| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
#1856
|
|
|
|
|
| |
I used the wrong query, so it only used the lang items from the respective
crate...
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is only allowed for generic parameters (including `Self` in traits), and
special care needs to be taken to not run into cycles while resolving it,
because we use the where clauses of the generic parameter to find candidates for
the trait containing the associated type, but the where clauses may themselves
contain instances of short-hand associated types.
In some cases this is even fine, e.g. we might have `T: Trait<U::Item>, U:
Iterator`. If there is a cycle, we'll currently panic, which isn't great, but
better than overflowing the stack...
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is to make debugging rust-analyzer easier.
The idea is that `dbg!(krate.debug(db))` will print the actual, fuzzy
crate name, instead of precise ID. Debug printing infra is a separate
thing, to make sure that the actual hir doesn't have access to global
information.
Do not use `.debug` for `log::` logging: debugging executes queries,
and might introduce unneded dependencies to the crate graph
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
E.g. if we call `foo<T: Into<u32>>(x)`, that adds an obligation that `x:
Into<u32>`, etc.
|
|
|
|
|
|
| |
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!
|
|
|
|
|
| |
With an intermediate query, changing one module won't cause reparsing
of all modules
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Before this commit, `Parse`s for original file ended up two times in
salsa's db: first, when we parse original file, and second, when we
parse macro or a file.
Given that parse trees are the worst ofenders in terms of memory, it
makes sense to make sure we store them only once.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
We use panics for cancellation, so we could trigger panic while
holding the solver. std::sync::Mutex will be poisoned as a result,
which and all further attempts to use solver (from other threads) will
panic as well.
This commit switches to parking_lot::Mutex which just unlocks on panic.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Also remove the only remaining mention of chalk outside of the ty::traits
module.
|
|
|
|
|
| |
- add proper canonicalization logic
- add conversions from/to Chalk IR
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, when expanding macros, we look at the source code
directly (we invoke ast_id_to_node query via to_node method).
This is less then ideal, because it make us re-expand macros after
every source change.
This commit establishes a salsa-firewall: a query to get macro call's
token tree. Unlike the syntax tree, token tree changes only if we
actually modify the macro itself.
|
|
|
|
|
|
| |
This reverts commit 6c63a59425e256ce46d058807b64149297231982.
This causes massive slowdowns: looks like we accidentally have some source-depndent
|