Commit Graph

221 Commits

Author SHA1 Message Date
Jonas Schievink
9559bce311 Rename parse_macro to parse_macro_expansion
This does not parse macros, it expands a macro and parses the *result*
2020-11-24 21:57:51 +01:00
Jonas Schievink
f9d0d51101 hir_expand::db: reduce fn visibility 2020-11-24 21:55:08 +01:00
Jonas Schievink
9a3bb19d32 Remove fixed FIXME, propagate errors better 2020-11-24 21:52:19 +01:00
Jonas Schievink
d5e9bf80f9 hir_expand: propagate expansion errors 2020-11-24 19:00:23 +01:00
Lukas Wirth
c868f0255f Fill the diagnostic code field in publish_diagnostics 2020-11-17 16:23:53 +01:00
Aleksey Kladov
6158304f8b Simplify 2020-11-06 22:30:58 +01:00
Aleksey Kladov
ba8d6d1e4e Remove more unreachable pubs 2020-11-02 16:58:33 +01:00
Francesco Zardi
f3aa44b01d Fix typo in comment 2020-10-21 21:51:53 +02:00
Francesco Zardi
a9d996a7c5 Add whitelist of safe intrinsics 2020-10-21 09:06:05 +02:00
Aleksey Kladov
13451d3dc4 Complete methods when receiver is a macro 2020-10-17 23:43:13 +02:00
Lukas Wirth
aaa3905fdd Shorten type hints for std::iter Iterators 2020-10-06 19:20:42 +02: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
Jean SIMARD
875ad9b5c4
Bump smol_str from 0.1.16 to 0.1.17 2020-09-24 16:39:08 +02:00
Jonas Schievink
5486b70bc0 Use hir_def to resolve proc macros 2020-09-18 16:43:50 +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
Aleksey Kladov
7f54ded71b Bump token expansion limit
We hit this for redis crate, reported at

Reported at
https://www.reddit.com/r/rust/comments/ikfsf8/rustanalyzer_doesnt_work_with_the_redis_crate/
2020-09-01 14:55:41 +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
8146669542 Add type safety to diagnostic codes 2020-08-18 18:39:43 +02:00
Igor Aleksanov
c26c911ec1 Merge branch 'master' into add-disable-diagnostics 2020-08-14 07:34:07 +03:00
Aleksey Kladov
b7aa4898e0 Rename ra_hir_expand -> hir_expand 2020-08-13 16:29:33 +02:00