Rollup of 2 pull requests#155090
Closed
JonathanBrouwer wants to merge 6 commits intorust-lang:mainfrom
Closed
Conversation
Builtin attribute macros like #[eii] generate AST items programmatically without collected tokens. When another attribute macro was present on the same item, the compiler would panic in TokenStream::from_ast() trying to tokenize the generated items during subsequent attribute expansion. Generate fake token streams (via pretty-print and re-parse) for Item and ForeignItem nodes that lack collected tokens, following the existing pattern used for Crate and out-of-line modules.
…ass test When a function has `eii_impls` set (via `eii_shared_macro`), the `#[hello]` attribute is consumed from `node.attrs()`. A subsequent `AttrProcMacro` expander like `contracts::requires` calls `item.to_tokens()` which uses the current `node.attrs()` — so `#[hello]` is missing from the token stream. After the roundtrip and `parse_ast_fragment`, the new AST item has empty `eii_impls` and the EII link is broken. Fix this by using `fake_token_stream_for_item` when the item is a function with non-empty `eii_impls`. The pretty-printer re-emits `eii_impls` as `#[hello]` in `print_fn_full`, which survives the roundtrip and gets re-expanded by `eii_shared_macro` on the resulting item. Add a run-pass test to verify EII + contract annotation works correctly at runtime.
…erated_item test
The previous test used `fn implementation() {}` with a body, which caused
`generate_default_impl` to generate a `const _: () = { fn implementation() {} }`
item containing `self::implementation`. On Linux (aarch64-gnu-llvm-21), the
resolver's `suggest_ident_hidden_by_hygiene` emitted an extra help span on the
resulting E0425 error that did not appear on macOS, causing a stderr mismatch.
Switch the declaration to `fn implementation();` (no body) so that
`generate_default_impl` is not called and no `self::implementation` path is
emitted. The test still validates that `#[eii]` + `#[core::contracts::ensures]`
produces graceful errors instead of an ICE, via the two contract-annotation
errors on the generated foreign item.
…-eii-attr-expansion, r=jdonszelmann Fix ICE when combining #[eii] with #[core::contracts::ensures] Fixes rust-lang#153745 Builtin attribute macros like #[eii] generate AST items programmatically without collected tokens. When another attribute macro was present on the same item, the compiler would panic in TokenStream::from_ast() trying to tokenize the generated items during subsequent attribute expansion. Generate fake token streams (via pretty-print and re-parse) for Item and ForeignItem nodes that lack collected tokens, following the existing pattern used for Crate and out-of-line modules.
…, r=JonathanBrouwer error on invalid macho section specifier The macho section specifier used by `#[link_section = "..."]` is more strict than e.g. the one for elf. LLVM will error when you get it wrong, which is easy to do if you're used to elf. So, provide some guidance for the simplest mistakes, based on the LLVM validation. Currently compilation fails with an LLVM error, see https://godbolt.org/z/WoE8EdK1K. The LLVM validation logic is at https://github.com/llvm/llvm-project/blob/a0f0d6342e0cd75b7f41e0e6aae0944393b68a62/llvm/lib/MC/MCSectionMachO.cpp#L199-L203 LLVM validates the other components of the section specifier too, but it feels a bit fragile to duplicate those checks. If you get that far, hopefully the LLVM errors will be sufficient to get unstuck. --- sidequest from rust-lang#147811 r? JonathanBrouwer specifically, is this the right place for this sort of validation? `rustc_attr_parsing` also does some validation.
rustbot
added
A-attributes
Contributor
Author
|
@bors r+ rollup=never p=5 |
Contributor
rust-bors
bot
added
S-waiting-on-bors
This comment has been minimized.
This comment has been minimized.
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
rust-bors
bot
added
S-waiting-on-review
Contributor
|
💔 Test for ee627eb failed: CI. Failed job:
|
rust-bors
bot
added
S-waiting-on-author
Contributor
|
PR #155065, which is a member of this rollup, was unapproved. |
rustbot
removed
the
S-waiting-on-author
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Successful merges:
r? @ghost
Create a similar rollup