- 26 3月, 2016 40 次提交
-
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
the intention is to give some simple protection like link-guards but not impede ability to upgrade dylib in place
-
由 Niko Matsakis 提交于
This reverts commit b52004d202ddfffa100d4963216e1673a0be0b95.
-
由 Niko Matsakis 提交于
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.
-
由 Niko Matsakis 提交于
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
-
由 Niko Matsakis 提交于
another name was added in the meantime
-
由 Niko Matsakis 提交于
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.
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
Gah. I always find it confusing that make tidy gives me the highest error code, but not the **next** error code.
-
由 Niko Matsakis 提交于
specialization nabbed E0520
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
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 提交于
makes better edges in dep graph
-
由 Niko Matsakis 提交于
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.
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
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.
-
由 Niko Matsakis 提交于
make DefPath store krate and enable uniform access to crate_name/crate_disambiguator
-
由 Niko Matsakis 提交于
-
由 Michael Woerister 提交于
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.
-
由 Michael Woerister 提交于
-
由 Michael Woerister 提交于
Make the compiler emit an error if the crate graph contains two crates with the same crate-name and crate-salt but different SVHs.
-
由 Michael Woerister 提交于
-
由 Michael Woerister 提交于
-
由 Michael Woerister 提交于
-
由 Michael Woerister 提交于
-
由 Michael Woerister 提交于
-
由 Michael Woerister 提交于
-
由 Michael Woerister 提交于
-
由 Michael Woerister 提交于
-
由 Michael Woerister 提交于
-
由 Michael Woerister 提交于
-
由 Michael Woerister 提交于
-