aboutsummaryrefslogtreecommitdiff
path: root/crates/ra_hir_def/src/diagnostics.rs
diff options
context:
space:
mode:
authorbors[bot] <26634292+bors[bot]@users.noreply.github.com>2020-04-30 11:17:40 +0100
committerGitHub <[email protected]>2020-04-30 11:17:40 +0100
commit95e8766db60be2a00bce9978e2680a769771a546 (patch)
treeadd99db171c000d164056c56885ea2ce0741eaa6 /crates/ra_hir_def/src/diagnostics.rs
parentc2425fd88b13b8aeaaaca4e4933a647526f8511f (diff)
parent0af727da91e7ff3c8ed5518cb7e005e8d4f939b0 (diff)
Merge #4178
4178: Validate the location of `crate` in paths r=matklad a=djrenren **This solution does not fully handle `use` statements. See below** This pull requests implements simple validation of usages of the `crate` keyword in `Path`s. Specifically it validates that: - If a `PathSegment` is starts with the `crate` keyword, it is also the first segment of the `Path` - All other usages of `crate` in `Path`s are considered errors. This aligns with `rustc`'s rules. Unlike rustc this implementation does not issue a special error message in the case of `::crate` but it does catch the error. Furthermore, this change does not cover all error cases. Specifically the following is not caught: ```rust use foo::{crate} ``` This is because this check is context sensitive. From an AST perspective, `crate` is the root of the `Path`. Only by inspecting the full `UseItem` do we see that it is not in fact the root. This problem becomes worse because `UseTree`s are allowed to be arbitrarily nested: ```rust use {crate, {{crate, foo::{crate}}} ``` So this is a hard problem to solve without essentially a breadth-first search. In a traditional compiler, I'd say this error is most easily found during the AST -> HIR conversion pass but within rust-analyzer I'm not sure where it belongs. Under the implementation in this PR, such errors are ignored so we're *more correct* just not *entirely correct*. Co-authored-by: John Renner <[email protected]>
Diffstat (limited to 'crates/ra_hir_def/src/diagnostics.rs')
0 files changed, 0 insertions, 0 deletions