aboutsummaryrefslogtreecommitdiff
path: root/crates/hir_def/src/body/lower.rs
Commit message (Collapse)AuthorAgeFilesLines
* 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
|
* Handle `#[cfg]` on call argumentsJonas Schievink2021-03-171-11/+16
|
* Merge #8048bors[bot]2021-03-171-2/+13
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-161-2/+13
| |
* | 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-081-2/+1
|
* Introduce TypeCtor::ScalarLukas Wirth2021-02-281-6/+11
|
* 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
* Shortcut `block_def_map` if there's no inner itemsJonas Schievink2021-02-031-3/+6
| | | | | This previously didn't work, but apparently only because of the wonky test setup
* Use block_def_map in body loweringJonas Schievink2021-02-031-10/+25
|
* Revert "Use block_def_map in body lowering"Jonas Schievink2021-02-021-25/+10
|
* Use block_def_map in body loweringJonas Schievink2021-02-011-10/+25
|
* add more countsAleksey Kladov2021-01-271-0/+2
|
* Revert "Make use of `block_def_map` in body lowering"Jonas Schievink2021-01-211-12/+4
|
* Make use of `block_def_map` in body loweringJonas Schievink2021-01-211-4/+12
| | | | | Removes the `local_scope` hack from `Expander` in favor of tracking the `DefMap` in use during body lowering
* Add support for yiled keywordDaiki Ihara2021-01-151-0/+4
|
* prepare to publish el libro de arenaAleksey Kladov2021-01-141-1/+1
|
* Fixed typos in code commentsVincent Esche2021-01-091-2/+2
|
* Rename expr -> tail_exprAleksey Kladov2021-01-051-1/+1
|
* Merge #7021bors[bot]2020-12-241-47/+45
|\ | | | | | | | | | | | | | | 7021: Track labels in the HIR r=matklad a=Veykril Groundwork for #6966 Co-authored-by: Lukas Wirth <[email protected]>
| * Track labels in the HIRLukas Wirth2020-12-241-47/+45
| |
* | Implement const block inferenceLukas Wirth2020-12-231-0/+4
| |
* | Implement const pat inferenceLukas Wirth2020-12-231-3/+9
|/
* Update ungrammar for const block patternsLukas Wirth2020-12-231-1/+3
|
* Refactor attributes API to allow handling cfg_attrJonas Schievink2020-12-181-1/+1
|
* Node-ify lifetimesLukas Wirth2020-12-161-17/+7
|
* Make macro def krate mandatoryJonas Schievink2020-12-151-1/+1
| | | | Refactors builtin derive support to go through proper name resolution
* Basic support for decl macros 2.0Jonas Schievink2020-12-151-1/+4
|
* Move to upstream `macro_rules!` modelJonas Schievink2020-12-151-65/+69
|
* Expand statements for mbe in loweringEdwin Cheng2020-12-151-82/+134
|
* Attach macro expansion errors to the right fileJonas Schievink2020-12-021-2/+5
|
* Emit unresolved proc macro errorsJonas Schievink2020-12-011-8/+23
|
* Emit macro diagnostics when lowering bodiesJonas Schievink2020-11-301-2/+12
|
* Cleanup APIAleksey Kladov2020-11-061-10/+11
|
* Deny unreachable-pubAleksey Kladov2020-11-021-3/+3
| | | | | | | | 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.
* Diagnose #[cfg]s in bodiesJonas Schievink2020-10-231-14/+46
|
* Fix `mut self` not emitting mutable binding on `self` useLukas Wirth2020-10-111-1/+4
|
* Merge #5971bors[bot]2020-09-131-1/+4
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]>
| * Implement async blocksoxalica2020-09-101-1/+4
| |
* | Implement box pattern inferenceJonas Schievink2020-09-121-1/+5
|/
* :arrow_up: ungrammarAleksey Kladov2020-08-211-1/+1
|
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-14 06:22:40 +0000