Rollup of 6 pull requests#155115
Conversation
Currently, `rustc_errors` depends on `rustc_abi`, which depends on `rustc_error_messages`. This is a bit odd. `rustc_errors` depends on `rustc_abi` for a single reason: `rustc_abi` defines a type `TargetDataLayoutErrors` and `rustc_errors` impls `Diagnostic` for that type. We can get a more natural relationship by inverting the dependency, moving the `Diagnostic` trait upstream. Then `rustc_abi` defines `TargetDataLayoutErrors` and also impls `Diagnostic` for it. `rustc_errors` is already pretty far upstream in the crate graph, it doesn't hurt to push it a little further because errors are a very low-level concept.
Error enum names should not be plural. Even though there are multiple possible errors, each instance of an error enum describes a single error. There are dozens of singular error enum names, and only two plural error enum names. This commit makes them both singular.
Unconditionally pass -Zunstable-options in the `unpretty` and `-Zno-codegen` (typecheck) paths in compiletest. This ensures custom targets resolved via RUST_TARGET_PATH work consistently. This is primarily needed when using non-built-in targets without a .json extension. Signed-off-by: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
This PR introduces a `#[diagnostic::on_unknown_item]` attribute that allows crate authors to customize the error messages emitted by unresolved imports. The main usecase for this is using this attribute as part of a proc macro that expects a certain external module structure to exist or certain dependencies to be there. For me personally the motivating use-case are several derives in diesel, that expect to refer to a `tabe` module. That is done either implicitly (via the name of the type with the derive) or explicitly by the user. This attribute would allow us to improve the error message in both cases: * For the implicit case we could explicity call out our assumptions (turning the name into lower case, adding an `s` in the end) + point to the explicit variant as alternative * For the explicit variant we would add additional notes to tell the user why this is happening and what they should look for to fix the problem (be more explicit about certain diesel specific assumptions of the module structure) I assume that similar use-cases exist for other proc-macros as well, therefore I decided to put in the work implementing this new attribute. I would also assume that this is likely not useful for std-lib internal usage.
…` instead of a `Span`
…r=jdonszelmann Introduce a `#[diagnostic::on_unknown]` attribute This PR introduces a `#[diagnostic::on_unknown]` attribute that allows crate authors to customize the error messages emitted by unresolved imports. The main usecase for this is using this attribute as part of a proc macro that expects a certain external module structure to exist or certain dependencies to be there. For me personally the motivating use-case are several derives in diesel, that expect to refer to a `tabe` module. That is done either implicitly (via the name of the type with the derive) or explicitly by the user. This attribute would allow us to improve the error message in both cases: * For the implicit case we could explicity call out our assumptions (turning the name into lower case, adding an `s` in the end) + point to the explicit variant as alternative * For the explicit variant we would add additional notes to tell the user why this is happening and what they should look for to fix the problem (be more explicit about certain diesel specific assumptions of the module structure) I assume that similar use-cases exist for other proc-macros as well, therefore I decided to put in the work implementing this new attribute. I would also assume that this is likely not useful for std-lib internal usage. related rust-lang#152900 and rust-lang#128674
…ng-attrs, r=petrochenkov Reject dangling attributes in where clauses Report `attribute without where predicates` for trailing outer attributes in where clauses. Closes rust-lang#155073 .
…_abi, r=davidtwco Invert dependency between `rustc_errors` and `rustc_abi`. Currently, `rustc_errors` depends on `rustc_abi`, which depends on `rustc_error_messages`. This is a bit odd. `rustc_errors` depends on `rustc_abi` for a single reason: `rustc_abi` defines a type `TargetDataLayoutErrors` and `rustc_errors` impls `Diagnostic` for that type. We can get a more natural relationship by inverting the dependency, moving the `Diagnostic` trait upstream. Then `rustc_abi` defines `TargetDataLayoutErrors` and also impls `Diagnostic` for it. `rustc_errors` is already pretty far upstream in the crate graph, it doesn't hurt to push it a little further because errors are a very low-level concept. r? @davidtwco
…dtwco Add suggestion to `.to_owned()` used on `Cow` when borrowing fixes rust-lang#144792 supersedes rust-lang#144925 with the review comments addressed the tests suggested from @Kivooeo from rust-lang#144925 (comment) didn't work entirely, because these tests failed due to error `[E0308]` mismatched types, which actually already provides a suggestion, that actually makes the code compile: ``` $ cargo check error[E0308]: mismatched types --> src/main.rs:3:5 | 1 | fn test_cow_suggestion() -> String { | ------ expected `std::string::String` because of return type 2 | let os_string = std::ffi::OsString::from("test"); 3 | os_string.to_string_lossy().to_owned() | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `String`, found `Cow<'_, str>` | = note: expected struct `std::string::String` found enum `std::borrow::Cow<'_, str>` help: try using a conversion method | 3 | os_string.to_string_lossy().to_owned().to_string() | ++++++++++++ ``` now this suggestion is of course not good or efficient code, but via clippy with `-Wclippy::nursery` lint group you can actually get to the correct code, so i don't think this is too much of an issue: <details> <summary>the clippy suggestions</summary> ``` $ cargo clippy -- -Wclippy::nursery warning: this `to_owned` call clones the `Cow<'_, str>` itself and does not cause its contents to become owned --> src/main.rs:3:5 | 3 | os_string.to_string_lossy().to_owned().to_string() | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: for further information visit https://rust-lang.github.io/rust-clippy/beta/index.html#suspicious_to_owned = note: `#[warn(clippy::suspicious_to_owned)]` on by default help: depending on intent, either make the `Cow` an `Owned` variant | 3 | os_string.to_string_lossy().into_owned().to_string() | ++ help: or clone the `Cow` itself | 3 - os_string.to_string_lossy().to_owned().to_string() 3 + os_string.to_string_lossy().clone().to_string() | $ # apply first suggestion $ cargo c -- -Wclippy::nursery warning: redundant clone --> src/main.rs:3:45 | 3 | os_string.to_string_lossy().into_owned().to_string() | ^^^^^^^^^^^^ help: remove this | note: this value is dropped without further use --> src/main.rs:3:5 | 3 | os_string.to_string_lossy().into_owned().to_string() | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ = help: for further information visit https://rust-lang.github.io/rust-clippy/beta/index.html#redundant_clone = note: `-W clippy::redundant-clone` implied by `-W clippy::nursery` = help: to override `-W clippy::nursery` add `#[allow(clippy::redundant_clone)]` ``` </details> the actual error that we are looking for is error `[E0515]`, cannot return value referencing local variable, which was only present in the original issue due to automatic type inference assuming you want to return a cloned `Cow<'_, str>`, which is of course not possible. this is why i took the original test functions and turned them into closures, where it's less obvious that it's trying to return the wrong type. r? davidtwco (because you reviewed the last attempt) (also, let me know if i should squash this down to one commit and add myself as the co-contributor)
…t-unstable, r=davidtwco compiletest: pass -Zunstable-options for unpretty and no-codegen paths When using custom targets via `RUST_TARGET_PATH`, compiletest does not consistently pass `-Zunstable-options` in all code paths. In particular, `unpretty` and `-Zno-codegen` (typecheck) paths invoke rustc without `-Zunstable-options`, which causes failures when the target is not built-in. Pass `-Zunstable-options` in these code paths to ensure consistent behavior when using custom targets. This primarily affects setups using custom targets without `.json` suffix (resolved via `RUST_TARGET_PATH`).
…, r=JonathanBrouwer Make `rustc_attr_parsing::SharedContext::emit_lint` take a `MultiSpan` instead of a `Span` I'll likely need it for rust-lang#153721 to allow emitting the lint on one attribute at a time instead of each of the wrong values. r? @JonathanBrouwer
|
@bors r+ rollup=never p=5 |
|
Trying commonly failed jobs |
This comment has been minimized.
This comment has been minimized.
Rollup of 6 pull requests try-job: dist-various-1 try-job: test-various try-job: x86_64-gnu-aux try-job: x86_64-gnu-llvm-21-3 try-job: x86_64-msvc-1 try-job: aarch64-apple try-job: x86_64-mingw-1
This comment has been minimized.
This comment has been minimized.
|
📌 Perf builds for each rolled up PR:
previous master: b6100ccf71 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 b6100cc (parent) -> 02c7f9b (this PR) Test differencesShow 31 test diffsStage 1
Stage 2
Additionally, 15 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 02c7f9bec0fd583160f8bcccb830216023b07bee --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 (02c7f9b): comparison URL. Overall result: ❌ regressions - please read:Our benchmarks found a performance regression caused by this PR. Next Steps:
@rustbot label: +perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary -0.1%, secondary -3.8%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary -4.8%)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: 491.232s -> 491.759s (0.11%) |
Successful merges:
#[diagnostic::on_unknown]attribute #152901 (Introduce a#[diagnostic::on_unknown]attribute)rustc_errorsandrustc_abi. #154449 (Invert dependency betweenrustc_errorsandrustc_abi.).to_owned()used onCowwhen borrowing #154646 (Add suggestion to.to_owned()used onCowwhen borrowing)rustc_attr_parsing::SharedContext::emit_linttake aMultiSpaninstead of aSpan#155097 (Makerustc_attr_parsing::SharedContext::emit_linttake aMultiSpaninstead of aSpan)r? @ghost
Create a similar rollup