Skip to content

[BoundsSafety] Rename experimental C++ and Objective-C flags and make them CC1 only #10635

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

Merged
merged 1 commit into from
May 8, 2025

Conversation

delcypher
Copy link

@delcypher delcypher commented May 7, 2025

The existing -fbounds-attributes-cxx-experimental and -fbounds-attributes-objc-experimental flags were previously exposed as driver and CC1 flags. However, given that these modes are highly experimental we don't want to encourage their use so these flags have no been made CC1 only flags. The functionality is still available from the driver by doing -Xclang <flag name>.

This patch also does a rename of the flags to be prefixed with experimental- which upstream prefers.

  1. -fbounds-attributes-cxx-experimental -> -fexperimental-bounds-safety-cxx
  2. -fbounds-attributes-objc-experimental -> -fexperimental-bounds-safety-objc.

This patch also renames "bounds attributes" to "bounds safety" for things associated with these flags (e.g.
LangOptions::BoundsSafetyCXXExperimental). "bounds attributes" is the legacy name that we need to slowly purge from the codebase and this is one small step towards that goal.

rdar://149423268

@delcypher delcypher added the clang:bounds-safety Issue relating to the experimental -fbounds-safety feature in Clang label May 7, 2025
@delcypher
Copy link
Author

@swift-ci test llvm

@@ -543,8 +543,8 @@ BENIGN_LANGOPT(CheckConstexprFunctionBodies, 1, 1,
LANGOPT(BoundsSafety, 1, 0, "Bounds safety extension for C")
/* TO_UPSTREAM(BoundsSafety) ON*/
LANGOPT(BoundsSafetyAttributes, 1, 0, "Experimental bounds safety attributes")
LANGOPT(BoundsAttributesCXXExperimental, 1, 0, "Experimental bounds attributes for C++")
LANGOPT(BoundsAttributesObjCExperimental, 1, 0, "Experimental bounds attributes for Objective-C")
LANGOPT(BoundsSafetyCXXExperimental, 1, 0, "Experimental bounds attributes for C++")
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hnrklssn @patrykstefanski @rapidsna Should we drop the Experimental suffix from the language option? Upstream doesn't seem to do this but I kind of like having the suffix there because it makes it much clearer that this language option is experimental.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have no strong opinion in either direction on this one

Copy link

@hnrklssn hnrklssn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, but we may want some more time to let the others weigh in

… them CC1 only

The existing `-fbounds-attributes-cxx-experimental` and
`-fbounds-attributes-objc-experimental` flags were previously exposed as driver and
CC1 flags. However, given that these modes are highly experimental we
don't want to encourage their use so these flags have no been made CC1
only flags. The functionality is still available from the driver by
doing `-Xclang <flag name>`.

This patch also does a rename of the flags to be prefixed with
`experimental-` which upstream prefers.

1. `-fbounds-attributes-cxx-experimental` -> `-fexperimental-bounds-safety-cxx`
2. `-fbounds-attributes-objc-experimental` ->
  `-fexperimental-bounds-safety-objc`.

This patch also renames "bounds attributes" to "bounds safety" for
things associated with these flags (e.g.
`LangOptions::BoundsSafetyCXXExperimental`). "bounds attributes" is the
legacy name that we need to slowly purge from the codebase and this is
one small step towards that goal.

rdar://149423268
@delcypher delcypher force-pushed the dliew/rdar-149423268 branch from b30b975 to 89573e8 Compare May 7, 2025 20:13
@delcypher
Copy link
Author

@swift-ci test llvm

@delcypher
Copy link
Author

Compile errors look unrelated:

[2025-05-08T05:13:48.186Z] /Users/ec2-user/jenkins/workspace/pr-apple-llvm-project-llvm-macos/branch-next/llvm-project/llvm/unittests/ExecutionEngine/JITLink/StubsTests.cpp:12:10: fatal error: 'llvm/ExecutionEngine/JITLink/i386.h' file not found
[2025-05-08T05:13:48.186Z]    12 | #include "llvm/ExecutionEngine/JITLink/i386.h"
[2025-05-08T05:13:48.186Z]       |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[2025-05-08T05:13:48.186Z] 1 error generated.
@delcypher delcypher merged commit cf995c3 into swiftlang:next May 8, 2025
0 of 2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clang:bounds-safety Issue relating to the experimental -fbounds-safety feature in Clang
2 participants