aboutsummaryrefslogtreecommitdiff
path: root/crates/hir_expand/src/db.rs
Commit message (Collapse)AuthorAgeFilesLines
* internal: move diagnostics to hirAleksey Kladov2021-05-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | The idea here is to eventually get rid of `dyn Diagnostic` and `DiagnosticSink` infrastructure altogether, and just have a `enum hir::Diagnostic` instead. The problem with `dyn Diagnostic` is that it is defined in the lowest level of the stack (hir_expand), but is used by the highest level (ide). As a first step, we free hir_expand and hir_def from `dyn Diagnostic` and kick the can up to `hir_ty`, as an intermediate state. The plan is then to move DiagnosticSink similarly to the hir crate, and, as final third step, remove its usage from the ide. One currently unsolved problem is testing. You can notice that the test which checks precise diagnostic ranges, unresolved_import_in_use_tree, was moved to the ide layer. Logically, only IDE should have the infra to render a specific range. At the same time, the range is determined with the data produced in hir_def and hir crates, so this layering is rather unfortunate. Working on hir_def shouldn't require compiling `ide` for testing.
* Merge #8977bors[bot]2021-05-241-1/+1
|\ | | | | | | | | | | | | | | 8977: internal: minor `TokenMap` cleanups r=jonas-schievink a=jonas-schievink bors r+ Co-authored-by: Jonas Schievink <[email protected]>
| * Make `TokenTextRange` privateJonas Schievink2021-05-241-1/+1
| |
* | internal: rename hypothetical -> speculativeAleksey Kladov2021-05-241-7/+7
|/ | | | | Lets steal this good naming from Roslyn before I forget about it yet again.
* Clarify field nameJonas Schievink2021-05-191-1/+1
|
* Simplify eager macro representationJonas Schievink2021-05-191-81/+39
|
* Remove delimiters from proc macro inputJonas Schievink2021-05-121-1/+10
|
* Rewrite `#[derive]` removal to be based on ASTJonas Schievink2021-05-101-3/+4
|
* Precompute macro fragment kindJonas Schievink2021-05-091-60/+11
|
* Fix buildDawer2021-05-061-1/+1
|
* Document expansion queriesAleksey Kladov2021-05-041-0/+21
|
* simplify macro expansion codeAleksey Kladov2021-05-041-27/+17
| | | | | Using `Option` arguments such that you always pass `None` or `Some` at the call site is a code smell.
* make illegal states unrepresentableAleksey Kladov2021-05-041-32/+28
| | | | only declarative macros have def-site token map
* CleanupsAleksey Kladov2021-05-041-139/+134
|
* Merge #8727bors[bot]2021-05-041-11/+11
|\ | | | | | | | | | | | | | | | | 8727: minor: use standard import style r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * minor: use standard import styleAleksey Kladov2021-05-041-11/+11
| |
* | Merge #8726bors[bot]2021-05-041-3/+3
|\| | | | | | | | | | | | | | | | | 8726: internal: reduce visibility r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * internal: reduce visibilityAleksey Kladov2021-05-041-3/+3
| |
* | minor: unconfuse myself about macro def vs macro rulesAleksey Kladov2021-05-041-0/+5
|/
* hir_ty: Expand macros at type positioncynecx2021-04-171-0/+1
|
* Support macros in pattern positionJonas Schievink2021-04-111-0/+1
|
* Revert "Rewrite `#[derive]` removal to be based on AST"Jonas Schievink2021-04-101-4/+3
| | | | This reverts commit 7e78aebc8fbbb4043d62949681e4d700f1a2ec46.
* Rewrite `#[derive]` removal to be based on ASTJonas Schievink2021-04-091-3/+4
|
* Make `ast_to_token_tree` infallibleJonas Schievink2021-04-041-10/+4
| | | | It could never return `None`, so reflect that in the return type
* Basic Support Macro 2.0Edwin Cheng2021-03-271-21/+39
|
* Fix recursive macro statement expansionEdwin Cheng2021-03-251-17/+42
|
* remove more redundant clones (clippy::redundant_clone())Matthias Krüger2021-03-211-1/+1
|
* Store an `AstId` for procedural macrosJonas Schievink2021-03-181-2/+2
|
* Make MacroDefId's `AstId` mandatory when possibleJonas Schievink2021-03-181-5/+5
|
* Fix macro expansion for statements w/o semicolonEdwin Cheng2021-03-161-1/+2
|
* add expand logEdwin Cheng2021-03-131-0/+2
|
* :arrow_up: rowanAleksey Kladov2021-01-191-1/+1
|
* Remove useless wrapperAleksey Kladov2021-01-151-1/+1
|
* Fixed typos in code commentsVincent Esche2021-01-091-1/+1
|
* Proper handling $crate Take 2Edwin Cheng2021-01-071-3/+9
|
* Fix infer error of macro invocation in array exprEdwin Cheng2021-01-021-1/+1
|
* Pass crate environment to proc macrosJonas Schievink2020-12-271-1/+1
|
* Store invocation site for eager macrosJonas Schievink2020-12-221-4/+5
|
* Basic support for decl macros 2.0Jonas Schievink2020-12-151-1/+4
|
* Remove obsolete commentEdwin Cheng2020-12-151-1/+0
|
* Expand statements for mbe in loweringEdwin Cheng2020-12-151-1/+2
|
* 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
|
* Make `compile_error!` lazy and emit a diagnosticJonas Schievink2020-12-031-0/+1
|
* builtin_macro: move to `mbe::ExpandResult`Jonas Schievink2020-11-301-1/+1
|
* Merge #6645bors[bot]2020-11-281-1/+8
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-271-1/+8
| |
* | Add/Fix macro expansion profilingJonas Schievink2020-11-271-2/+4
|/
* Use `ExpandResult` instead of `MacroResult`Jonas Schievink2020-11-261-52/+28
| | | | `MacroResult` is redundant