7386: Handle box with allocator r=flodiebold a=tweksteen
In 1.49.0, the definition of Box was modified to support an optional
Allocator[1]. Adapt the parsing of the `box` keyword to supply the
expected number of parameters to the constructor.
[1] f288cd2e17Fixes: #6956
Co-authored-by: Thiébaud Weksteen <tweek@google.com>
In 1.49.0, the definition of Box was modified to support an optional
Allocator[1]. Adapt the parsing of the `box` keyword to supply the
expected number of parameters to the constructor.
[1] f288cd2e17
7291: Wrap remaining self/super/crate in Name{Ref} r=matklad a=Veykril
That should be the remaining special casing for `self` 🎉
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
7276: Remove map module from la-arena public API r=lnicola a=arzg
It’s unlikely that more items will be added to the module, so it’s simpler for users if `ArenaMap` is re-exported and the module made private.
This doesn’t compile for the same reason that #7275 doesn’t:
> This pull request doesn’t compile because dependencies on la-arena go through crates.io, so existing dependencies on the crate are referencing an old version. As such, this PR will only compile once a new la-arena version has been published.
Co-authored-by: Aramis Razzaghipour <aramisnoah@gmail.com>
7145: Proper handling $crate Take 2 [DO NOT MERGE] r=edwin0cheng a=edwin0cheng
Similar to previous PR (#7133) , but improved the following things :
1. Instead of storing the whole `ExpansionInfo`, we store a similar but stripped version `HygieneInfo`.
2. Instread of storing the `SyntaxNode` (because every token we are interested are IDENT), we store the `TextRange` only.
3. Because of 2, we now can put it in Salsa.
4. And most important improvement: Instead of computing the whole frames every single time, we compute it recursively through salsa: (Such that in the best scenario, we only need to compute the first layer of frame)
```rust
let def_site = db.hygiene_frame(info.def.file_id);
let call_site = db.hygiene_frame(info.arg.file_id);
HygieneFrame { expansion: Some(info), local_inner, krate, call_site, def_site }
```
The overall speed compared to previous PR is much faster (65s vs 45s) :
```
[WITH old PR]
Database loaded 644.86ms, 284mi
Crates in this dir: 36
Total modules found: 576
Total declarations: 11153
Total functions: 8715
Item Collection: 15.78s, 91562mi
Total expressions: 240721
Expressions of unknown type: 2635 (1%)
Expressions of partially unknown type: 2064 (0%)
Type mismatches: 865
Inference: 49.84s, 250747mi
Total: 65.62s, 342310mi
rust-analyzer -q analysis-stats . 66.72s user 0.57s system 99% cpu 1:07.40 total
[WITH this PR]
Database loaded 665.83ms, 284mi
Crates in this dir: 36
Total modules found: 577
Total declarations: 11188
Total functions: 8743
Item Collection: 15.28s, 84919mi
Total expressions: 241229
Expressions of unknown type: 2637 (1%)
Expressions of partially unknown type: 2064 (0%)
Type mismatches: 868
Inference: 30.15s, 135293mi
Total: 45.43s, 220213mi
rust-analyzer -q analysis-stats . 46.26s user 0.74s system 99% cpu 47.294 total
```
*HOWEVER*, it is still a perf regression (35s vs 45s):
```
[WITHOUT this PR]
Database loaded 657.42ms, 284mi
Crates in this dir: 36
Total modules found: 577
Total declarations: 11177
Total functions: 8735
Item Collection: 12.87s, 72407mi
Total expressions: 239380
Expressions of unknown type: 2643 (1%)
Expressions of partially unknown type: 2064 (0%)
Type mismatches: 868
Inference: 22.88s, 97889mi
Total: 35.74s, 170297mi
rust-analyzer -q analysis-stats . 36.71s user 0.63s system 99% cpu 37.498 total
```
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
7133: Proper handling $crate and local_inner_macros r=jonas-schievink a=edwin0cheng
This PR introduces `HygineFrames` to store the macro definition/call site hierarchy in hyginee and when resolving `local_inner_macros` and `$crate`, we use the token to look up the corresponding frame and return the correct value.
See also: https://rustc-dev-guide.rust-lang.org/macro-expansion.html#hygiene-and-hierarchies
fixe #6890 and #6788
r? @jonas-schievink
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
6852: Ignore lifetime params in substitutions r=matklad a=Veykril
[`hir_ty::utils::Generics`](https://github.com/rust-analyzer/rust-analyzer/blob/master/crates/hir_ty/src/utils.rs#L153) currently only assumes type parameters but not lifetime parameters and therefor creates incorrect index and length calculations, this PR just makes the use sites ignore LifetimeGenerics for now.
This fixes the panic at least locally for me for `analysis-stats`. Funnily enough this panic prevented me from using reference search for the `args` field to fix this problem.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6818: Add Lifetimes to the HIR r=matklad a=Veykril
This doesn't handle resolve yet as I don't know yet how that will be used. I'll get to that once I start moving the lifetime reference PR to the hir.
This also adds a new `hir` name type for lifetimes and labels, `hir::LifetimeName`.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
Without arbitrary self types, the self type could never refer to the method type
parameters, so this wasn't a problem; but with arbitrary self types, it can.
This fixes the crash from #6668; but it doesn't make method resolution work for
these methods.
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.
6350: Make IncorrectDiagnostic match rustc by copying rustc's code. r=popzxc a=ArifRoktim
This closes#6343 and closes#6345.
The old algorithm which used a `DetectedCase` enum, didn't match how rustc thinks of cases. Some inputs can be interpreted as more than 1 case depending on the situation. For example, to rustc:
- `ABCD`: Can be both camel case and upper snake case
- `X86_64`: Can be both camel case and upper snake case
I could've made `detect_case` return a collection of `DetectedCase` and then modified the other code as such, but I think using the same code rustc uses is simpler and a surefire way to achieve the same diagnostics as rustc.
Co-authored-by: Arif Roktim <arifrroktim@gmail.com>
- add panic context for the trait goal if CHALK_DEBUG is set
- print the Chalk program even if we're panicking
- log goal/solution while TLS is still set
6307: Add whitelist of safe intrinsics r=frazar a=frazar
This PR should fix#5996, where intrinsic operations where all marked as unsafe.
I'm rather new to this codebase, so I might be doing something *very* wrong. Please forgive me!
In particular, I'm not sure how to "check that we are in extern `rust-intrinsics`" as mentioned [in this comment](https://github.com/rust-analyzer/rust-analyzer/issues/5996#issuecomment-709234802).
Co-authored-by: Francesco Zardi <frazar@users.noreply.github.com>
* Chalk very recently (like an hour ago) merged a fix that prevents rust analyzer from panicking. This allows it to be usable again for code that hits those situations. See #6134, #6145, Probably #6120
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 <oxalicc@pm.me>
5968: Lookup ADT and associated type names for chalk debugging / tweak chalk interner r=flodiebold a=nathanwhit
This PR improves the chalk program writing integration by looking up the names for ADTs and associated types, making the output much more readable.
There are also a few small changes to the interner, which gives some nice performance improvements. We clone `Ty`s and `ProgramClause`s relatively often in chalk, so wrapping them in `Arc`s is a perf win. This takes the time for performing type inference on the rust-analyzer codebase from 40s to 33s on my machine.
Co-authored-by: Nathan Whitaker <nathan.whitaker01@gmail.com>
