aboutsummaryrefslogtreecommitdiff
path: root/crates/hir_def
Commit message (Collapse)AuthorAgeFilesLines
* Give better diagnostic if `OUT_DIR` is unsetJonas Schievink2020-12-031-0/+3
|
* Update/Fix testsJonas Schievink2020-12-031-4/+15
|
* Propagate eager expansion errorsJonas Schievink2020-12-032-17/+54
|
* Test macro diagnostics in body loweringJonas Schievink2020-12-021-0/+41
|
* Merge #6698bors[bot]2020-12-021-2/+5
|\ | | | | | | | | | | | | | | | | | | | | | | 6698: Attach macro expansion errors to the right file r=jonas-schievink a=jonas-schievink Previously it attached them to the result of the macro expansion (or, if no result was produced, to the file containing the invocation). Always use the file containing the invocation. This doesn't seem to have any observable difference, but seems better in theory. bors r+ Co-authored-by: Jonas Schievink <[email protected]>
| * Attach macro expansion errors to the right fileJonas Schievink2020-12-021-2/+5
| |
* | Merge #6697bors[bot]2020-12-022-1/+22
|\ \ | |/ |/| | | | | | | | | | | 6697: Don't discard PathKind::Abs information in lower_use::convert_path r=matklad a=Veykril Fixes #6694 Co-authored-by: Lukas Wirth <[email protected]>
| * Don't discard PathKind::Abs information in lower_use::convert_pathLukas Wirth2020-12-022-1/+22
| |
* | Emit unresolved proc macro errorsJonas Schievink2020-12-012-9/+28
| |
* | Emit macro diagnostics when lowering bodiesJonas Schievink2020-11-304-27/+68
|/
* More accurately place proc-macro diagnosticJonas Schievink2020-11-272-4/+42
|
* Publish diagnostics for macro expansion errorsJonas Schievink2020-11-273-4/+137
|
* Don't store `SyntaxNodePtr` in `CrateDefMap`Jonas Schievink2020-11-262-8/+7
| | | | It is volatile across reparses and makes incrementality worse.
* Test def map invalidation with #[cfg] below changeJonas Schievink2020-11-261-0/+6
|
* Improve autoimports on completion speedKirill Bulatov2020-11-241-5/+77
| | | | | * Ignore modules eaferly * Do less completion string rendering
* Cleanup APIAleksey Kladov2020-11-061-10/+11
|
* Don't stack overflow on circular modulesAleksey Kladov2020-11-044-18/+62
| | | | closes #6453
* Merge #6435bors[bot]2020-11-031-2/+15
|\ | | | | | | | | | | | | | | 6435: Test Fixture ExplicitRoot + ModuleResolutionRelativePathOutsideRoot. r=matklad a=rickvanprim Updates `module_resolution_relative_path_outside_root` test to check valid paths outside of the root, by moving the root to a subpath so that paths outside of it are possible. If this would be more appropriate as a new test, or if the original check for an invalid path should be left, I'm happy to update. Co-authored-by: James Leitch <[email protected]>
| * Feedback.James Leitch2020-11-021-1/+1
| |
| * Test Fixture ExplicitRoot + ModuleResolutionRelativePathOutsideRoot.James Leitch2020-11-021-2/+15
| |
* | Remove more unreachable pubsAleksey Kladov2020-11-021-2/+2
| |
* | Deny unreachable-pubAleksey Kladov2020-11-024-20/+20
| | | | | | | | | | | | | | | | It's very useful when `pub` is equivalent to "this is crate's public API", let's enforce this! Ideally, we should enforce it for local `cargo test`, and only during CI, but that needs https://github.com/rust-lang/cargo/issues/5034.
* | Handle #![cfg] in crate rootJonas Schievink2020-10-262-2/+22
|/
* Fix name of InactiveCode diagnosticJonas Schievink2020-10-231-1/+1
|
* Diagnose #[cfg]s in bodiesJonas Schievink2020-10-237-94/+213
|
* Merge #6324bors[bot]2020-10-235-23/+75
|\ | | | | | | | | | | | | | | | | 6324: Improve #[cfg] diagnostics r=jonas-schievink a=jonas-schievink Unfortunately I ran into https://github.com/rust-analyzer/rust-analyzer/issues/4058 while testing this on https://github.com/nrf-rs/nrf-hal/, so I didn't see much of it in action yet, but it does seem to work. Co-authored-by: Jonas Schievink <[email protected]> Co-authored-by: Jonas Schievink <[email protected]>
| * Use format_toJonas Schievink2020-10-231-4/+3
| | | | | | | | Co-authored-by: Aleksey Kladov <[email protected]>
| * Emit better #[cfg] diagnosticsJonas Schievink2020-10-225-21/+74
| |
* | Merge #6307bors[bot]2020-10-211-2/+45
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | 6307: Add whitelist of safe intrinsics r=frazar a=frazar This PR should fix #5996, where intrinsic operations where all marked as unsafe. I'm rather new to this codebase, so I might be doing something *very* wrong. Please forgive me! In particular, I'm not sure how to "check that we are in extern `rust-intrinsics`" as mentioned [in this comment](https://github.com/rust-analyzer/rust-analyzer/issues/5996#issuecomment-709234802). Co-authored-by: Francesco Zardi <[email protected]>
| * Refactor is_intrinsic_fn_unsafe() and make it privateFrancesco Zardi2020-10-211-39/+42
| |
| * Move safe intrinsic testsFrancesco Zardi2020-10-211-20/+0
| |
| * Add whitelist of safe intrinsicsFrancesco Zardi2020-10-212-2/+62
| |
* | More detailed messageJonas Schievink2020-10-201-1/+1
| |
* | Rename UnconfiguredCode -> InactiveCodeJonas Schievink2020-10-202-4/+4
| |
* | Add a (hint) diagnostic for unconfigured itemsJonas Schievink2020-10-204-1/+70
| |
* | Rename declaration_name -> display_nameAleksey Kladov2020-10-202-8/+4
| | | | | | | | | | | | | | | | Declaration names sounds like a name of declaration -- something you can use for analysis. It empathically isn't, and is just a label displayed in various UI. It's important not to confuse the two, least we accidentally mix semantics with UI (I believe, there's already a case of this in the FamousDefs at least).
* | Add descriptions for diagnostics parseable by xtaskIgor Aleksanov2020-10-191-0/+9
|/
* Improve readabilityAleksey Kladov2020-10-171-2/+4
|
*-. Merge #6130 #6135bors[bot]2020-10-121-0/+6
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6130: Items case quick fix (snake_case / UPPER_SNAKE_CASE / CamelCase) r=matklad a=popzxc Resolves #4598. After a third try, it finally works. Boy, it appeared tougher than it seemed. Initially I thought like "Ha, `rustc` already tells us where idents are named incorrectly. It shouldn't be that hard, should it?". Well, the problems with the information provided by `rustc` appeared shortly: - `rustc` warnings are `flycheck` warnings, which are slightly aside from our diagnostics with fixes. When we map flycheck diagnostic to LSP, we can convert it into a fix, but only if it's marked as `Applicability::MachineApplicable`. Name case fix is marked `Applicability::MaybeIncorrect`, and for a reason: it only suggest to rename symbol under cursor, without tracking any references. - Warning spawned by `rustc` are identified by string labels rather than enum. It means that if one day the diagnostic will be renamed in `rustc`, `rust-analyzer` code will still compile, but won't find the required diagnostic by name anymore. If by chance this will happen when some unlucky guy will decide to create their first pull request, they'll be confused by suddenly failing tests (likely) not related to their changes. - Even if we'll try to build fixes atop of `rustc` warnings, we'll have to do it in the `rust_analyzer::diagnostics::to_proto` module, which is far less convenient for that matter than `ide` crate. That's why I decided that it's worth a separate `rust-analyzer` diagnostic, which will implement `DiagnosticWithFix` trait. After that, I discovered that currently `hir_ty::diagnostics` only check `DefWithBody` types, like function bodies. I had to add support for diagnostics which look at any `ModuleDef`. And of course, since I'd added a lot of new functionality, it required extensive testing. That explains why the diff is so big for a (looking) relatively small feature. I hope that this PR doesn't only add a small feature, but also creates a base for building another features. ## Example: ![case_quick_fix](https://user-images.githubusercontent.com/12111581/95008475-e07ee780-0622-11eb-9978-62a9ea0e7782.gif) P.S. My eyes were bleeding when I had to write the code for the example... 6135: when generating new function, focus on return type instead of body r=matklad a=bnjjj I made a little change when we use the assist to generate a new function, instead of focusing on the function body, it will focus on return type Co-authored-by: Igor Aleksanov <[email protected]> Co-authored-by: Benjamin Coenen <[email protected]>
| * | Remove previously added parameter names from the function dataIgor Aleksanov2020-10-123-18/+0
| | |
| * | Make incorrect case diagnostic work inside of functionsIgor Aleksanov2020-10-121-0/+6
| | |
| * | Create basic support for names case checks and implement function name case ↵Igor Aleksanov2020-10-123-0/+18
| | | | | | | | | | | | check
* | | Merge #6199bors[bot]2020-10-121-1/+4
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | 6199: Fix `mut self` not emitting mutable binding on `self` use r=matklad a=Veykril Prior to this, when `self` in a function is taken by value and bound mutably, its use inside of the method body won't be marked `mutably`. Fixes #5461 Co-authored-by: Lukas Wirth <[email protected]>
| * | Fix `mut self` not emitting mutable binding on `self` useLukas Wirth2020-10-111-1/+4
| |/
* | Merge #5917bors[bot]2020-10-124-12/+18
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 5917: Add a command to open docs for the symbol under the cursor r=matklad a=zacps #### Todo - [ ] Decide if there should be a default keybind or context menu entry - [x] Figure out how to get the documentation path for methods and other non-top-level defs - [x] Design the protocol extension. In future we'll probably want parameters for local/remote documentation URLs, so that should maybe be done in this PR? - [x] Code organisation - [x] Tests Co-authored-by: Zac Pullar-Strecker <[email protected]>
| * | Update tests for new function fieldZac Pullar-Strecker2020-10-081-12/+12
| | |
| * | Differentiate method/tymethod by determining 'defaultness'Zac Pullar-Strecker2020-10-083-0/+6
| |/ | | | | | | | | | | | | | | | | Currently a method only has defaultness if it is a provided trait method, but this will change when specialisation is available and may need to become a concept known to hir. I opted to go for a 'fewest changes' approach given specialisation is still under development.
* / adt: correctly inherit field visibility from enumJonas Schievink2020-10-091-9/+19
|/ | | | | | | Previously, "find all references" on a variant field wouldn't find any references outside the defining module. This is because variant fields were incorrectly assumed to be private, like struct fields without explicit visibility, but they actually inherit the enum's visibility.
* Add test makrAleksey Kladov2020-10-061-0/+2
|
* Constrain ImportMap to only store simple pathsAleksey Kladov2020-10-061-10/+26
|
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-23 05:41:15 +0000