New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
stdlib: Print the error message in precondition() and preconditionFailure() even in release builds. #26215
base: main
Are you sure you want to change the base?
Conversation
@swift-ci smoke test |
…lure() even in release builds. This is important for frameworks, like Foundation, because frameworks are always shipped and used as release builds. This change results in a little code size overhead, but it's quite small: Instead of a trap instruction it basically ends up in loading a few registers and calling the fatalError runtime function. I also added an overload for precondition/Failure without a message (instead of a default parameter). This overload just traps, because without a message calling the fatalError function does not add any benefit.
f050b4f
to
5b31183
Compare
@@ -59,10 +59,12 @@ public func assert( | |||
/// | |||
/// * In playgrounds and `-Onone` builds (the default for Xcode's Debug | |||
/// configuration): If `condition` evaluates to `false`, stop program | |||
/// execution in a debuggable state after printing `message`. | |||
/// execution in a debuggable state after printing `message` | |||
/// along with the file and line information.. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/// along with the file and line information.. | |
/// along with the file and line information. |
@swift-ci please benchmark |
@swift-ci please test |
Performance: -O
Code size: -O
Performance: -Osize
Code size: -Osize
Performance: -Onone
Code size: -swiftlibs
How to read the dataThe tables contain differences in performance which are larger than 8% and differences in code size which are larger than 1%.If you see any unexpected regressions, you should consider fixing the Noise: Sometimes the performance results (not code size!) contain false Hardware Overview
|
Build failed |
} else if _isReleaseAssertConfiguration() { | ||
Builtin.condfail_message(true._value, | ||
StaticString("precondition failure").unsafeRawPointer) | ||
StaticString("Precondition failed").unsafeRawPointer) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd suggest not adding this additional overload. We don't really want people omitting messages from their preconditions to save on code size; that is an unnecessary level of flexibility.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't add it, but converted the default-argument version to a separate function. Removing the overload would be a source compatibility break.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, I'm saying you could just leave the default-argument version.
Is there any chance for this PR to be picked up again? We just ran into the problem that a |
I think the better usability is worth the small code size increase. @airspeedswift @kylemacomber are you fine with making this change? |
This is important for frameworks, like Foundation, because frameworks are always shipped and used as release builds.
This change results in a little code size overhead, but it's quite small: Instead of a trap instruction it basically ends up in loading a few registers and calling the fatalError runtime function.
rdar://problem/71323149