| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
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.
|
|
|
|
This massively speeds up serialization. It also
seems to produce deterministic metadata hashes
(before I was seeing inconsistent results).
Fixes #35232.
|
|
The biggest problem, actually, is krate numbers being removed entirely,
which can lead to array-index-out-of-bounds errors.
cc #35123 -- not a complete fix, since really we ought to "map" the old
crate numbers to the new ones, not just detect changes.
|
|
The way we do HIR inlining introduces reads of the "Hir" into the graph,
but this Hir in fact belongs to other crates, so when we try to load
later, we ICE because the Hir nodes in question don't belond to the
crate (and we haven't done inlining yet). This pass rewrites those HIR
nodes to the metadata from which the inlined HIR was loaded.
|
|
|
|
In the older version, a `.o` and ` .bc` file were separate
work-products. This newer version keeps, for each codegen-unit, a set
of files of different kinds. We assume that if any kinds are available
then all the kinds we need are available, since the precise set of
switches will depend on attributes and command-line switches.
Should probably test this: the effect of changing attributes in
particular might not be successfully tracked?
|
|
|
|
|
|
This way we distinguish, in particular, `Foo: Sized`
and `Bar: Sized`, which fixes #33850.
|
|
|
|
These tests reveal that the edges are in some cases
too strict.
|
|
this allows us to remove the dummy `foo` fn
|
|
|
|
Not sure what was the bug. Fixes #32014.
|
|
|
