-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Aspects get falsely evaluated against incompatible targets #15271
Labels
P2
We'll consider working on this in future. (Assignee optional)
team-Configurability
platforms, toolchains, cquery, select(), config transitions
Comments
@gregestren , FYI. I'll work on this once the robotics season is over at the end of this month and after I finish with #14096. |
sgowroji
added
type: bug
team-Configurability
platforms, toolchains, cquery, select(), config transitions
untriaged
labels
Apr 18, 2022
Makes total sense, and I agree. Thanks for the report and commitment, and good luck with robotics! |
gregestren
added
P2
We'll consider working on this in future. (Assignee optional)
and removed
untriaged
type: bug
labels
Apr 18, 2022
philsc
added a commit
to philsc/bazel
that referenced
this issue
Jul 26, 2022
This patch prevents aspect functions from being evaluated when their associated targets are incompatible. Otherwise aspects can generate errors that should never be printed at all. For example, an aspect evaluating an incompatible target may generate errors about missing providers. This is not the desired behaviour. The implementation in this patch short-circuits the `AspectValue` creation if the associated target is incompatible. I had tried to add an `IncompatiblePlatformProvider` to the corresponding `ConfiguredAspect` instance, but then Bazel complained about having duplicate `IncompatiblePlatformProvider` instances. Fixes bazelbuild#15271 (cherry picked from commit 6d71850)
ShreeM01
added a commit
that referenced
this issue
Jul 27, 2022
* Prevent aspects from executing on incompatible targets This patch prevents aspect functions from being evaluated when their associated targets are incompatible. Otherwise aspects can generate errors that should never be printed at all. For example, an aspect evaluating an incompatible target may generate errors about missing providers. This is not the desired behaviour. The implementation in this patch short-circuits the `AspectValue` creation if the associated target is incompatible. I had tried to add an `IncompatiblePlatformProvider` to the corresponding `ConfiguredAspect` instance, but then Bazel complained about having duplicate `IncompatiblePlatformProvider` instances. Fixes #15271 (cherry picked from commit 6d71850) * Fix build and test Co-authored-by: kshyanashree <[email protected]>
dfinity-bot
pushed a commit
to dfinity/ic
that referenced
this issue
Sep 1, 2022
Upgrade bazel to 5.3.0, bazelisk to 1.12.2 This release contains the fix for bazelbuild/bazel#15271 and therefore fixes `bazel build //...` on Mac OS. bazel 5.3.0 release notes: https://blog.bazel.build/2022/08/23/bazel-5.3.html See merge request dfinity-lab/public/ic!7362
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
P2
We'll consider working on this in future. (Assignee optional)
team-Configurability
platforms, toolchains, cquery, select(), config transitions
Description of the bug:
It looks like aspects run on incompatible targets when they shouldn't.
I think the answer here is that the aspects should not run and instead just provide the
IncompatiblePlatformProvider
to signify that it's incompatible as well.What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
The absolute minimal example:
example.bzl
:BUILD
:When you build this target, you'll see that the
print()
statement in the aspect gets executed:This can lead to undesirable effects. Largely because the aspect evaluation can generate errors before bazel gets a chance to tell the user about the incompatible target being requested.
Which operating system are you running Bazel on?
Ubuntu 18.04
What is the output of
bazel info release
?release 5.1.0
If
bazel info release
returnsdevelopment version
or(@non-git)
, tell us how you built Bazel.N/A
What's the output of
git remote get-url origin; git rev-parse master; git rev-parse HEAD
?Have you found anything relevant by searching the web?
No response
Any other information, logs, or outputs that you want to share?
No response
The text was updated successfully, but these errors were encountered: