| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
It's not needed, and `source` is only used by tests anyways
|
| |
|
| |
|
|
|
|
|
| |
This removes leading newlines everywhere, shifting all ranges in tests
by one
|
|
|
|
|
| |
The paths in fixture are not really relative (the default one is
`/main.rs`), so it doesn't make sense to use `RelativePathBuf` here.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
4947: Replace `impls_in_trait` query with smarter use of `CrateImplDefs` r=matklad a=jonas-schievink
`impls_in_trait` was allocating a whopping ~400 MB of RAM when running analysis-stats on r-a itself.
Remove it, instead adding a query that computes a summary `CrateImplDefs` map for all transitive dependencies. This can probably still be made more efficient, but this already reduces the peak memory usage by 25% without much performance impact on analysis-stats.
**Before**:
```
Total: 34.962107188s, 2083mb allocated 2141mb resident
422mb ImplsForTraitQuery (deps)
250mb CrateDefMapQueryQuery
147mb MacroArgQuery
140mb TraitSolveQuery (deps)
68mb InferQueryQuery (deps)
62mb ImplDatumQuery (deps)
```
**After**:
```
Total: 35.261100358s, 1520mb allocated 1569mb resident
250mb CrateDefMapQueryQuery
147mb MacroArgQuery
144mb TraitSolveQuery (deps)
68mb InferQueryQuery (deps)
61mb ImplDatumQuery (deps)
45mb BodyQuery
45mb ImplDatumQuery
```
Co-authored-by: Jonas Schievink <[email protected]>
|
| | |
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
4958: Infer FnSig via Fn traits r=flodiebold a=adamrk
Addresses https://github.com/rust-analyzer/rust-analyzer/issues/4481.
When inferring types check if the callee implements one of the builtin `Fn` traits. Also autoderef the callee before trying to figure out it's `FnSig`.
Co-authored-by: adamrk <[email protected]>
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
Fixes #4885.
Fixes #4800.
|
|/ /
| |
| |
| |
| |
| |
| |
| | |
When referring to an associated type of a super trait, we used the substs of the
subtrait. That led to the #4931 crash if the subtrait had less parameters, but
it could also lead to other incorrectness if just the order was different.
Fixes #4931.
|
| |
| |
| |
| | |
Fixes #4953.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
4851: Add quickfix to add a struct field r=TimoFreiberg a=TimoFreiberg
Related to #4563
I created a quickfix for record literals first because the NoSuchField diagnostic was already there.
To offer that quickfix for FieldExprs with unknown fields I'd need to add a new diagnostic (or create a `NoSuchField` diagnostic for those cases)
I think it'd make sense to make this a snippet completion (to select the generated type), but this would require changing the `Analysis` API and I'd like some feedback before I touch that.
Co-authored-by: Timo Freiberg <[email protected]>
|
| | | |
|
|\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
4839: `Go to Type Definition` hover action. r=matklad a=vsrs
![hover_actions_goto](https://user-images.githubusercontent.com/62505555/83335671-0122e380-a2b7-11ea-9922-fbdcfb11a7f3.gif)
This implementation supports things like `dyn Trait<SomeType>`, `-> impl Trait`, etc.
Co-authored-by: vsrs <[email protected]>
|
| | | |
|
| | | |
|
| | | |
|
|/ / |
|
| | |
|
| | |
|
|/ |
|
| |
|
| |
|
|
|
|
|
|
| |
'Unknown' int/float types actually never exist as such, they get replaced by
type variables immediately. So the whole `Uncertain<IntTy>` thing was
unnecessary and just led to a bunch of match branches that were never hit.
|
|
|
|
|
| |
They should not be applied in expression or pattern contexts, unless there are
other explicitly given type args.
|
|\
| |
| |
| |
| |
| |
| |
| | |
4761: Upgrade Chalk to published version r=matklad a=flodiebold
CC @pksunkara
Co-authored-by: Florian Diebold <[email protected]>
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
4689: Implement return position impl trait / opaque type support r=matklad a=flodiebold
This is working, but I'm not that happy with how the lowering works. We might need an additional representation between `TypeRef` and `Ty` where names are resolved and `impl Trait` bounds are separated out, but things like inference variables don't exist and `impl Trait` is always represented the same way.
Also note that this doesn't implement correct handling of RPIT *inside* the function (which involves turning the `impl Trait`s into variables and creating obligations for them). That intermediate representation might help there as well.
Co-authored-by: Florian Diebold <[email protected]>
Co-authored-by: Florian Diebold <[email protected]>
|
| | | |
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is working, but I'm not that happy with how the lowering works. We might
need an additional representation between `TypeRef` and `Ty` where names are
resolved and `impl Trait` bounds are separated out, but things like inference
variables don't exist and `impl Trait` is always represented the same
way.
Also note that this doesn't implement correct handling of RPIT *inside* the
function (which involves turning the `impl Trait`s into variables and creating
obligations for them). That intermediate representation might help there as
well.
|
|/ |
|
| |
|
|
|
|
| |
For things like `concant!(env!("OUT_DIR"))`, we need to support abs paths
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
4653: Fix match ergonomics in closure parameters r=matklad a=flodiebold
Fixes #4476.
Co-authored-by: Florian Diebold <[email protected]>
|
| |
| |
| |
| | |
Fixes #4476.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
4651: Use first match branch in case of type mismatch, not last r=kjeremy a=flodiebold
The comment says this was intentional, but I do agree with #4304 that it makes
more sense the other way around (for if/else as well).
Fixes #4304.
Co-authored-by: Florian Diebold <[email protected]>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The comment says this was intentional, but I do agree with #4304 that it makes
more sense the other way around (for if/else as well).
Fixes #4304.
|