-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Visit more targets when validating attributes #80920
Conversation
@bors r+ LGTM! |
📌 Commit 39a1d774fcbfbb3dcf434cdf8ad9e0b97c3ecc1d has been approved by |
@bors r- try |
⌛ Trying commit 39a1d774fcbfbb3dcf434cdf8ad9e0b97c3ecc1d with merge bb9dbf1d07454a99066eabaabd5819851281494b... |
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@craterbot check |
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
Just wanted to give a heads up, I think PR #80641 is doing something almost identical, you may want to coordinate, and at least make sure the same tests are included and the issues (like "inline") are covered. |
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
Here's an issue on |
🎉 Experiment
|
Looks like this regresses |
I'll nominate this for the language team to decide if the breaking changes are acceptable. |
Note that |
We discussed this during lang meeting today and concluded that we can move forward (we want to ping authors of the affected crates, but I believe have done so in Niko's comment and @joshtriplett is going to file an issue on the other project). We also noted that generally speaking this breakage is unfortunate and we may want to move to only breaking crates over edition boundaries in cases like this, but we're not prepared to reconsider the current pre-existing behavior here for inline in other contexts. It's unclear to me that we get a huge amount of benefit from avoiding the breakage in cases like this too. |
I think we can probably land this then, could you rebase @rylev? |
39a1d77
to
396022b
Compare
@davidtwco I've rebased. The PR is a lot less exciting than it started as, but there might be a reason to still merge it. Perhaps though we should further refactor how attributes are validated in other parts of the compiler. |
@bors r+ |
📌 Commit 9f0e1d4 has been approved by |
Rollup of 11 pull requests Successful merges: - rust-lang#80523 (#[doc(inline)] sym_generated) - rust-lang#80920 (Visit more targets when validating attributes) - rust-lang#81720 (Updated smallvec version due to RUSTSEC-2021-0003) - rust-lang#81891 ([rustdoc-json] Make `header` a vec of modifiers, and FunctionPointer consistent) - rust-lang#81912 (Implement the precise analysis pass for lint `disjoint_capture_drop_reorder`) - rust-lang#81914 (Fixing bad suggestion for `_` in `const` type when a function rust-lang#81885) - rust-lang#81919 (BTreeMap: fix internal comments) - rust-lang#81927 (Add a regression test for rust-lang#32498) - rust-lang#81965 (Fix MIR pretty printer for non-local DefIds) - rust-lang#82029 (Use debug log level for developer oriented logs) - rust-lang#82056 (fix ice (rust-lang#82032)) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Sorry I missed these parts of the description, but hopefully this helps for future PRs:
You can always keep data in the visitor itself, but that's harder to make sure nothing goes wrong with.
It's a bit weird IMO that |
This begins to address #80048, allowing for additional validation of attributes.
There are more refactorings that can be done, though I think they should be tackled in additional PRs:
ast_validation
intorustc_passes
Target
toAttributeTarget
Visitor::visit_attribute
.Target
into this method which might be too big of a refactoring to be worth it.r? @davidtwco