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>
4499: CodeLens configuration options r=vsrs a=vsrs
This PR
- adds an option to granularly enable\disable all CodeLens, just like the TypeScript extension.
- fixes a minor bug for doctests. It makes no sense to show `Debug` lens for them as cargo `Can't skip running doc tests with --no-run`.
Co-authored-by: vsrs <vit@conrlab.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>
4479: Chalk upgrade r=matklad a=flodiebold
This includes the fix for `dyn Trait` super traits, but I noticed that still a lot of `db.super_trait_method()` calls don't work because the super trait isn't in scope (because it doesn't actually need to be). Somehow, I thought we handled that already, but I'll fix it in a separate PR. Also I'll see what happens if we use more of Chalk's new built-in types and traits in a separate PR.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
4288: Add rename self to parameter and back. r=zbsz a=zbsz
This is a first stab at #3439
I liked the idea to do this as a rename instead of separate assist, so I tried implementing that.
It mostly works, but I'm sure there are some cases that I missed, especially in regards to parameter type.
Note: I'm playing with this this as a way to learn Rust and this project. So I'm sure it could be cleaner and put in better places`. Any suggestions?
Co-authored-by: zbsz <zbigniewo@gmail.com>
4470: Handle `Self` in values and patterns r=matklad a=flodiebold
I.e.
- `Self(x)` or `Self` in tuple/unit struct impls
- `Self::Variant(x)` or `Self::Variant` in enum impls
- the same in patterns
Fixes#4454.
Co-authored-by: Florian Diebold <florian.diebold@freiheit.com>
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>
4445: Correctly fill default type parameters r=flodiebold a=montekki
Fixes#3877
So, basically even if the parameters are omitted from the `impl` block, check the parameters in `trait` if they have a default type, and if they do go from `hir` to `ast::TypeArg`. I've added a helper for that but I am not sure that it's a proper way to go from `hir` to `ast` here.
Co-authored-by: Fedor Sakharov <fedor.sakharov@gmail.com>
