| Age | Commit message (Collapse) | Author | Lines |
|
|
|
|
|
|
|
|
|
test incremental ThinLTO.
|
|
|
|
|
|
This commit moves compression of the bytecode from the `link` module to the
`write` module, namely allowing it to be (a) cached by incremental compilation
and (b) produced in parallel. The parallelization may show up as some nice wins
during normal compilation and the caching in incremental mode should be
beneficial for incremental compiles! (no more need to recompress the entire
crate's bitcode on all builds)
|
|
This adds auto-assertion to `rustc_clean/dirty` and also implements
more comprehensive testing for
- src/test/incremental/hashes/enum_constructors.rs
- src/test/incremental/hashes/enum_defs.rs
- src/test/incremental/hashes/extern_mods.rs
- src/test/incremental/hashes/inherent_impls.rs
- src/test/incremental/hashes/statics.rs
- src/test/incremental/hashes/struct_constructors.rs
- src/test/incremental/hashes/type_defs.rs
trait_defs.rs and trait_impl.rs are blocked on a hard to triage
compiler ICE (at least hard for a newbie like me) having to do
with some DepNodes not getting computed for traits.
A FIXME has been added in the source to reflect this continued
work.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This allows for treating global crate metadata the same as regular metadata with regard to incr. comp.
|
|
|
|
|
|
Each MIR key is a DefId that has MIR associated with it
|
|
|
|
A task function is now given as a `fn` pointer to ensure that it carries
no state. Each fn can take two arguments, because that worked out to be
convenient -- these two arguments must be of some type that is
`DepGraphSafe`, a new trait that is intended to prevent "leaking"
information into the task that was derived from tracked state.
This intentionally leaves `DepGraph::in_task()`, the more common form,
alone. Eventually all uses of `DepGraph::in_task()` should be ported
to `with_task()`, but I wanted to start with a smaller subset.
Originally I wanted to use closures bound by an auto trait, but that
approach has some limitations:
- the trait cannot have a `read()` method; since the current method
is unused, that may not be a problem.
- more importantly, we would want the auto trait to be "undefined" for all types
*by default* -- that is, this use case doesn't really fit the typical
auto trait scenario. For example, imagine that there is a `u32` loaded
out of a `hir::Node` -- we don't really want to be passing that
`u32` into the task!
|
|
|
|
There are now three patterns (shallow, deep, and nested visit). These
are described in detail on the docs in `itemlikevisit::ItemLikeVisitor`.
|
|
The shadow graph supercedes the existing code that checked for
reads/writes without an active task and now adds the ability
to filter for specific edges.
|
|
A work product right now is just a `.o` file. In the future it probably
includes other kinds of files, such as `.bc` files saving the
unoptimized LLVM IR.
However, because WorkProductIds must be independent of DefIds, so that
they don't need translation, this system may not be suitable *as is* for
storing fine-grained information (such as the MIR for individual defs),
as it was originally intended. We will want to refactor some for that.
|
|
Create some re-usable filtering subroutines.
|
|
This lets us determine what was used to construct the metadata.
Conflicts:
src/librustc_metadata/encoder.rs
|
|
it is useful later to customize how change the type we use for reference
items away from DefId
|
|
|
|
|
|
|
|
Add Pass manager for MIR
A new PR, since rebasing the original one (https://github.com/rust-lang/rust/pull/31448) properly was a pain. Since then there has been several changes most notable of which:
1. Removed the pretty-printing with `#[rustc_mir(graphviz/pretty)]`, mostly because we now have `--unpretty=mir`, IMHO that’s the direction we should expand this functionality into;
2. Reverted the infercx change done for typeck, because typeck can make an infercx for itself by being a `MirMapPass`
r? @nikomatsakis
|
|
impl blocks.
For example, the following is now correctly illegal:
```rust
struct Foo;
impl Foo {
fn id() {}
}
impl Foo {
fn id() {}
}
```
"Overlapping" here is determined the same way it is for traits (and in
fact shares the same code path): roughly, there must be some way of
substituting any generic types to unify the impls, such that none of the
`where` clauses are provably unsatisfiable under such a unification.
Closes #22889
|
|
|
|
|
|
|
|
In MIR we previously tried to match `let x in { exprs; let y in { exprs; }}` with our data
structures which is rather unwieldy, espeicially because it requires some sort of recursion or
stack to process, while, a flat list of statements is enough – lets only relinquish their lifetime
at the end of the block (i.e. end of the list).
Also fixes #31853.
|
|
another and were not previously instrumented.
|
|
acccessed.
|
|
size of `DepNode` smaller and because we are not that fine-grained yet
anyhow
|
|
|
|
along with a README explaining how they are to be used
|