aboutsummaryrefslogtreecommitdiff
path: root/crates/hir_def/src/body
Commit message (Collapse)AuthorAgeFilesLines
* internal: check that coverage marks are always pairedAleksey Kladov2021-06-131-5/+5
|
* clippy::useless_returnMaan20032021-06-131-1/+1
|
* clippy::redudant_borrowMaan20032021-06-132-4/+4
|
* internal: move diagnostics to hirAleksey Kladov2021-05-253-67/+26
| | | | | | | | | | | | | | | | | | | | | | | 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.
* Add support for lengths in array repeats, if they are literalsJade2021-05-131-2/+3
| | | | Now we will get the type of `[0u8; 4]`.
* Support length for ByteStringsJade2021-05-131-1/+4
| | | | I am not confident that my added byte string parsing is right.
* Merge #8398bors[bot]2021-05-112-8/+18
|\ | | | | | | | | | | | | | | 8398: Fix inference with conditionally compiled tails r=flodiebold a=DJMcNab Fixes #8378 Co-authored-by: Daniel McNab <[email protected]>
| * Fix inference with conditionally compiled tailsDaniel McNab2021-05-032-8/+18
| | | | | | | | Fixes #8378
* | Reuse database in LowerCtxJonas Schievink2021-05-061-2/+2
| |
* | Don't store call-site text offsets in hygiene infoJonas Schievink2021-05-061-12/+18
|/
* Add failing local items testJonas Schievink2021-04-212-0/+32
|
* hir_ty: Expand macros at type positioncynecx2021-04-171-7/+27
|
* Include path in `unresolved-macro-call` diagnosticJonas Schievink2021-04-162-3/+7
|
* Support macros in pattern positionJonas Schievink2021-04-111-7/+27
|
* Update `OUT_DIR` diagnostic to match settingJonas Schievink2021-04-071-1/+1
|
* Intern TypeRefs stored in BodyJonas Schievink2021-04-061-4/+7
| | | | Minor improvement to memory usage (1 MB or so)
* Use Box'es to reduce the size of hir_def::expr::Pat from 112 to 64 bytes on ↵Alexandru Macovei2021-04-061-3/+3
| | | | 64bit
* Use Box'es to reduce size of hir_def::expr::Expr from 128 to 72 bytes (on ↵Alexandru Macovei2021-04-061-6/+10
| | | | | | | | | | 64bit systems) Rationale: only a minority of variants used almost half the size. By keeping large members (especially in Option) behind a box the memory cost is only payed when the large variants are needed. This reduces the size Vec<Expr> needs to allocate.
* Only remember blocks that have a DefMapJonas Schievink2021-04-041-5/+7
|
* Fix recursive macro statement expansionEdwin Cheng2021-03-251-35/+33
|
* Fix incorrect scoping in while expressionsLukas Wirth2021-03-211-1/+1
|
* Track labels in scopesLukas Wirth2021-03-211-10/+47
|
* Improve diagnostic when including nonexistent fileJonas Schievink2021-03-171-1/+1
|
* Handle `#[cfg]` on call argumentsJonas Schievink2021-03-171-11/+16
|
* Merge #8048bors[bot]2021-03-173-3/+30
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 8048: Fix missing unresolved macro diagnostic in function body r=edwin0cheng a=brandondong This was an issue I found while working on https://github.com/rust-analyzer/rust-analyzer/pull/7970. **Reproduction:** 1. Call a non-existent macro in a function body. ``` fn main() { foo!(); } ``` 2. No diagnostics are raised. An unresolved-macro-call diagnostic is expected. 3. If the macro call is instead outside of the function body, this works as expected. I believe this worked previously and regressed in https://github.com/rust-analyzer/rust-analyzer/pull/7805. **Behavior prior to https://github.com/rust-analyzer/rust-analyzer/pull/7805:** - The unresolved-macro-call diagnostic did not exist. Instead, a macro-error diagnostic would be raised with the text "could not resolve macro [path]". - This was implemented by adding an error to the error sink (https://github.com/rust-analyzer/rust-analyzer/pull/7805/files#diff-50a326c5ae465bd9b31ee4310186380aa06e4fa1f6b41dbc0aed5bcc656a3cb8L657). - The error was propagated through https://github.com/rust-analyzer/rust-analyzer/blob/1a82af3527e476d52410ff4dfd2fb4c57466abcb/crates/hir_def/src/body.rs#L123 eventually reaching https://github.com/rust-analyzer/rust-analyzer/blob/1a82af3527e476d52410ff4dfd2fb4c57466abcb/crates/hir_def/src/body/lower.rs#L569. **Behavior after:** - Instead of writing to the error sink, an UnresolvedMacro error is now returned (https://github.com/rust-analyzer/rust-analyzer/pull/7805/files#diff-50a326c5ae465bd9b31ee4310186380aa06e4fa1f6b41dbc0aed5bcc656a3cb8R631). - The parent caller throws away the error as its function signature is `Option<MacroCallId>` (https://github.com/rust-analyzer/rust-analyzer/pull/7805/files#diff-50a326c5ae465bd9b31ee4310186380aa06e4fa1f6b41dbc0aed5bcc656a3cb8R604). - We instead now reach the warn condition (https://github.com/rust-analyzer/rust-analyzer/blob/1a82af3527e476d52410ff4dfd2fb4c57466abcb/crates/hir_def/src/body.rs#L124) and no diagnostics are created in https://github.com/rust-analyzer/rust-analyzer/blob/1a82af3527e476d52410ff4dfd2fb4c57466abcb/crates/hir_def/src/body/lower.rs#L575. **Fix:** - Make sure to propagate the UnresolvedMacro error. Report the error using the new unresolved-macro-call diagnostic. Co-authored-by: Brandon <[email protected]>
| * Fix missing unresolved macro diagnostic in function bodyBrandon2021-03-163-3/+30
| |
* | Fix macro expansion for statements w/o semicolonEdwin Cheng2021-03-161-47/+58
|/
* Simplify source maps for fieldsAleksey Kladov2021-03-151-15/+9
|
* Stop fetching ItemTrees for no reasonJonas Schievink2021-03-101-14/+1
|
* Remove `item_scope` field from `Body`Jonas Schievink2021-03-091-139/+4
|
* Store inner `BlockId`s in `Body`Jonas Schievink2021-03-091-0/+3
|
* Use upstream cov-markLaurențiu Nicola2021-03-084-11/+9
|
* Merge #7804bors[bot]2021-02-281-6/+11
|\ | | | | | | | | | | | | | | 7804: Introduce TypeCtor::Scalar r=lnicola a=Veykril `TypeCtor::Int(..) | TypeCtor::Float(..) | TypeCtor::Char | TypeCtor::Bool` => `TypeCtor::Scalar(..)`, in this case we can actually just straight up use `chalk_ir::Scalar` already since its just a POD without any IDs or anything. Co-authored-by: Lukas Wirth <[email protected]>
| * Introduce TypeCtor::ScalarLukas Wirth2021-02-281-6/+11
| |
* | Restrict visibilities to the containing DefMapJonas Schievink2021-02-281-0/+29
|/
* Add another block def map testJonas Schievink2021-02-091-0/+27
|
* Add `TestDB::module_at_position`Jonas Schievink2021-02-091-100/+4
|
* Add expression scopes for blocksJonas Schievink2021-02-091-4/+18
|
* Test `super` resolution tooJonas Schievink2021-02-051-0/+2
|
* Fix resolution of `self` module within blocksJonas Schievink2021-02-051-6/+8
|
* Remove redundant clonesYoshua Wuyts2021-02-051-1/+1
|
* Expander: store a LocalModuleId, not ModuleIdJonas Schievink2021-02-041-7/+7
| | | | | It already stores the DefMap containing the module, so having a full ModuleId is unnecessary and makes it easier to mix things up
* Don't keep the parent DefMap alive via ArcJonas Schievink2021-02-041-4/+3
| | | | | This seems like it could easily leak a lot of memory since we don't currently run GC
* Add newline between block and crate mapsJonas Schievink2021-02-031-0/+10
|
* Test for name resolution with DefMap shortcutJonas Schievink2021-02-031-0/+33
|
* Shortcut `block_def_map` if there's no inner itemsJonas Schievink2021-02-032-5/+8
| | | | | This previously didn't work, but apparently only because of the wonky test setup
* Use body lowering for block_def_map testsJonas Schievink2021-02-032-2/+301
| | | | Removes the hacky and buggy custom lowering code
* Use block_def_map in body loweringJonas Schievink2021-02-031-10/+25
|
* Revert "Use block_def_map in body lowering"Jonas Schievink2021-02-023-326/+12
|
* Use body lowering for block_def_map testsJonas Schievink2021-02-012-2/+301
| | | | Removes the hacky and buggy custom lowering code