aboutsummaryrefslogtreecommitdiff
path: root/crates/hir_expand/src
Commit message (Collapse)AuthorAgeFilesLines
...
| * Remove obsolete commentEdwin Cheng2020-12-151-1/+0
| |
| * Expand statements for mbe in loweringEdwin Cheng2020-12-151-1/+2
| |
* | Resolve `macro-error` diagnostics on asm & llvm_asmlf-2020-12-152-0/+17
| | | | | | | | | | | | | | | | | | We currently stub these out as returning unit. This fixes spurious RA diagnostics in the following: ```rust unsafe { asm!(""); llvm_asm!(""); } ```
* | Implement `module_path!()`Jonas Schievink2020-12-142-0/+11
|/
* Add Lifetimes to the HIRLukas Wirth2020-12-111-1/+6
|
* Use decimal notationJonas Schievink2020-12-101-1/+1
|
* Double the macro token limitJonas Schievink2020-12-101-1/+1
|
* Improve macro limit error and move to constJonas Schievink2020-12-101-3/+9
|
* format_args: handle key-value argumentsJonas Schievink2020-12-101-0/+6
|
* Introduce anchored_pathAleksey Kladov2020-12-092-5/+6
| | | | | They allow to represent paths like `#[path = "C:\path.rs"] mod foo;` in a lossless cross-platform & network-transparent way.
* Fix `concat!` with integer literalsJonas Schievink2020-12-081-8/+34
|
* Fix logic for determining macro callsJonas Schievink2020-12-081-9/+7
| | | | | | I believe this currently goes back all the way to the initial user-written call, but that seems better than the current broken behavior.
* Make `original_range` a method on `InFile<&SyntaxNode>`Jonas Schievink2020-12-081-3/+69
|
* Use the right `def_crate` for builtin macrosJonas Schievink2020-12-071-1/+1
|
* Remove resolved FIXMEJonas Schievink2020-12-071-1/+0
|
* Make `compile_error!` message match upstream rustcJonas Schievink2020-12-031-4/+1
| | | | It only consists of the argument passed to it
* Fix proc macro token mappingJonas Schievink2020-12-031-6/+16
|
* Rename `error_sink` to `diagnostic_sink`Jonas Schievink2020-12-031-11/+12
|
* Make `compile_error!` lazy and emit a diagnosticJonas Schievink2020-12-032-21/+28
|
* Give better diagnostic if `OUT_DIR` is unsetJonas Schievink2020-12-031-9/+17
|
* Propagate eager expansion errorsJonas Schievink2020-12-031-16/+99
|
* builtin_macro: move to `mbe::ExpandResult`Jonas Schievink2020-11-303-52/+81
|
* Merge #6659bors[bot]2020-11-281-2/+7
|\ | | | | | | | | | | | | | | | | 6659: Explain how we get precise spans for diagnostics. r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * Explain how we get precise spans for diagnostics.Aleksey Kladov2020-11-281-2/+7
| |
* | Merge #6645bors[bot]2020-11-283-3/+10
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6645: Publish diagnostics for macro expansion errors r=matklad a=jonas-schievink This adds 2 new diagnostics, emitted during name resolution: * `unresolved-proc-macro`, a weak warning that is emitted when a proc macro is supposed to be expanded, but was not provided by the build system. This usually means that proc macro support is turned off, but may also indicate setup issues when using rust-project.json. Being a weak warning, this should help set expectations when users see it, while not being too obstructive. We do not yet emit this for attribute macros though, just custom derives and `!` macros. * `macro-error`, which is emitted when any macro (procedural or `macro_rules!`) fails to expand due to some error. This is an error-level diagnostic, but currently still marked as experimental, because there might be spurious errors and this hasn't been tested too well. This does not yet emit diagnostics when expansion in item bodies fails, just for module-level macros. Known bug: The "proc macro not found" diagnostic points at the whole item for custom derives, it should just point at the macro's name in the `#[derive]` list, but I haven't found an easy way to do that. Screenshots: ![screenshot-2020-11-26-19:54:14](https://user-images.githubusercontent.com/1786438/100385782-f8bc2300-3023-11eb-9f27-e8f8ce9d6114.png) ![screenshot-2020-11-26-19:55:39](https://user-images.githubusercontent.com/1786438/100385784-f954b980-3023-11eb-9617-ac2eb0a0a9dc.png) Co-authored-by: Jonas Schievink <[email protected]>
| * Publish diagnostics for macro expansion errorsJonas Schievink2020-11-272-2/+9
| |
| * Add dedicated error for "proc macro not found"Jonas Schievink2020-11-271-1/+1
| |
* | Add/Fix macro expansion profilingJonas Schievink2020-11-271-2/+4
|/
* Use `ExpandResult` instead of `MacroResult`Jonas Schievink2020-11-262-52/+30
| | | | `MacroResult` is redundant
* Use named fields in `ExpandResult`Jonas Schievink2020-11-261-1/+1
|
* Rename `parse_macro` to `parse_macro_expansion`Jonas Schievink2020-11-242-4/+4
| | | | This does not parse macros, it expands a macro and parses the *result*
* hir_expand::db: reduce fn visibilityJonas Schievink2020-11-241-15/+9
|
* Remove fixed FIXME, propagate errors betterJonas Schievink2020-11-241-6/+2
|
* hir_expand: propagate expansion errorsJonas Schievink2020-11-242-41/+84
|
* Fill the diagnostic code field in publish_diagnosticsLukas Wirth2020-11-171-1/+1
|
* SimplifyAleksey Kladov2020-11-061-1/+1
|
* Remove more unreachable pubsAleksey Kladov2020-11-021-1/+1
|
* Fix typo in commentFrancesco Zardi2020-10-211-1/+1
|
* Add whitelist of safe intrinsicsFrancesco Zardi2020-10-211-0/+36
|
* Complete methods when receiver is a macroAleksey Kladov2020-10-171-0/+1
|
* Shorten type hints for std::iter IteratorsLukas Wirth2020-10-061-0/+1
|
* Merge #6033bors[bot]2020-09-281-14/+25
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]>
| * Use hir_def to resolve proc macrosJonas Schievink2020-09-181-14/+25
| |
* | Bump smol_str from 0.1.16 to 0.1.17Jean SIMARD2020-09-241-5/+5
|/
* Rename `CustomDerive` to `ProcMacro`Jonas Schievink2020-09-184-5/+5
| | | | | It handles fn-like macros too, and will handle attribute macros in the future
* Bump token expansion limitAleksey Kladov2020-09-011-1/+1
| | | | | | | 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/
* Add type safety to diagnostic codesAleksey Kladov2020-08-181-1/+10
|
* Merge branch 'master' into add-disable-diagnosticsIgor Aleksanov2020-08-141-0/+1
|
* Rename ra_hir_expand -> hir_expandAleksey Kladov2020-08-1312-0/+2994
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-24 08:11:13 +0000