| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Minor improvement to memory usage (1 MB or so)
|
|
|
|
| |
64bit
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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]>
|
| | |
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
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]>
|
| | |
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
It already stores the DefMap containing the module, so having
a full ModuleId is unnecessary and makes it easier to mix things up
|
|
|
|
|
| |
This seems like it could easily leak a lot of memory since we don't
currently run GC
|
| |
|
| |
|
|
|
|
|
| |
This previously didn't work, but apparently only because of the wonky
test setup
|
|
|
|
| |
Removes the hacky and buggy custom lowering code
|
| |
|
| |
|
|
|
|
| |
Removes the hacky and buggy custom lowering code
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Removes the `local_scope` hack from `Expander` in favor of tracking the
`DefMap` in use during body lowering
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
7021: Track labels in the HIR r=matklad a=Veykril
Groundwork for #6966
Co-authored-by: Lukas Wirth <[email protected]>
|
| | |
|
| | |
|
|/ |
|