Commit Graph

459 Commits

Author SHA1 Message Date
Lukas Wirth
eac77997bf Properly fetch inner and outer attributes on hir-level 2020-12-08 23:21:20 +01:00
Jonas Schievink
306c6cbaac Use original_file_range in TestDB 2020-12-08 19:03:24 +01:00
Jonas Schievink
6c1d292569 Add test for $crate in builtin macros
Fixes #6716
2020-12-08 17:17:30 +01:00
Jonas Schievink
678c74430b Handle macros in TestDB::check_diagnostics 2020-12-08 17:16:18 +01:00
Lukas Wirth
2facd9517f Escape string literals in Attr::from_src 2020-12-08 13:47:58 +01:00
Lukas Wirth
7a338e5207 Replace Arc<[str]> with String in attr::Documentation 2020-12-07 21:55:00 +01:00
Lukas Wirth
b064f6da9e Keep doc attribute order 2020-12-07 20:38:28 +01:00
Lukas Wirth
efe86a42dc Remove raw pre and suffixes from string attr literals 2020-12-07 19:58:17 +01:00
Lukas Wirth
1caaa201fa Remove hir_def/docs.rs module 2020-12-07 19:58:17 +01:00
Lukas Wirth
b3652ef288 Remove documentation query 2020-12-07 19:58:17 +01:00
Lukas Wirth
93262c750e Don't insert blank lines between doc attributes 2020-12-07 16:10:46 +01:00
Jonas Schievink
957fb18799 Make compile_error! message match upstream rustc
It only consists of the argument passed to it
2020-12-03 19:07:37 +01:00
Jonas Schievink
3e6ffa5124 Fix proc macro token mapping 2020-12-03 18:38:05 +01:00
Jonas Schievink
883c8d177d Make compile_error! lazy and emit a diagnostic 2020-12-03 15:48:29 +01:00
Jonas Schievink
4634bfb332 Give better diagnostic if OUT_DIR is unset 2020-12-03 15:48:29 +01:00
Jonas Schievink
17542d08b4 Update/Fix tests 2020-12-03 15:48:29 +01:00
Jonas Schievink
a634243634 Propagate eager expansion errors 2020-12-03 15:48:29 +01:00
Jonas Schievink
f4866bb05c Test macro diagnostics in body lowering 2020-12-02 15:03:21 +01:00
bors[bot]
3e1fb112af
Merge #6698
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 <jonasschievink@gmail.com>
2020-12-02 13:25:54 +00:00
Jonas Schievink
319fcd01ac Attach macro expansion errors to the right file 2020-12-02 14:23:51 +01:00
bors[bot]
14086e3118
Merge #6697
6697: Don't discard PathKind::Abs information in lower_use::convert_path r=matklad a=Veykril

Fixes #6694

Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
2020-12-02 12:16:19 +00:00
Lukas Wirth
7b456552b8 Don't discard PathKind::Abs information in lower_use::convert_path 2020-12-02 09:54:03 +01:00
Jonas Schievink
ea7b81fef9 Emit unresolved proc macro errors 2020-12-01 12:40:03 +01:00
Jonas Schievink
be50908a50 Emit macro diagnostics when lowering bodies 2020-11-30 20:26:35 +01:00
Jonas Schievink
d171838d63 More accurately place proc-macro diagnostic 2020-11-27 16:29:40 +01:00
Jonas Schievink
0432aa0ed7 Publish diagnostics for macro expansion errors 2020-11-27 13:50:22 +01:00
Jonas Schievink
519d870c11 Don't store SyntaxNodePtr in CrateDefMap
It is volatile across reparses and makes incrementality worse.
2020-11-26 17:29:09 +01:00
Jonas Schievink
74cb3e96a5 Test def map invalidation with #[cfg] below change 2020-11-26 17:28:00 +01:00
Kirill Bulatov
4baac238a8 Improve autoimports on completion speed
* Ignore modules eaferly
* Do less completion string rendering
2020-11-24 02:28:45 +02:00
Aleksey Kladov
5db789df9c Cleanup API 2020-11-06 22:52:42 +01:00
Aleksey Kladov
2b108133ac Don't stack overflow on circular modules
closes #6453
2020-11-04 15:31:35 +01:00
bors[bot]
8ad01d863b
Merge #6435
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 <rickvanprim@gmail.com>
2020-11-03 16:36:34 +00:00
James Leitch
ff87726074 Feedback. 2020-11-02 10:57:31 -07:00
Aleksey Kladov
ba8d6d1e4e Remove more unreachable pubs 2020-11-02 16:58:33 +01:00
Aleksey Kladov
b610118453 Deny unreachable-pub
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.
2020-11-02 14:07:08 +01:00
James Leitch
d2d7a4403c Test Fixture ExplicitRoot + ModuleResolutionRelativePathOutsideRoot. 2020-11-01 17:20:55 -07:00
Jonas Schievink
cd3c632cfc Handle #![cfg] in crate root 2020-10-26 16:04:08 +01:00
Jonas Schievink
5350c15e27 Fix name of InactiveCode diagnostic 2020-10-23 19:31:11 +02:00
Jonas Schievink
93dc6f511b Diagnose #[cfg]s in bodies 2020-10-23 19:27:04 +02:00
bors[bot]
81609960fa
Merge #6324
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 <jonas.schievink@ferrous-systems.com>
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
2020-10-23 10:38:30 +00:00
Jonas Schievink
bfe1efca26 Use format_to
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2020-10-23 12:12:03 +02:00
Jonas Schievink
3421b645e6 Emit better #[cfg] diagnostics 2020-10-22 19:19:18 +02:00
bors[bot]
9eb6cbb80b
Merge #6307
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 <frazar@users.noreply.github.com>
2020-10-21 20:09:11 +00:00
Francesco Zardi
aff04d81ba Refactor is_intrinsic_fn_unsafe() and make it private 2020-10-21 21:53:37 +02:00
Francesco Zardi
0be21b05d6 Move safe intrinsic tests 2020-10-21 21:53:05 +02:00
Francesco Zardi
a9d996a7c5 Add whitelist of safe intrinsics 2020-10-21 09:06:05 +02:00
Jonas Schievink
3fa04f35d2 More detailed message 2020-10-20 18:23:55 +02:00
Jonas Schievink
4cb3cf352f Rename UnconfiguredCode -> InactiveCode 2020-10-20 18:22:31 +02:00
Jonas Schievink
80d2741401 Add a (hint) diagnostic for unconfigured items 2020-10-20 17:53:04 +02:00
Aleksey Kladov
af4e75533f Rename declaration_name -> display_name
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).
2020-10-20 15:38:11 +02:00
Igor Aleksanov
2a20e7795c Add descriptions for diagnostics parseable by xtask 2020-10-19 20:55:16 +03:00
Aleksey Kladov
4fe4c30436 Improve readability 2020-10-17 23:35:21 +02:00
bors[bot]
c518fe7f6c
Merge #6130 #6135
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 <popzxc@yandex.ru>
Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
2020-10-12 16:00:13 +00:00
bors[bot]
93de4918ea
Merge #6199
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 <lukastw97@gmail.com>
2020-10-12 14:24:18 +00:00
Igor Aleksanov
cfbee8d3a3 Remove previously added parameter names from the function data 2020-10-12 11:05:00 +03:00
Igor Aleksanov
b42562b5de Make incorrect case diagnostic work inside of functions 2020-10-12 11:05:00 +03:00
Igor Aleksanov
4039176ec6 Create basic support for names case checks and implement function name case check 2020-10-12 10:59:54 +03:00
bors[bot]
518f6d7724
Merge #5917
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 <zacmps@gmail.com>
2020-10-12 07:38:24 +00:00
Lukas Wirth
9909ccb4f4 Fix mut self not emitting mutable binding on self use 2020-10-11 18:39:03 +02:00
Jonas Schievink
5dcbf03d0f adt: correctly inherit field visibility from enum
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.
2020-10-09 20:46:45 +02:00
Zac Pullar-Strecker
ec75d8bd75 Update tests for new function field 2020-10-08 15:04:57 +13:00
Zac Pullar-Strecker
c648884397 Differentiate method/tymethod by determining 'defaultness'
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.
2020-10-08 15:04:21 +13:00
Aleksey Kladov
801e5b453c Add test makr 2020-10-06 19:20:56 +02:00
Aleksey Kladov
0d3bc38577 Constrain ImportMap to only store simple paths 2020-10-06 17:04:29 +02:00
Aleksey Kladov
2090b534fc Move ModPath->ast::Path function to IDE layer
closes #6092
2020-10-06 16:19:18 +02:00
bors[bot]
87cb840a4e
Merge #6124
6124: Better normalized crate name usage r=jonas-schievink a=SomeoneToIgnore

Closes https://github.com/rust-analyzer/rust-analyzer/issues/5343 
Closes https://github.com/rust-analyzer/rust-analyzer/issues/5932

Uses normalized name for code snippets (to be able to test the fix), hover messages and documentation rewrite links (are there any tests for those?).
Also renamed the field to better resemble the semantics.

Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
2020-10-06 11:51:15 +00:00
bors[bot]
af0e54a566
Merge #6139
6139: Make find_path_prefixed configurable r=matklad a=Veykril

This makes `find_path_prefixed` more configurable allowing one to choose whether it always returns absolute paths, self-prefixed paths or to ignore local imports when building the path. 

The config names are just thrown in here, taking better names if they exist :)

This should fix #6131 as well?

Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
2020-10-06 11:43:08 +00:00
Jonas Schievink
8ab7696acd Account for proc macro helpers when parsing attr 2020-10-05 23:41:16 +02:00
Lukas Wirth
67e71619b9 Make find_path_prefixed configurable 2020-10-05 17:12:37 +02:00
Kirill Bulatov
9d19e5b962 Properly name the field 2020-10-02 21:38:22 +03:00
bors[bot]
18c62c8a39
Merge #6019
6019: Remove make::path_from_text r=matklad a=Veykril

This removes the `make::path_from_text` function, which according to a note should've been private. I removed it since it didn't really serve a purpose as it was simply wrapping `make::ast_from_text`.

Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
2020-09-29 10:29:33 +00:00
bors[bot]
0fb5d9d87a
Merge #6033
6033: Make name resolution resolve proc macros instead of relying purely on the build system r=matklad a=jonas-schievink

This makes name resolution look at proc-macro declaration attributes like `#[proc_macro_derive]` and defines the right proc macro in the macro namespace, fixing unresolved custom derives like `thiserror::Error` (which can cause false positives, now that we emit diagnostics for unresolved imports).

This works even when proc-macro support is turned off, in which case we fall back to a dummy expander that always returns an error. IMO this is the right way to handle at least the name resolution part of proc. macros, while the *expansion* itself should rely on the build system to build and provide the macro DLL. It does mean that they may go out of sync, but we can provide diagnostics if that happens (something like "could not find macro X in crate Y – ensure that all files of crate Y are saved").

I think it is valuable to be able to reason about proc macros even when we can't expand them, since proc macro expansion can break between Rust releases or users might not want to turn it on for performance reasons. It allows us to provide better diagnostics on any proc macro invocation we're not expanding (like a weak warning that informs the user that proc macro support is turned off, or that it has been disabled because the server crashed).

Fixes https://github.com/rust-analyzer/rust-analyzer/issues/5763

Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
2020-09-28 11:03:47 +00:00
Jonas Schievink
e88e4fbb7b Add more comments about proc macro resolution 2020-09-28 13:02:28 +02:00
Jonas Schievink
e799dbe5d7 Simplify iterator chain 2020-09-28 12:51:40 +02:00
bors[bot]
000046cfa0
Merge #6085
6085: Mark unresolved imports diagnostic as experimental r=jonas-schievink a=jonas-schievink

It causes a lot of false positives for people. We collected all of the known ones during the last week.

Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
2020-09-28 10:47:33 +00:00
Jonas Schievink
f0b5832cb8 Mark unresolved imports diagnostic as experimental 2020-09-28 12:45:20 +02:00
Lukas Wirth
e1d6981f90 Don't unnecessarily unnest imports for import insertion 2020-09-25 15:19:22 +02:00
Jonas Schievink
7474a42b00 Remove incorrect docs 2020-09-18 18:09:47 +02:00
Jonas Schievink
baab72e611 Reduce visibility of non-proc-macros
proc-macro crates only export proc-macros, but currently other items
are also considered public (and show up in completion)
2020-09-18 17:50:04 +02:00
Jonas Schievink
069045015c Remove obsolete proc macro collection code
The new attribute-based resolution takes care of this
2020-09-18 16:52:24 +02:00
Jonas Schievink
5486b70bc0 Use hir_def to resolve proc macros 2020-09-18 16:43:50 +02:00
Jonas Schievink
dfa3a3f017 Add test 2020-09-18 16:37:12 +02:00
Jonas Schievink
9dc0afe854 Rename CustomDerive to ProcMacro
It handles fn-like macros too, and will handle attribute macros in the
future
2020-09-18 15:37:31 +02:00
Jonas Schievink
700a3d5d75 Invert condition to unindent code 2020-09-18 12:32:07 +02:00
Jonas Schievink
6eea06415d Give ExternCrate a Name, not a ModPath 2020-09-17 15:28:23 +02:00
bors[bot]
933fc1eb18
Merge #6016
6016: Emit diagnostics for unresolved imports and extern crates r=jonas-schievink a=jonas-schievink

AFAIK, we don't have any major bugs in name resolution that would cause a lot of false positives here (except procedural attribute macro support and some rare issues around `#[path]` on module files), so these are *not* marked as experimental diagnostics right now.

I noticed that diagnostics in a file sometimes don't get displayed after opening, but require some edit to be performed. This seems like a preexisting issue though.

Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
2020-09-17 13:00:25 +00:00
Jonas Schievink
0dca7acf0f Don't diagnose imports whose base crate is missing 2020-09-17 14:48:17 +02:00
Lukas Wirth
f2ae412ccf Remove make::path_from_text 2020-09-16 21:36:10 +02:00
Jonas Schievink
f792bc7ddd Add annotation-based nameres diagnostic tests 2020-09-16 17:26:51 +02:00
Jonas Schievink
4785162b08 Track import sources and emit diagnostics 2020-09-16 17:26:51 +02:00
Jonas Schievink
4ac9a2e5d3 Leave extern crate items unresolved if they are 2020-09-16 17:26:51 +02:00
Jonas Schievink
2a9a66d254 Add diagnostic types for unresolved crates/imports 2020-09-16 17:26:51 +02:00
Charles Lew
389d9a6c2d Lower extern type alias as foreign opaque type. 2020-09-16 20:57:14 +08:00
Jonas Schievink
44f4510caa Store Import indices for later reconstruction 2020-09-16 12:35:09 +02:00
Charles Lew
b302f69b7c Update chalk to 0.27 and adapt to chalk changes. 2020-09-15 22:37:05 +08:00
bors[bot]
0d03fe6ef5
Merge #5971
5971: Implement async blocks r=flodiebold a=oxalica

Fix #4018

@flodiebold already gave a generic guide in the issue. Here's some concern about implementation detail:
- Chalk doesn't support generator type yet.
- Adding generator type as a brand new type (ctor) can be complex and need to *re-introduced* builtin impls. (Like how we implement closures before native closure support of chalk, which is already removed in #5401 )
- The output type of async block should be known after type inference of the whole body.
  - We cannot directly get the type from source like return-positon-impl-trait. But we still need to provide trait bounds when chalk asking for `opaque_ty_data`.
  - During the inference, the output type of async block can be temporary unknown and participate the later inference.
    `let a = async { None }; let _: i32 = a.await.unwrap();`

So in this PR, the type of async blocks is inferred as an opaque type parameterized by the `Future::Output` type it should be, like what we do with closure type.
And it really works now.

Well, I still have some questions:
- The bounds `AsyncBlockImplType<T>: Future<Output = T>` is currently generated in `opaque_ty_data`. I'm not sure if we should put this code here.
- Type of async block is now rendered as `impl Future<Output = OutputType>`. Do we need to special display to hint that it's a async block? Note that closure type has its special format, instead of `impl Fn(..) -> ..` or function type.



Co-authored-by: oxalica <oxalicc@pm.me>
2020-09-13 17:28:22 +00:00
Jonas Schievink
07a704e31c Implement box pattern inference 2020-09-12 21:18:57 +02:00
oxalica
251ef93ac3
Implement async blocks 2020-09-10 20:01:23 +08:00
Aleksey Kladov
c692b5d76d ⬆️ expect-test 2020-08-28 14:47:14 +02:00
Jonas Schievink
f3ac19e8cd Support extern types 2020-08-24 22:02:55 +02:00
Pavan Kumar Sunkara
335add49db Add description for crates that will be published 2020-08-24 13:07:22 +02:00
Pavan Kumar Sunkara
a8fa5cd42e Add version to deps in cargo.toml 2020-08-24 11:10:41 +02:00
Aleksey Kladov
863b1fb731 ⬆️ ungrammar 2020-08-21 19:14:05 +02:00
Aleksey Kladov
b0fd3faf36 Switch to expect_test from crates.io 2020-08-21 13:19:31 +02:00
Aleksey Kladov
8146669542 Add type safety to diagnostic codes 2020-08-18 18:39:43 +02:00
bors[bot]
b8dfc331ab
Merge #5682
5682: Add an option to disable diagnostics r=matklad a=popzxc

As far as I know, currently it's not possible to disable a selected type of diagnostics provided by `rust-analyzer`.

This causes an inconvenient situation with a false-positive warnings: you either have to disable all the diagnostics, or you have to ignore these warnings.

There are some open issues related to this problem, e.g.: https://github.com/rust-analyzer/rust-analyzer/issues/5412, https://github.com/rust-analyzer/rust-analyzer/issues/5502

This PR attempts to make it possible to selectively disable some diagnostics on per-project basis.

Co-authored-by: Igor Aleksanov <popzxc@yandex.ru>
2020-08-18 12:04:49 +00:00
Aleksey Kladov
2052d33b9b Remove deprecated Path::from_ast
Long term, we probably should make hir::Path private to hir.
2020-08-15 18:22:16 +02:00
Igor Aleksanov
c26c911ec1 Merge branch 'master' into add-disable-diagnostics 2020-08-14 07:34:07 +03:00
Aleksey Kladov
b28c54a2c2 Rename ra_hir_def -> hir_def 2020-08-13 16:29:33 +02:00