| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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]>
|
| | | |
|
| | | |
|
| |/ |
|
| |
|
|
| |
This should fix some of the worst performance problems.
|
| |
|
|
| |
+ various fixes related to that.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
E.g.
```
trait Trait {
type Item: SomeOtherTrait;
}
```
Note that these don't simply desugar to where clauses; as I understand it, where
clauses have to be proved by the *user* of the trait, but these bounds are proved
by the *implementor*. (Also, where clauses on associated types are unstable.)
|
| |
|
|
|
| |
This speeds up inference in analysis-stats by ~30% (even more with the recursive
solver).
|
| |
|
|
|
|
|
|
|
|
| |
Chalk now panics if we don't implement these methods and run with CHALK_DEBUG,
so I thought I'd try to implement them 'properly'. Sadly, it seems impossible to
do without transmuting lifetimes somewhere. The problem is that we need a `&dyn
HirDatabase` to get names etc., which we can't just put into TLS. I thought I
could just use `scoped-tls`, but that doesn't support references to unsized
types. So I put the `&dyn` into another struct and put the reference to *that*
into the TLS, but I have to transmute the lifetime to 'static for that to work.
|
| | |
|
| |
|
|
|
|
|
| |
The big change here is counting binders, not
variables (https://github.com/rust-lang/chalk/pull/360). We have to adapt to the
same scheme for our `Ty::Bound`. It's mostly fine though, even makes some things
more clear.
|
| | |
|
| |
|
|
|
|
|
| |
It improves compile time in `--release` mode quite a bit, it doesn't
really slow things down and, conceptually, it seems closer to what we
want the physical architecture to look like (we don't want to
monomorphise EVERYTHING in a single leaf crate).
|
| | |
|
| | |
|
| |
|
|
|
| |
This slows down analysis-stats a bit (~5% in my measurement), but improves
incremental checking a lot because we can reuse trait solve results.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This adds some tools helpful when debugging nondeterminism in analysis-stats:
- a `--randomize` option that analyses everything in random order
- a `-vv` option that prints even more detail
Also add a debug log if Chalk fuel is exhausted (which would be a source of
nondeterminism, but didn't happen in my tests).
I found one source of nondeterminism (rust-lang/chalk#331), but there are still
other cases remaining.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
It's not very different, except we can directly use Salsa IDs instead of casting
them. This means we need to refactor the handling of errors to get rid of
UNKNOWN_TRAIT though.
|
| | |
|
| | |
|
| |
|
|
| |
This untangles the builtin logic from the Chalk translation.
|
| |
|
