Can we get consistent assertion behavior in the latest release Swift compiler across host platforms?

Development Compiler
1

I have been noticing issues raised for compiler assertion crashes this year with the OSS macOS release toolchains, which are not reproducible with the Xcode or linux release toolchains, presumably because those assertions are disabled in those builds. In particular, @marcprux has filed issues like these, and I raised this problem in the forum five months ago.

I understand that it may be a contentious issue of whether the release compiler should have these assertions enabled or disabled, but I'd at least like to argue for consistency across platforms and builds, ie the latest release should make the same choice for all release compiler builds. I just raised the issue with @compnerd and @etcwilde, and @compnerd tells us that the release Windows compiler has these assertions enabled.

This is not going to be a great dev experience, if the Swift 6.1.2 compiler on linux can compile those samples linked, but the Swift 6.1.2 compiler on Windows can't.

Let me emphasize that I'm only talking about the latest patch releases like 6.1.2, the nightly snapshot builds are excluded from this discussion.

I'd like to see some consensus reached on this topic by the Swift teams, and I suspect a growing amount of Swift devs would also.

4 Likes
2

From a supportability point of view, the windows toolchain really does rely on the assertions heavily. The assertions have almost always found real issues that would silently potentially cause invalid code generation. or potentially allow invalid code through. I think that given the resources available for Windows, the assertions are not reasonable to disable.

We are waiting on @mishal_shah to coordiinat getting Rename toolchain msi and cab files to include name of variant (asserts) by mhegazy · Pull Request #428 · swiftlang/swift-installer-scripts · GitHub merged which will allow us to package both an Asserts and NoAsserts toolchain and the user can then select if they want to ignore the issues and build the code anyway.

1 Like
3

I've been consistently running into this issue for months, and have had to refactor and rearchitect a ton of perfectly valid swift code, with pure swift dependencies just to avoid compiler crashes.

This affects Skip.tools android apps, because the android sdk relies on the macOS toolchain. I started running into this as well when I was testing out the new swiftly toolchain manager.

I did notice that the last couple changes to the build toolchain are related to adding flags that allow you to target macOS specifically, and one about adding an assertions flag. Could this be an unintended interaction between those flags?

4

Unfortunately, programs that only compile with a no-asserts toolchain aren’t quite perfectly valid. At the very least it means you’re exercising some compiler code path that’s not covered by tests, so it could regress in a future release. We’ve also seen bugs where an input program that trips an assertion then silently miscompiles without asserts.

1 Like
5

Unfortunately, programs that only compile with a no-asserts toolchain aren’t quite perfectly valid. At the very least it means you’re exercising some compiler code path that’s not covered by tests, so it could regress in a future release. We’ve also seen bugs where an input program that trips an assertion then silently miscompiles without asserts.

So does that mean that the Xcode toolchain has these assertions enabled, but generates code in a more correct way? Or does the xcode toolchain disable these assertions, potentially allowing through code that can silently miscompile?

If thats the case should people be concerned about using these features in production systems?