Niko Matsakis [Wed, 16 Mar 2016 09:57:03 +0000 (05:57 -0400)]
refactor item-paths in diagnostics, symbol names
This change has a few parts. We introduce a new `item_path` module for
constructing item paths. The job of this module is basically to make
nice, user-readable paths -- but these paths are not necessarily 100%
unique. They meant to help a *human* find code, but not necessarily a
compute. These paths are used to drive `item_path_str` but also symbol
names.
Because the paths are not unique, we also modify the symbol name hash to
include the full `DefPath`, whereas before it included only those
aspects of the def-path that were not included in the "informative"
symbol name.
Eventually, I'd like to make the item-path infrastructure a bit more
declarative. Right now it's based purely on strings. In particular, for
impls, we should supply the raw types to the `ItemPathBuffer`, so that
symbol names can be encoded using the C++ encoding scheme for better
integration with tooling.
Niko Matsakis [Wed, 16 Mar 2016 09:50:38 +0000 (05:50 -0400)]
track the extern-crate def-id rather than path
We used to track, for each crate, a path that led to the extern-crate
that imported it. Instead of that, track the def-id of the extern crate,
along with a bit more information, and derive the path on the fly.
Add a "link-guard" to avoid accidentally linking to a wrong dylib at runtime.
We want to prevent compiling something against one version
of a dynamic library and then, at runtime accidentally
using a different version of the dynamic library. With the
old symbol-naming scheme this could not happen because every
symbol had the SVH in it and you'd get an error by the
dynamic linker when using the wrong version of a dylib. With
the new naming scheme this isn't the case any more, so this
patch adds the "link-guard" to prevent this error case.
This is implemented as follows:
- In every crate that we compile, we emit a function called
"__rustc_link_guard_<crate-name>_<crate-svh>"
- The body of this function contains calls to the
"__rustc_link_guard" functions of all dependencies.
- An executable contains a call to it's own
"__rustc_link_guard" function.
As a consequence the "__rustc_link_guard" function call graph
mirrors the crate graph and the dynamic linker will fail if a
wrong dylib is loaded somewhere because its
"__rustc_link_guard" function will contain a different SVH in
its name.
bors [Fri, 25 Mar 2016 12:03:13 +0000 (05:03 -0700)]
Auto merge of #31908 - jseyfried:disallow_shadowed_traits, r=nikomatsakis
Disallow methods from traits that are not in scope
This PR only allows a trait method to be used if the trait is in scope (fixes #31379).
This is a [breaking-change]. For example, the following would break:
```rust
mod foo {
pub trait T { fn f(&self) {} }
impl T for () {}
}
mod bar { pub use foo::T; }
fn main() {
pub use bar::*;
struct T; // This shadows the trait `T`,
().f() // making this an error.
}
```
r? @nikomatsakis
bors [Fri, 25 Mar 2016 06:12:57 +0000 (23:12 -0700)]
Auto merge of #32428 - nikomatsakis:scopes-in-mir, r=nagisa
Scopes in mir
This PR adds scopes to MIR. There is a tree of scopes (each represented by a `ScopeId`). Every statement, variable, and terminator now has an associated scope and span. It also adds a `-Z dump-mir` switch one can use to conveniently examine the MIR as optimizations proceed.
The intention is two-fold. First, to support MIR debug-info. This PR does not attempt to modify trans to make use of the scope information, however.
Second, in a more temporary capacity, to support the goal of moving regionck and borowck into the MIR. To that end, the PR also constructs a "scope auxiliary" table storing the extent of each span (this is kept separate from the main MIR, since it contains node-ids) and the dom/post-dom of the region in the graph where the scope occurs. When we move to non-lexical lifetimes, I expect this auxiliary information to be discarded, but that is still some ways in the future (requires, at minimum, an RFC, and there are some thorny details to work out -- though I've got an in-progress draft).
Right now, I'm just dropping this auxiliary information after it is constructed. I was debating for some time whether to add some sort of sanity tests, but decided to just open this PR instead, because I couldn't figure out what such a test would look like (and we don't have independent tests for this today beyond the regionck and borrowck tests).
I'd prefer not to store the auxiliary data into any kind of "per-fn" map. Rather, I'd prefer that we do regionck/borrowck/whatever-else immediately after construction -- that is, we build the MIR for fn X and immediately thereafter do extended correctness checking on it. This will reduce peak memory usage and also ensure that the auxiliary data doesn't exist once optimizations begin. It also clarifies the transition point where static checks are complete and MIR can be more freely optimized.
bors [Thu, 24 Mar 2016 21:22:26 +0000 (14:22 -0700)]
Auto merge of #32346 - nikomatsakis:no-erased-regions, r=eddyb
Remove `ErasedRegions` from substs
This commit removes the `ErasedRegions` enum from `Substs`. Instead, in trans, we just generate a vector of `ReStatic` of suitable length. The goal is both general cleanup and to help pave the way for a glorious future where erasure is used in type check.
r? @eddyb
One concern: might be nice to do some profiling. Not sure the best way to do that. Perhaps I'll investigate running nrc's test suite locally.
Niko Matsakis [Wed, 9 Mar 2016 23:22:05 +0000 (18:22 -0500)]
remove ErasedRegions from substitutions
This hack has long since outlived its usefulness; the transition to
trans passing around full substitutions is basically done. Instead of
`ErasedRegions`, just supply substitutions with a suitable number of
`'static` entries, and invoke `erase_regions` when needed (the latter of
which we already do).
Niko Matsakis [Thu, 24 Mar 2016 00:46:38 +0000 (20:46 -0400)]
rewrite scope drop to be iterative
while I'm at it, remove the "extra caching" that I was doing for no good
reason except laziness. Basically before I was caching at each scope in
the chain, but there's not really a reason to do that, since the cached
entry point at level N is always equal to the last cached exit point
from level N-1.
Niko Matsakis [Wed, 23 Mar 2016 09:01:30 +0000 (05:01 -0400)]
Add `ScopeAuxiliaryVec`, return MIR+aux via tuple
It's nice to be able to index with a scope-id,
but coherence rules prevent us from implementing
`Index<ScopeId>` for `Vec<ScopeAuxiliary>`, and I'd
prefer that `ScopeAuxiliary` remain in librustc_mir,
just for compilation time reasons.
Niko Matsakis [Wed, 23 Mar 2016 00:39:29 +0000 (20:39 -0400)]
rewrite drop code
This was triggered by me wanting to address a use of DUMMY_SP, but
actually I'm not sure what would be a better span -- I guess the span
for the function as a whole.
Rollup merge of #32437 - eddyb:orbital-msvc, r=alexcrichton
Annotate run-pass/backtrace with #[rustc_no_mir] on MSVC.
Fixes #32384 by not using MIR on MSVC for the functions in the path of the backtrace.
This is the known blocker for the MSVC MIR builder, hopefully the only one overall.
r? @alexcrichton Confirmed to work on a nightly, by @retep998.
Rollup merge of #32430 - sanxiyn:const-trans, r=arielb1
Fix const trans
Fix #30615.
The idea was that when there are N autoderefs, first do N-1 derefs and check for autoref. If there is autoref, done, if not, do one more deref. But when N is zero, doing one more deref is wrong.
Rollup merge of #32429 - alexcrichton:scope-id-hton, r=aturon
std: Store flowinfo/scope_id in host byte order
Apparently these aren't supposed to be stored in network byte order, so doing so
ends up causing failures when it would otherwise succeed when stored in the host
byte order.
bors [Wed, 23 Mar 2016 08:03:04 +0000 (01:03 -0700)]
Auto merge of #32348 - brson:cargotest, r=alexcrichton
Introduce 'cargotest' and the check-cargotest buildstep
This is a new suite of tests that verifies that the compiler builds specific revisions of select crates from crates.io.
It does not run by default. It is intended that bors runs these tests against all PRs, and gates on them. In this way we will make it harder still to break important swaths of the ecosystem, even on nightly.
This is a very basic implementation intended for feedback. The biggest thing it probably should do but doesn't is use a lockfile for every project it builds.
r? @alexcrichton cc @rust-lang/lang @rust-lang/libs
projects / rust.git / log