incompatible_disable_nocopts: Disallow 'nocopts' attribute from cc_* rules

[scentini]

Flag: --incompatible_disable_nocopts
Available since: 0.28
Will be flipped: 1.0

The nocopts attribute in cc_* rules is used to specify a pattern for filtering out flags from C++ compilation command line.
We are deprecating it because:

• it prevents migration of C++ rules to Starlark: we don’t have regex in Starlark currently
• we don’t need to do it - we can disable features to have the same effect

Migration

If you use the nocopts attributes to filter out a flag please comment on this issue, with the offending flag/pattern that you're filtering out.

As we have no way of knowing which flags users filter out, we will rely on them reaching out to us in case the flipping of the --incompatible_disable_nocopts flag breaks their project. We will keep on support for filtering out the flags through --noincompatible_disable_nocopts for 1-2 extra Bazel releases, until we are able to provide the support for disabling the reported flags through features.

If a user is filtering out a flag provided by bazel's own C++ toolchain configuration, we will wrap the flag into a feature, so the user can disable the feature instead of filter out the flag.
E.g a

cc_library(
    name = "lib",
    srcs = ["lib.cc", "lib.h"],
    nocopts = "flagA",
)

would be migrated to

cc_library(
    name = "lib",
    srcs = ["lib.cc", "lib.h"],
    features = ["-flag_a_feature"],
)

with flag_a_feature being defined in bazel's own C++ toolchain configuration.

[dslomov]

What is the flag flip risk in 1.0?
https://buildkite.com/bazel/bazelisk-plus-incompatible-flags/builds/195 shows that it "only" breaks TensorFlow

[AustinSchuh]

I grepped through our code base and we have 1 call site. One library really doesn't work well when built with coverage support (which is enabled by the toolchain/crosstool). We remove the --coverage flag with nocopts.

[scentini]

Thanks for reaching out!
Our C++ toolchain configuration rule provides the --coverage flag through a coverage feature.
Can you try replacing nocopts = '--coverage' with features = ["-coverage"] (note the minus , denoting "disable this feature")?

[AustinSchuh]

That looks like it worked. That's a much better solution than nocopts. Thanks!

[scentini]

This flag was flipped in 8b840e1.

[cocasema]

There's one more use-case for nocopts - when we build third-party code and have to disable some warnings (-Wno-). If we have both .c and .cpp files in a single cc_library and need to turn off some c-only warnings (like -Wno-declaration-after-statement), we also have to add then to nocopts to make g++ happy.

[scentini]

Do you use your own toolchain configuration? If so, you'll need to create a feature that will pass the -Wno-declaration-after-statement to the command line, and use
features = ["-declaration_after_statement"] in the targets that you'd like to not apply the flag to.

[wanguanglu]

if I want to filter "-Werror" with nocopts="-Werror"
but features = ["-error"] seems not work.

[asraa]

Hi, I have a use-case for nocopts, and wanted to know what the appropriate migration is. I have a third-party library that I'm building through an http_archive, and wanted to build it without the preprocessor macro FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION defined, even when the CLI defines it. Some users pass in --copt=-DFUZZING_BUILD_... and a build configuraiton we define also uses this copt.

Originally I was going to use nocopts and patch the BUILD file for the dependency, but instead it seems I should be using a feature. Does this mean I need to create a feature for FUZZING_BUILD_MODE... and pass it in to every target but the RE2 library during a specific build config?

[mst9009]

If I want to filter out the “-g” option, how should I set the “features” attribute？Thanks！

[wrowe]

If I want to filter out the “-g” option, how should I set the “features” attribute？Thanks！

@mst9009 sorry this is quite late, but adding copts "-g0" should accomplish what you were looking for?

[changlan]

Hi. How should I filter out the -fstack-protector flag with the “features” attribute? Tried default_compile_flags but it removed all compile flags.

[mason-bially]

This may be because of a whole separate issue (and I realize years after the original change), but one of the use cases for nocopts that I was using was removing /I. from some windows builds where it was being applied incorrectly (it's inclusion causes MSVC to behave differently than gcc/clang given the same file structure; this would be the separate and much more complex issue to fix that I am fine working around, even though it's pretty weird (the first depending cc_library's BUILD file location effects the build of the dependent cc_library for all the other depending rules)). So a feature flag setting of -include_path_local (minus to remove) would be nice (unless there is a syntax for removing a specific instance of the include_paths flag group? Currently my workaround is this:

cc_library(
    ...
    features = select({
        "@bazel_tools//src/conditions:windows": ["-include_paths"],
        "//conditions:default": [],
    }),
    copts = select({
        "@bazel_tools//src/conditions:windows": ["/Imanual", "/Iinclude", "/Ilist"],
        "//conditions:default": [],
    }),
)

Which is brittle, ugly, and not great (and is notably significantly worse than the original nocopts method of fixing it up)

[wondfor]

maybe you should update https://docs.bazel.build/versions/main/be/c-cpp.html#cc_binary.nocopts

[JohnGHS]

I have to admit that I'm only starting with Bazel, so please take the following with a grain of salt.
I'm trying to integrate a non-gcc C++ compiler into Bazel, and it is complaining about a lot of gcc-specific options that are being injected into the build. I can easily believe that this is because I'm following a tutorial that assumes a gcc builder, hence a single load() could be adding unnecessary flags. However, the most egregious of these (as I see it) are:

• "Unknown option '-frandom-seed=...'"
• "Unknown option '-iquote' passed to linker"
• "Unrecognized option: -S"

I know what each of these options do with gcc (although I'm surprised to see '-iquote' passed to the linker), but want to turn them off.

[scentini]

cc @oquenchil

[dmadisetti]

3 years later and docs have no been updated. Also dead references in comments and code: https://github.com/bazelbuild/bazel/search?p=1&q=nocopts&type=code (edit: github code search is 😬, see: https://cs.opensource.google/search?q=nocopts&sq=&ss=bazel%2Fbazel )

Is the logic with UNFILTERED_COMPILE_FLAGS_FEATURE_NAME still relevant?

bazel/src/main/java/com/google/devtools/build/lib/rules/cpp/CompileCommandLine.java

Line 144 in a48e246

if (pair.getFirst().equals(CppRuleClasses.UNFILTERED_COMPILE_FLAGS_FEATURE_NAME)) {

The provided toolchain link is also dead, has it been moved to https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_toolchain_config_lib.bzl ?

Which is then consumed by the various tool chain definitions? e.g. https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/unix_cc_toolchain_config.bzl

I think these features need to be a bit better documented, are they consistent between toolchains? I think I found something for my usecase, but not with the granularity I would like (just looking to turn off cxx_flags).

[keith]

FWIW this attribute is still in the docs which might confuse some folks

[hvadehra]

cc @pzembrod