resolve: Refactor how the prelude is handled
This PR refactors how the prelude is handled in `resolve`.
Instead of importing names from the prelude into each module's `resolutions`, this PR adds a new field `prelude: RefCell<Option<Module>>` to `ModuleS` that is set during import resolution but used only when resolving in a lexical scope (i.e. the scope of an initial segment of a relative path).
r? @nikomatsakis
As discussed in
https://github.com/rust-lang/rust/pull/32293#issuecomment-200597130,
adding link guards are a heuristic that is causing undue complications:
- the link guards inject extra public symbols, which is not always OK.
- link guards as implemented could be a non-trivial performance hit,
because no attempt is made to "de-duplicate" the dependency graph,
so at worst you have O(N!) calls to the link guard functions.
Nonetheless, link guards are very helpful in detecting errors, so it may
be worth adding them back in some modified form in the future.
Link guards cause problems in some specific scenarios on windows because
they force libcore to be instantiated, since we do not GC functions
effectively on windows.
The changes here are two:
1. disable core for rsbegin/rsend
2. make panic_fmt an extern fn for smallest-hello-world so that it
is not marked as "internal" for LLVM
Full binary reproducible builds are not possible on all platforms
because linker injects a certain amount of randomness, apparently. Or,
at minimum, they don't work reliably yet.
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.
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.
In particular, remove the name from the Impl, since that name is
synthesized and is not predictable (it tends to break incr. comp.).
Also rename the variants to be a bit more uniform and remove some
distinctions that we were not really taking advantage of anywhere.
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.
