Rollup of 4 pull requests#155112
Closed
JonathanBrouwer wants to merge 12 commits intorust-lang:mainfrom
Closed
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.
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.
…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)
rustbot
added
A-attributes
Contributor
Author
|
@bors r+ rollup=never p=5 |
Contributor
rust-bors
bot
added
S-waiting-on-bors
rust-bors
bot
added
S-waiting-on-author
Contributor
|
This pull request was unapproved due to being closed. |
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
7 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:
#[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)r? @ghost
Create a similar rollup