4501: Querify `importable_locations_in_crate` r=jonas-schievink a=jonas-schievink
This brings the time needed to compute the `add_missing_impl_members` assist down from ~5 minutes to 20 seconds on my test workload (which is editing within an impl of a MIR [`MutVisitor`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/visit/trait.MutVisitor.html))
cc #4498
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
4497: Create LowerCtx on the fly r=matklad a=edwin0cheng
Previously we create `LowerCtx` at the beginning of lowering, however, the hygiene content is in fact changing between macro expression expanding.
This PR change it to create the `LowerCtx` on the fly to fix above bug.
However, #4465 is not fixed by this PR, the goto-def is still not work yet. It only fixed the infer part.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
4493: Provide builtin impls of Fn traits for fn-pointers r=flodiebold a=hban
Meant to be, but isn't actually a fix for #2880.
Consider this snippet:
```rust
use std::marker::PhantomData;
use std::ops::Deref;
struct Lazy<T, F/* = fn() -> T*/>(F, PhantomData<T>);
impl<T, F> Lazy<T, F> {
pub fn new(f: F) -> Lazy<T, F> {
Lazy(f, PhantomData)
}
}
impl<T, F: FnOnce() -> T> Deref for Lazy<T, F> {
type Target = T;
fn deref(&self) -> &T { todo!() }
}
fn test() {
let lazy1: Lazy<u32, _> = Lazy::new(|| 0u32);
let r1 = lazy1.to_string();
fn make_u32_fn() -> u32 { todo!() }
let make_u32_fn_ptr: fn() -> u32 = make_u32_fn;
let lazy2: Lazy<u32, _> = Lazy::new(make_u32_fn_ptr);
let r2 = lazy2.to_string();
}
```
* On current master:
* When type default is commented-out, `r1` is correctly inferred, `r2` in _{unknown}_.
* When type default is not commented-out, both `r1` and `r2` are _{unknown}_.
* With this PR:
* When type default is commented-out, both `r1` and `r2` are correctly inferred.
* When type default is not commented-out, both `r1` and `r2` are _{unknown}_.
Well, it's a improvement at least. I guess this thing with type defaults is a different problem.
I also tried add Fn impls for fn items, but wasn't successful. So this PR only adds those impls for fn pointers.
Co-authored-by: Hrvoje Ban <hban@users.noreply.github.com>
4489: Memory allocation optimization r=matklad a=simonvandel
I did some profiling using DHAT, and this was what I could easily optimize without much knowledge of the codebase.
This speeds up analysis-stats on rust-analyser by ~4% on my local machine.
**Benchmark**
➜ rust-analyzer-base git:(master) hyperfine --min-runs=2 '/home/simon/Documents/rust-analyzer/target/release/rust-analyzer analysis-stats .' '/home/simon/Documents/rust-analyzer-base/target/release/rust-analyzer analysis-stats .'
Benchmark #1: /home/simon/Documents/rust-analyzer/target/release/rust-analyzer analysis-stats .
Time (mean ± σ): 49.621 s ± 0.317 s [User: 48.725 s, System: 0.792 s]
Range (min … max): 49.397 s … 49.846 s 2 runs
Benchmark #2: /home/simon/Documents/rust-analyzer-base/target/release/rust-analyzer analysis-stats .
Time (mean ± σ): 51.764 s ± 0.045 s [User: 50.882 s, System: 0.756 s]
Range (min … max): 51.733 s … 51.796 s 2 runs
Summary
'/home/simon/Documents/rust-analyzer/target/release/rust-analyzer analysis-stats .' ran
1.04 ± 0.01 times faster than '/home/simon/Documents/rust-analyzer-base/target/release/rust-analyzer analysis-stats .'
Co-authored-by: Simon Vandel Sillesen <simon.vandel@gmail.com>
4484: Allow calling dyn trait super trait methods without the super trait in scope r=flodiebold a=flodiebold
This also removes some vestiges of the old impl trait support which I think aren't currently in use.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
4472: Fix path resolution for module and function with same name r=hasali19 a=hasali19
This fixes#3970 and also fixes completion for the same issue.
Co-authored-by: Hasan Ali <git@hasali.co.uk>
4448: Generate configuration for launch.json r=vsrs a=vsrs
This PR adds two new commands: `"rust-analyzer.debug"` and `"rust-analyzer.newDebugConfig"`. The former is a supplement to the existing `"rust-analyzer.run"` command and works the same way: asks for a runnable and starts new debug session. The latter allows adding a new configuration to **launch.json** (or to update an existing one).
If the new option `"rust-analyzer.debug.useLaunchJson"` is set to true then `"rust-analyzer.debug"` and Debug Lens will first look for existing debug configuration in **launch.json**. That is, it has become possible to specify startup arguments, env variables, etc.
`"rust-analyzer.debug.useLaunchJson"` is false by default, but it might be worth making true the default value. Personally I prefer true, but I'm not sure if it is good for all value.
----
I think that this PR also solves https://github.com/rust-analyzer/rust-analyzer/issues/3441.
Both methods to update launch.json mentioned in the issue do not work:
1. Menu. It is only possible to add a launch.json configuration template via a debug adapter. And anyway it's only a template and it is impossible to specify arguments from an extension.
2. DebugConfigurationProvider. The exact opposite situation: it is possible to specify all debug session settings, but it is impossible to export these settings to launch.json.
Separate `"rust-analyzer.newDebugConfig"` command looks better for me.
----
Fixes#4450Fixes#3441
Co-authored-by: vsrs <vit@conrlab.com>
Co-authored-by: vsrs <62505555+vsrs@users.noreply.github.com>
4273: Trigger add_vis assist on paths/record fields as well r=flodiebold a=TimoFreiberg
Resolves#4037.
- [x] Function defs
- [x] ADT defs
- [x] Enum variants
- [x] Consts
- [x] Statics
- [x] Traits
- [x] Type aliases
- [x] Modules
- [x] Record fields (using different implementation)
- [x] struct fields
- [x] enum variant fields
- ❌ union fields (`Semantics::resolve_record_field` seems to not work for union fields, so I think this can be handled in a future PR)
- [x] More tests?
- [x] Improve test fixture code and documentation a bit (see [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Fwg-rls-2.2E0/topic/resolve_path.20between.20fixture.20files))
Co-authored-by: Timo Freiberg <timo.freiberg@gmail.com>
