| Age | Commit message (Collapse) | Author | Lines |
|
add more incremental reuse test cases
r? @michaelwoerister
This is basically a port of the "private method in impl". It works better when it's a top-level fn. =)
|
|
|
|
|
|
|
|
Currently doesn't work that well at all in terms of getting reuse
afterwards, see #37333. =)
|
|
|
|
add test case for changing private methods
The goal of this test case is to ensure we are getting the reuse we expect. This targets a particular change where we modify the body of a private inherent method defined on a struct, and looks at different ways we can use that struct.
It checks for when type-checking would be needed as well as the actual reuse achieved.
cc https://github.com/rust-lang/rust/issues/37121
r? @michaelwoerister
|
|
|
|
|
|
incr.comp.: Minor refactoring and update to struct ICH test case
r? @nikomatsakis
|
|
ICH: Enable some cases in trait definition hashing.
Enable some test cases originally written by @eulerdisk. The tests can be enabled now because @MathieuBordere has fixed the underlying problem in #36974.
r? @nikomatsakis
|
|
|
|
Fixes #37000.
|
|
Fixes #37001.
|
|
|
|
Test Case for Incr. Comp. Hash for traits #36681.
Fixes #36681
Part of #36350
Currently, the following tests fail:
Unsafe modifier
Extern modifier
Extern c to rust-intrinsic
Trait unsafety
Change type of method parameter (&i32 => &mut i32)
Mode of self parameter
r? @michaelwoerister
|
|
|
|
|
|
parameter"
|
|
|
|
|
|
Improve error message and snippet for "did you mean `x`"
- Fixes #36164
- Part of #35233
Based on the standalone example https://is.gd/8STXMd posted by @nikomatsakis and using the third formatting option mentioned in #36164 and agreed by @jonathandturner.
Note however this does not address the question of [how to handle an empty or unknown suggestion](https://github.com/rust-lang/rust/issues/36164#issuecomment-244460024). @nikomatsakis any suggestions on how best to address that part?
|
|
|
|
|
|
- Fixes #36164
- Part of #35233
- handles unknown fields
- uses UI-style tests
- update all related tests (cfail, ui, incremental)
|
|
|
|
|
|
|
|
|
|
map crate numbers between compilations
?r nikomatsakis
issue #35123
|
|
|
|
|
|
|
|
|
|
fix a few errant `Krate` edges
Exploring the effect of small changes on `syntex` reuse, I discovered the following sources of unnecessary edges from `Krate`
r? @michaelwoerister
|
|
incr. comp.: Take spans into account for ICH
This PR makes the ICH (incr. comp. hash) take spans into account when debuginfo is enabled.
A side-effect of this is that the SVH (which is based on the ICHs of all items in the crate) becomes sensitive to the tiniest change in a code base if debuginfo is enabled. Since we are not trying to model ABI compatibility via the SVH anymore (this is done via the crate disambiguator now), this should be not be a problem.
Fixes #33888.
Fixes #32753.
|
|
Across crates only, converting a def-id into its def-key or def-path was
considered a read. This caused spurious reads when computing the symbol
name for some item.
|
|
|
|
We touch the krate to adjust the maps, but we don't expose that data
widely.
|
|
The goal here is to avoid writing to the `inherent_impls` map from
within the general `Coherence` task, and instead write to it as we
visit. Writing to it from the Coherence task is actually an information
leak; it happened to be safe because Coherence read from
`DepNode::Krate`, but that was very coarse.
I removed the `Rc` here because, upon manual inspection, nobody clones
the data in this table, and it meant that we can accumulate the data in
place. That said, the pattern that is used for the inherent impls map
is *generally* an anti-pattern (that is, holding the borrow lock for the
duration of using the contents), so it'd probably be better to
clone (and I doubt that would be expensive -- how many inherent impls
does a typical type have?).
|
|
|
|
|
|
|
|
This seems not only more correct but allows us to write tests that check
whether the krate hash as a whole is clean/dirty
|
|
Fixes #35593
|
|
This avoids the compile-time overhead of computing them twice. It also fixes
an issue where the hash computed after typeck is differen than the hash before,
because typeck mutates the def-map in place.
Fixes #35549.
Fixes #35593.
|
|
|
|
.. and use it to purge the incremental compilation cache if necessary.
|
|
We now incorporate the `def_map` and `trait_map`
results into the SVH.
|
|
|