-
Notifications
You must be signed in to change notification settings - Fork 4k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Move --incompatible_disable_proto_source_root to the option graveyard.
And with it, the proto_library.proto_source_root attribute. Good riddance. Fixes #7153. RELNOTES: None. PiperOrigin-RevId: 262537130
- Loading branch information
1 parent
760e1dd
commit 3e8364c
Showing
5 changed files
with
16 additions
and
76 deletions.
There are no files selected for viewing
This file contains 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
This file contains 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
This file contains 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
This file contains 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
This file contains 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
3e8364c
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 saw this error while testing another incompatible flag
https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/1133#a050a273-de3e-4c39-a6a8-6fe289474f7a
3e8364c
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.
Sigh. How come the "Bazelisk + incompatible flags" build didn't find this? /cc @philwo
I'll send out a pull request.
3e8364c
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.
@lberki Mhm. I don’t know for sure, but maybe you can only repro this failure when doing „bazel shutdown“ or „bazel clean“ between flipping it? Wouldn’t be the first flag where this is true (personally, I believe that it’s quite a bold strategy to rely on Bazel’s incremental correctness to test flag flips for implementation details...).
3e8364c
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.
Hm, that would be weird since this is just a vanilla analysis phase flag.
Anyhow, bazelbuild/rules_rust#246 sent out.
3e8364c
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.
/cc @aehlig @laurentlb
An incremental correctness bug would be quite terrible. I thought I saw a case where Bazel in fact did not notice my "add a statement to a .bzl file that makes the build fail changes, but I dismissed it as me editing the wrong file.
I tried reproducing the exact sequence of actions that led to this after a
clean --expunge
and it all worked, so I'll dismiss it as my own mistake for the time being.3e8364c
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.
Why is this flag already removed? Shouldn't we wait at least one (incompatible) release between flipping a flag and making it a no-op? Same for
--incompatible_do_not_emit_buggy_external_repo_import
.3e8364c
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.
My understanding is that that's not the case: the policy is that if version N is designated as the migration period, the flag can be flipped and made a no-op. At least https://docs.bazel.build/versions/master/backward-compatibility.html does not promise anything to the contrary.
3e8364c
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.
Correct, the flag can even be removed in the same commit as it's flipped. We can weigh the benefits of removing the code vs keeping the flag longer.
Yannic, do you think it's important to keep this flag longer?