Rollup of 8 pull requests#155099
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.
Add bit-or detection in lower expr within pattern. Previously `pat1 | pat2` in `$e:expr` failed to trigger `.pattern_from_macro_note` diagnostic bc `ast::Expr::is_approximately_pattern()` did not cover bit-or.
…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.
It doesn't need to be in there, it can instead be at the single call site. Removing it eliminates one parameter, makes `define_queries!` smaller (which is always good), and also enables the next commit which tidies up profiling. This commit also changes how `value` and `verify` are initialized, because I don't like the current way of doing it after the declaration.
From `plumbing.rs` to `execution.rs`, which is where most of the other query profiling occurs. It also avoids eliminates some fn parameters. This means the `provided_to_erased` call in `try_from_load_disk_fn` is now included in the profiling when previously it wasn't. This is good because `provided_to_erased` is included in other profiling calls (e.g. calls to `invoke_provider_fn`).
Moreover, dereference `ty_layout.align` for `#[rustc_dump_layout(align)]`
to render `align: Align($N bytes)` instead of `align: AbiAlign { abi: Align($N bytes) }`
which contains the same amount of information but it more concise and legible.
…g-mode, r=lcnr Always exhaustively match on typing mode r? @lcnr Unimplements Eq/PartialEq for TypingMode, adds TypingModeEqWrapper for the few cases where we need it (mainly in the query system), and adds a new rustc internal lint to detect cases where we non-exhaustively match on typing mode.
Simplify `try_load_from_disk_fn`. `try_load_from_disk_fn` has a single call site. We can move some of the stuff within it to its single call site, which simplifies it, and also results in all of the query profiling code ending up in the same module. Details in individual commits. r? @Zalathar
…clean, r=jdonszelmann Restrict EII declarations to functions at lowering time We tighten EII declaration resolution so that `lower_path_simple_eii` only accepts function‑like items (`Fn, AssocFn, Ctor(_, Fn)`) as valid EII targets. If name resolution points at something else (like a const with the same name), we now emit a direct error (“`externally implementable items must refer to a function`”) at the declaration site, which prevents bad `DefIds` from ever reaching `compare_eii_function_types` and turning into an ICE this is more robust and root-cause oriented fix to rust-lang#152337 issue and an alternate of my more simple PR rust-lang#152365 test included
…-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=JohnTitor Fix `pattern_from_macro_note` for bit-or expr This is a continuation of issue rust-lang#99380 (and pr rust-lang#124488) but covers bit-or pattern. Essentially a `pat1 | pat2`, or any bit-or pattern used in a `$e:expr` was not firing the `.pattern_from_macro_note` diagnostic bc `ast::Expr::is_approximately_pattern()` did not cover bit-or. The cover for bit-or is only added in `lower_expr_within_pat()`, otherwise doing it in `is_approximately_pattern()` would result in the suggestion `if (i + 2) = 2 => if let (i + 2) = 2` from `suggest_pattern_match_with_let()` (which is the only other place `ast::Expr::is_approximately_pattern()` is used from what i see). resolves rust-lang#99380 refs rust-lang#124488
…=JonathanBrouwer Rename some more of our internal `#[rustc_*]` TEST attributes Follow-up to rust-lang#153300. r? JonathanBrouwer or jdonszelmann
…lowering-ice, r=petrochenkov delegation: fix unelided lifetime ICE, refactoring of GenericArgPosition This PR does two things: - First it restores `lower_generic_args_of_path` as it was before rust-lang#151864, as it turns out we should use `GenericArgPosition::Type` for generic args lowering for signature inheritance, as it will not cause lifetime inference and then ICEs during child args lowering, - Next it refactors `GenericArgPosition` enum replacing `Value` and `MethodCall` with `Call(IsMethodCall)`, as the only place where we created `Value` or `MethodCall` variants was in `check_generic_arg_count_for_call`, where it was a match over `is_method_call`. Not sure it is needed, but seems cleaner to me. Fixes rust-lang#154178, part of rust-lang#118212. r? @petrochenkov
… r=JohnTitor Fix code block whitespace handling in Markdown ### Fix Markdown code block closing whitespace handling Previously, the parser incorrectly accepted closing backticks followed by extra text and rejected lines where only spaces appeared after closing backticks. This did not match expected Markdown behavior. Now, the parser correctly ends a code block only when line after the code ends with spaces or nothing. Lines where extra text appears after the closing backticks are treated as part of the code block. Includes tests for both correct and incorrect cases. ### Related issue This PR addresses the Outreachy issue: [Markdown whitespace bug in Rust Compiler](rustfoundation/interop-initiative#53)
|
@bors r+ rollup=never p=5 |
This comment has been minimized.
This comment has been minimized.
|
📌 Perf builds for each rolled up PR:
previous master: 8317fef204 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 8317fef (parent) -> b6100cc (this PR) Test differencesShow 72 test diffsStage 0
Stage 1
Stage 2
Additionally, 58 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard b6100ccf71c092dd01e7a68930360892545ee4fb --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
|
Finished benchmarking commit (b6100cc): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis perf run didn't have relevant results for this metric. Max RSS (memory usage)Results (primary 1.7%, secondary 2.2%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary 5.4%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis perf run didn't have relevant results for this metric. Bootstrap: 489.232s -> 491.232s (0.41%) |
Successful merges:
try_load_from_disk_fn. #155080 (Simplifytry_load_from_disk_fn.)pattern_from_macro_notefor bit-or expr #154369 (Fixpattern_from_macro_notefor bit-or expr)#[rustc_*]TEST attributes #155027 ( Rename some more of our internal#[rustc_*]TEST attributes)r? @ghost
Create a similar rollup