| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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
|
|
|
|
this avoids parsing item attributes on each call to `item_attrs`, which takes
off 33% (!) of translation time and 50% (!) of trans-item collection time.
|
|
|
|
|
|
|
|
|
|
|
|
This "on-demand" task both checks for errors and computes the custom
unsized kind, if any. This task is only defined on impls of
`CoerceUnsized`; invoking it on any other kind of impl results in a bug.
This is just to avoid having an `Option`, could easily be changed.
|
|
Remove unused adt-def insertion by constructor DefIndex
It looks to me like ADT definitions weren't being looked up by constructor id, and a test run supports my theory.
In any case, I'm not sure it would have worked in its current configuration. If I understand correctly, the `adt_def` map entry from constructor id -> adt def would only be present after a successful call to `queries::adt_def::get` with the proper ADT `DefIndex`. Trying to look up an adt_def by the constructor index prior to a successful lookup by ADT index would fail since `item.kind` would be `EntryKind::Fn` (for the constructor function) and so would trigger the `bug!`.
r? @nikomatsakis
|
|
|
|
`#[macro_reexport]`)
and macros 2.0 exports (`pub use` macro re-exports and `pub macro` (once implemented)
at the crate root.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Because certain somebody sucks at resolving big conflicts
|
|
Previously AdtDef variants contained ConstInt for each discriminant, which did not really reflect
the actual type of the discriminants. Moving the type into AdtDef allows to easily put the type
into metadata and also saves bytes from ConstVal overhead for each discriminant.
Also arguably the code is cleaner now :)
|
|
This effectively deprecates lookup_repr_hints.
|
|
This commit updates the version number to 1.17.0 as we're not on that version of
the nightly compiler, and at the same time this updates src/stage0.txt to
bootstrap from freshly minted beta compiler and beta Cargo.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This commit includes manual merge conflict resolution changes from a rebase by @est31.
|
