Introduce a #[diagnostic::on_unknown_item] attribute#152901
Open
weiznich wants to merge 1 commit intorust-lang:mainfrom
Open
Introduce a #[diagnostic::on_unknown_item] attribute#152901weiznich wants to merge 1 commit intorust-lang:mainfrom
#[diagnostic::on_unknown_item] attribute#152901weiznich wants to merge 1 commit intorust-lang:mainfrom
Conversation
Collaborator
|
Some changes occurred in compiler/rustc_passes/src/check_attr.rs |
rustbot
added
A-attributes
Collaborator
|
r? @nnethercote rustbot has assigned @nnethercote. Use Why was this reviewer chosen?The reviewer was selected based on:
|
This comment has been minimized.
This comment has been minimized.
weiznich
force-pushed
the
feature/on_unknown_item
branch
from
5c63f6f to
a9dd689
Compare
This comment has been minimized.
This comment has been minimized.
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.
weiznich
force-pushed
the
feature/on_unknown_item
branch
from
a9dd689 to
c87fc9e
Compare
Contributor
Contributor
Author
|
I can try this, although I need to read up on how the new infrastructure works and check if it's possible to use this inside of the name resolution stage. Somehow certain things (like lints) act weirdly there. |
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.
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
tabemodule. 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:sin the end)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 #152900 and #128674