[BoundsSafety] Re-introduce -funique-traps as a legacy alias of -fbounds-safety-unique-traps
#11602
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
delcypher
added
the
clang:bounds-safety
…bounds-safety-unique-traps` In rdar://158088410 (swiftlang#11455) the `-funique-traps` flag was removed in favor of a different implementation controlled by the `-fbounds-safety-unique-traps` flag. It turns out the `-funique-traps` flag is being used by an adopter of `-fbounds-safety`. To unbreak adopters of the flag this patch reintroduces the old flag (and its negation) as an alias of `-fbounds-safety-unique-traps` (`-fno-bounds-safety-unique-traps`) along with a diagnostic warning that `-funique-traps` (`-fno-unique-traps`) is deprecated. This patch doesn't use the `Alias<>` mixin in the `clang/Driver/Options.td` so "technically" at the implementation level `-funique-traps` isn't an alias of `-fbounds-safety-unique-traps`. This is done so that is possible distinguish use of the legacy flag from the new flag so that it is possible emit a deprecation warning. However, from the user's perspective `-funique-traps` and `-fbounds-safety-unique-traps` are aliases. We should remove `-funique-traps` eventually and that is tracked by rdar://162215869. rdar://162204734
delcypher
force-pushed
the
dliew/rdar-162204734
branch
from
e2d33ca to
7581278
Compare
|
@swift-ci test llvm |
rapidsna
reviewed
Oct 9, 2025
| else | ||
| ReplacementArg = getDriverOptTable().getOptionName( | ||
| options::OPT_fno_bounds_safety_unique_traps); | ||
| D.Diag(diag::warn_drv_deprecated_arg) |
There was a problem hiding this comment.
Can we make sure that this warning doesn't trigger as an error for the project using this flag?
There was a problem hiding this comment.
Yes we should do that but as a separate task to landing this fix here.
|
Test failures are known: |
rapidsna
approved these changes
Oct 9, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In rdar://158088410
(#11455) the
-funique-trapsflag was removed in favor of a different implementation controlled by the-fbounds-safety-unique-trapsflag.It turns out the
-funique-trapsflag is being used by an adopter of-fbounds-safety. To unbreak adopters of the flag this patch reintroduces the old flag (and its negation) as an alias of-fbounds-safety-unique-traps(-fno-bounds-safety-unique-traps) along with a diagnostic warning that-funique-traps(-fno-unique-traps) is deprecated.This patch doesn't use the
Alias<>mixin in theclang/Driver/Options.tdso "technically" at the implementation level-funique-trapsisn't an alias of-fbounds-safety-unique-traps. This is done so that is possible distinguish use of the legacy flag from the new flag so that it is possible emit a deprecation warning. However, from the user's perspective-funique-trapsand-fbounds-safety-unique-trapsare aliases.We should remove
-funique-trapseventually and that is tracked by rdar://162215869.rdar://162204734