| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
If/when we switch to using Chalk's Ty, we'll need to replace this by its `Fold`
trait, but I didn't want to import the whole thing just yet.
|
| |
|
|
|
|
|
|
|
| |
- refactor bounds handling in the AST a bit
- add HIR for bounds
- add `Ty::Dyn` and `Ty::Opaque` variants and lower `dyn Trait` / `impl Trait`
syntax to them
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds three different representations, copied from the Chalk model:
- `Ty::Projection` is an associated type projection written somewhere in the
code, like `<Foo as Trait>::Bar`.
- `Ty::UnselectedProjection` is similar, but we don't know the trait
yet (`Foo::Bar`).
- The above representations are normalized to their actual types during type
inference. When that isn't possible, for example for `T::Item` inside an `fn
foo<T: Iterator>`, the type is normalized to an application type with
`TypeCtor::AssociatedType`.
|
|
|
|
|
| |
This seems to be enough to prevent hanging in rust-analyzer, Chalk and the rustc
repo.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
I.e. if we are inside a function with some where clauses, we assume these where
clauses hold.
|
| |
|
| |
|
|
|
|
|
|
| |
This wasn't a right decision in the first place, the feature flag was
broken in the last rustfmt release, and syntax highlighting of imports
is more important anyway
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This gives a significant speedup, because chalk will call these
functions several times even withing a single revision. The only
significant one here is `impl_data`, but I figured it might be good to
cache others just for consistency.
The results I get are:
Before:
from scratch: 16.081457952s
no change: 15.846493ms
trivial change: 352.95592ms
comment change: 361.998408ms
const change: 457.629212ms
After:
from scratch: 14.910610278s
no change: 14.934647ms
trivial change: 85.633023ms
comment change: 96.433023ms
const change: 171.543296ms
Seems like a nice win!
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
For Send/Sync/Sized, we don't handle auto traits correctly yet and because they
have a lot of impls, they can easily lead to slowdowns. In the case of
Fn/FnMut/FnOnce, we don't parse the special Fn notation correctly yet and don't
handle closures yet, so we are very unlikely to find an impl.
|
|
|
|
|
| |
We don't pass field types to Chalk yet though, so the auto trait inference won't
be correct.
|
| |
|
| |
|
|
|
|
|
| |
This is slightly hacky, but maybe more elegant than alternative solutions: We
just use a hardcoded Chalk trait ID which we special-case to have no impls.
|
| |
|
|
|
|
|
| |
This is necessary because Chalk (reasonably) expects each 'struct' to know how
many type parameters it takes.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Badly, but at least it doesn't crash.
|
| |
|
|
|