| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
This comit applies the following changes:
* Deletes the `is_allocator` query as it's no longer used
* Moves the `is_sanitizer_runtime` method to a query
* Moves the `is_profiler_runtime` method to a query
* Moves the `panic_strategy` method to a query
* Moves the `is_no_builtins` method to a query
* Deletes the cstore method of `is_compiler_builtins`. The query was added in
#42588 but the `CrateStore` method was not deleted
A good bit of these methods were used late in linking during trans so a new
dedicated structure was created to ship a calculated form of this information
over to the linker rather than having to ship the whole of `TyCtxt` over to
linking.
|
|
Instead, combine the already-present DefPathHash with the 32-bit
ItemLocalIndex.
Should fix #44323.
|
|
|
|
|
|
This map, like `trait_map`, is calculated in resolve, but we want to be sure to
track it for incremental compliation. Hide it behind a query to get more
refactorings later.
|
|
This map is calculated in resolve, but we want to be sure to track it for
incremental compliation. Hide it behind a query to get more refactorings later.
|
|
This commit removes the `specialization_cache` field of `TyCtxt` by moving it to
a dedicated query, which it turned out was already quite easily structured to do
so!
|
|
|
|
|
|
|
|
incr.comp.: Cache Hir-DepNodeIndices in the HIR map.
In preparation for red/green. This should also be faster than before without any additional memory cost.
r? @nikomatsakis
|
|
|
|
|
|
|
|
(A followup commit removes the mir::transform based entry point.)
|
|
|
|
In preparation for incremental compilation this commit refactors the lint
handling infrastructure in the compiler to be more "eager" and overall more
incremental-friendly. Many passes of the compiler can emit lints at various
points but before this commit all lints were buffered in a table to be emitted
at the very end of compilation. This commit changes these lints to be emitted
immediately during compilation using pre-calculated lint level-related data
structures.
Linting today is split into two phases, one set of "early" lints run on the
`syntax::ast` and a "late" set of lints run on the HIR. This commit moves the
"early" lints to running as late as possible in compilation, just before HIR
lowering. This notably means that we're catching resolve-related lints just
before HIR lowering. The early linting remains a pass very similar to how it was
before, maintaining context of the current lint level as it walks the tree.
Post-HIR, however, linting is structured as a method on the `TyCtxt` which
transitively executes a query to calculate lint levels. Each request to lint on
a `TyCtxt` will query the entire crate's 'lint level data structure' and then go
from there about whether the lint should be emitted or not.
The query depends on the entire HIR crate but should be very quick to calculate
(just a quick walk of the HIR) and the red-green system should notice that the
lint level data structure rarely changes, and should hopefully preserve
incrementality.
Overall this resulted in a pretty big change to the test suite now that lints
are emitted much earlier in compilation (on-demand vs only at the end). This in
turn necessitated the addition of many `#![allow(warnings)]` directives
throughout the compile-fail test suite and a number of updates to the UI test
suite.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The field init shorthand syntax was stabilized in 1.17.0 (aebd94f); we
are now free to use it in the compiler.
|
|
Without this patch, there is an ICE when running rustc with
RUST_LOG=debug. This patch updates extract_def_id to check if the map
has been populated before accessing it. This fixes the problem, but
maybe we do not need to compute the incremental hashes maps in the first
place when we are not in incremental mode?
|
|
Track more crate metadata
Part of https://github.com/rust-lang/rust/issues/41417
r? @nikomatsakis
|
|
|
|
incr.comp.: Make DepNode's std::fmt::Debug implementation useful again.
With #42537 a regular `DepNode` only contains an opaque hash as its identifier. In most cases, this hash is actually a `DefPathHash` and we can reconstruct the `DefId` it came from via a table lookup --- and then use that to print something intelligible for debug outputs. For cases where we cannot reconstruct information from the DepNode's hash, this PR will cache a string representation of the `DepNode` in a side-table. This string is later used for debug outputs.
r? @nikomatsakis
|
|
|
|
|
|
|
|
optimization
|
|
|
|
|
|
In the case of `TransCrateItem`, I had to tweak the tests a bit, but
it's a concept that doesn't work well under new system.
|
|
|
|
|
|
This allows for treating global crate metadata the same as regular metadata with regard to incr. comp.
|
|
able to reconstruct obj-file names from one.
|
|
|
|
|
|
Rollup of 10 pull requests
- Successful merges: #41981, #42225, #42310, #42319, #42335, #42343, #42355, #42360, #42370, #42372
- Failed merges:
|
