| Age | Commit message (Collapse) | Author | Lines |
|---|
|
have to be hashed in downstream crates.
|
|
- Don't hash traits in scope as part of HIR hashing any more.
- Some queries returned DefIndexes from other crates.
- Provide a generic way of stably hashing maps (not used everywhere yet).
|
|
This is a big map that ends up inside of a `CrateContext` during translation for
all codegen units. This means that any change to the map may end up causing an
incremental recompilation of a codegen unit! In order to reduce the amount of
dependencies here between codegen units and the actual input crate this commit
refactors dealing with exported symbols and such into various queries.
The new queries are largely based on existing queries with filled out
implementations for the local crate in addition to external crates, but the main
idea is that while translating codegen untis no unit needs the entire set of
exported symbols, instead they only need queries about particulare `DefId`
instances every now and then.
The linking stage, however, still generates a full list of all exported symbols
from all crates, but that's going to always happen unconditionally anyway, so no
news there!
|
|
|
|
|
|
This should now be entirely tracked through queries, so no need to have a
`DepGraph` in the `CStore` object any more!
|
|
Previously a `Symbol` was stored there, but this ended up causing hash
collisions in situations that otherwise shouldn't have a hash collision. Only
the symbol's string value was hashed, but it was possible for distinct symbols
to have the same string value, fooling various calcuations into thinking that
these paths *didn't* need disambiguating data when in fact they did!
By storing `InternedString` instead we're hopefully triggering all the exising
logic to disambiguate paths with same-name `Symbol` but actually distinct
locations.
|
|
Should hopefully more accurately reflect what's happening! This commit also
removes the cache in the cstore implementation as it's already cached through
the query infrastructure.
|
|
|
|
|
|
Implements RFC 1845, adding implementations of:
* `From<&[T]>` for `Rc<[T]>`
* `From<&str>` for `Rc<str>`
* `From<String>` for `Rc<str>`
* `From<Box<T: ?Sized>>` for `Rc<T>`
* `From<Vec<T>>` for `Rc<[T]>`
* and likewise for `Arc<_>`
Also removes now-obsolete internal methods `Rc::__from_array` and
`Rc::__from_str`, replacing their use with `Rc::from`.
|
|
|
|
Like #43008 (f668999), but _much more aggressive_.
|
|
|
|
|
|
|
|
|
|
|
|
Implement lazy loading of external crates' sources. Fixes #38875
Fixes #38875. This is a follow-up to #42507. When a (now correctly translated) span from an external crate is referenced in a error, warning or info message, we still don't have the source code being referenced.
Since stuffing the source in the serialized metadata of an rlib is extremely wasteful, the following scheme has been implemented:
* File maps now contain a source hash that gets serialized as well.
* When a span is rendered in a message, the source hash in the corresponding file map(s) is used to try and load the source from the corresponding file on disk. If the file is not found or the hashes don't match, the failed attempt is recorded (and not retried).
* The machinery fetching source lines from file maps is augmented to use the lazily loaded external source as a secondary fallback for file maps belonging to external crates.
This required a small change to the expected stderr of one UI test (it now renders a span, where previously was none).
Further work can be done based on this - some of the machinery previously used to hide external spans is possibly obsolete and the hashing code can be reused in different places as well.
r? @eddyb
|
|
A bug has been discovered and fixed in the process.
|
|
incr.comp.: Make DepNode `Copy` and valid across compilation sessions
This PR moves `DepNode` to a representation that does not need retracing and thus simplifies comparing dep-graphs from different compilation sessions. The code also gets a lot simpler in many places, since we don't need the generic parameter on `DepNode` anymore. See https://github.com/rust-lang/rust/issues/42294 for details.
~~NOTE: Only the last commit of this is new, the rest is already reviewed in https://github.com/rust-lang/rust/pull/42504.~~
This PR is almost done but there are some things I still want to do:
- [x] Add some module-level documentation to `dep_node.rs`, explaining especially what the `define_dep_nodes!()` macro is about.
- [x] Do another pass over the dep-graph loading logic. I suspect that we can get rid of building the `edges` map and also use arrays instead of hash maps in some places.
cc @rust-lang/compiler
r? @nikomatsakis
|
|
We can use these to perform lazy loading of source files belonging to
external crates. That way we will be able to show the source code of
external spans that have been translated.
|
|
|
|
Fix translation of external spans
Previously, I noticed that spans from external crates don't generate any output. This limitation is problematic if analysis is performed on one or more external crates, as is the case with [rust-semverver](https://github.com/ibabushkin/rust-semverver). This change should address this behaviour, with the potential drawback that a minor performance hit is to be expected, as spans from potentially large crates have to be translated now.
|
|
|
|
This allows for treating global crate metadata the same as regular metadata with regard to incr. comp.
|
|
|
|
|
|
|
|
Remove interior mutability from TraitDef by turning fields into queries
This PR gets rid of anything `std::cell` in `TraitDef` by
- moving the global list of trait impls from `TraitDef` into a query,
- moving the list of trait impls relevent for some self-type from `TraitDef` into a query
- moving the specialization graph of trait impls into a query, and
- moving `TraitDef::object_safety` into a query.
I really like how querifying things not only helps with incremental compilation and on-demand, but also just plain makes the code cleaner `:)`
There are also some smaller fixes in the PR. Commits can be reviewed separately.
r? @eddyb or @nikomatsakis
|
|
|
|
|
|
Move the code for loading metadata from rlibs and dylibs from
rustc_metadata into rustc_trans, and introduce a trait to avoid
introducing a direct dependency on rustc_trans.
This means rustc_metadata is no longer rebuilt when LLVM changes.
|
|
|
|
|
|
|
|
|
|
|
|
On demandify region mapping
This is an adaptation of @cramertj's PR. I am sort of tempted to keep simplifying it, but also tempted to land it so and we can refactor more in follow-up PRs. As is, it does the following things:
- makes the region-maps an on-demand query, per function `tcx.region_maps(def_id)`
- interns code extents instead of of having them be integers
- remove the "root region extent" and (to some extent) item extents; instead we use `Option<CodeExtent<'tcx>>` in a few places (no space inefficiency since `CodeExtent<'tcx>` is now a pointer).
I'm not entirely happy with the way I have it setup though. Here are some of the changes I was considering (I'm not sure if they would work out well):
1. Removing `item_extents` entirely -- they are rarely used now, because most of the relevant places now accept an `Option<Region<'tcx>>` or an `Option<CodeExtent<'tcx>>`, but I think still used in a few places.
2. Merging `RegionMaps` into the typeck tables, instead of having it be its own query.
3. Change `CodeExtent<'tcx>` to store the parent pointer. This would mean that fewer places in the code actually *need* a `RegionMaps` anyhow, since most of them just want to be able to walk "up the tree". On the other hand, you wouldn't be able to intern a `CodeExtent<'tcx>` for some random node-id, you'd need to look it up in the table (since there'd be more information).
Most of this code is semi-temporary -- I expect it to largely go away as we move to NLL -- so I'm also not *that* concerned with making it perfect.
r? @eddyb
|
|
|
|
|
|
|
|
Make a `CodeExtent<'tcx>` be something allocated in an arena
instead of an index into the `RegionMaps`.
|
|
make *most* maps private
Currently we access the `DepTrackingMap` fields directly rather than using the query accessors. This seems bad. This branch removes several such uses, but not all, and extends the macro so that queries can hide their maps (so we can prevent regressions). The extension to the macro is kind of ugly :/ but couldn't find a simple way to do it otherwise (I guess I could use a nested macro...). Anyway I figure it's only temporary.
r? @eddyb
|
|
Implement a file-path remapping feature in support of debuginfo and reproducible builds
This PR adds the `-Zremap-path-prefix-from`/`-Zremap-path-prefix-to` commandline option pair and is a more general implementation of #41419. As opposed to the previous attempt, this implementation should enable reproducible builds regardless of the working directory of the compiler.
This implementation of the feature is more general in the sense that the re-mapping will affect *all* paths the compiler emits, including the ones in error messages.
r? @alexcrichton
|
|
|
|
#37653 support `default impl` for specialization
this commit implements the first step of the `default impl` feature:
> all items in a `default impl` are (implicitly) `default` and hence
> specializable.
In order to test this feature I've copied all the tests provided for the
`default` method implementation (in run-pass/specialization and
compile-fail/specialization directories) and moved the `default` keyword
from the item to the impl.
See [referenced](https://github.com/rust-lang/rust/issues/37653) issue for further info
r? @aturon
|
|
reproducible builds.
|
|
|
|
this commit implements the first step of the `default impl` feature:
all items in a `default impl` are (implicitly) `default` and hence
specializable.
In order to test this feature I've copied all the tests provided for the
`default` method implementation (in run-pass/specialization and
compile-fail/specialization directories) and moved the `default` keyword
from the item to the impl.
See referenced issue for further info
|
