| Age | Commit message (Collapse) | Author | Lines |
|
|
|
|
|
another name was added in the meantime
|
|
Gah. I always find it confusing that make tidy gives me the highest error
code, but not the **next** error code.
|
|
specialization nabbed E0520
|
|
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.
|
|
make DefPath store krate and enable uniform access to crate_name/crate_disambiguator
|
|
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.
|
|
the same crate-name and crate-salt but different SVHs.
|
|
|
|
|
|
|
|
|
|
another and were not previously instrumented.
|
|
|
|
|
|
|
|
|
|
tests & rustdoc still broken
|