| Age | Commit message (Collapse) | Author | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This commit updates the LLVM branch to the rebased version of the
upstream release/8.x branch. This includes a wasm patch which means that
the `rewrite_imports` pass in rustc is no longer needed (yay!) and we
can instead rely on `wasm-import-module`, an attribute we're already
emitting, to take care of all the work.
|
|
|
|
|
|
Stabilize linker-plugin based LTO (aka cross-language LTO)
This PR stabilizes [linker plugin based LTO](https://github.com/rust-lang/rust/issues/49879), also known as "cross-language LTO" because it allows for doing inlining and other optimizations across language boundaries in mixed Rust/C/C++ projects.
As described in the tracking issue, it works by making `rustc` emit LLVM bitcode instead of machine code, the same as `clang` does. A linker with the proper plugin (like LLD) can then run (Thin)LTO across all modules.
The feature has been implemented over a number of pull requests and there are various [codegen](https://github.com/rust-lang/rust/blob/master/src/test/codegen/no-dllimport-w-cross-lang-lto.rs) and [run](https://github.com/rust-lang/rust/tree/master/src/test/run-make-fulldeps/cross-lang-lto-clang)-[make](https://github.com/rust-lang/rust/tree/master/src/test/run-make-fulldeps/cross-lang-lto-upstream-rlibs) [tests](https://github.com/rust-lang/rust/tree/master/src/test/run-make-fulldeps/cross-lang-lto) that make sure that it keeps working.
It also works for building big projects like [Firefox](https://treeherder.mozilla.org/#/jobs?repo=try&revision=2ce2d5ddcea6fbff790503eac406954e469b2f5d).
The PR makes the feature available under the `-C linker-plugin-lto` flag. As discussed in the tracking issue it is not cross-language specific and also not LLD specific. `-C linker-plugin-lto` is descriptive of what it does. If someone has a better name, let me know `:)`
|
|
|
|
|
|
|
|
Support the case when link objects are not located in Rust sysroot
but in other locations which could be specify through library paths.
|
|
Returning an iterator leads to nicer code all around.
|
|
It's more idiomatic, makes the code shorter, and will help with the next
commit.
|
|
Instead of maybe storing its own sysroot and maybe deferring to the one
in `Session::opts`, just clone the latter when necessary so one is
always directly available. This removes the need for the getter.
|
|
|
|
|
|
Encode a custom "producers" section in wasm files
This commit implements WebAssembly/tool-conventions#65 for wasm files
produced by the Rust compiler. This adds a bit of metadata to wasm
modules to indicate that the file's language includes Rust and the
file's "processed-by" tools includes rustc.
The thinking with this section is to eventually have telemetry in
browsers tracking all this.
|
|
This is a follow up to 8aa9267 which changed the driver to use lld
directly rather than invoking it through Clang. This change ensures
we pass all the necessary flags to lld.
|
|
This commit implements WebAssembly/tool-conventions#65 for wasm files
produced by the Rust compiler. This adds a bit of metadata to wasm
modules to indicate that the file's language includes Rust and the
file's "processed-by" tools includes rustc.
The thinking with this section is to eventually have telemetry in
browsers tracking all this.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This commit adds a new codegen option for the compiler which disables
rustc's passing of `-nodefaultlibs` by default on relevant platforms.
Sometimes Rust is linked with C code which fails to link with
`-nodefaultlibs` and is unnecessarily onerous to get linking correctly
with `-nodefaultlibs`.
An example of this is that when you compile C code with sanitizers and
then pass `-fsanitize=address` to the linker, it's incompatible with
`-nodefaultlibs` also being passed to the linker.
In these situations it's easiest to turn off Rust's default passing of
`-nodefaultlibs`, which was more ideological to start with than
anything! Preserving the default is somewhat important but having this
be opt-in shouldn't cause any breakage.
Closes #54237
|
|
This function isn't strictly tied to LLVM (it's more of a utility) and
it's now near an analogous, almost identical `filename_for_input` (for
rlibs and so forth).
Also this means not depending on the backend when one wants to know the
accurate .rmeta output filename.
|
|
|
|
Remove LinkMeta struct
Fixes #53291
|
|
try to infer linker flavor from linker name and vice versa
This is a second take on PR #50359 that implements the logic proposed in https://github.com/rust-lang/rust/pull/50359#pullrequestreview-116663121
With this change it would become possible to link `thumb*` binaries using GNU's LD on stable as `-C linker=arm-none-eabi-ld` would be enough to change both the linker and the linker flavor from their default values of `arm-none-eabi-gcc` and `gcc`.
To link `thumb*` binaries using rustc's LLD on stable `-Z linker-flavor` would need to be stabilized as `-C linker=rust-lld -Z linker-flavor=ld.lld` are both required to change the linker and the linker flavor, but this PR doesn't propose that. We would probably need some sort of stability guarantee around `rust-lld`'s name and availability to make linking with rustc's LLD truly stable.
With this change it would also be possible to link `thumb*` binaries using a system installed LLD on stable using the `-C linker=ld.lld` flag (provided that `ld.lld` is a symlink to the system installed LLD).
r? @alexcrichton
|
|
|
|
|
|
|
|
|
|
this field defaults to the LD / GNU flavor
|
|
|
|
|
|
|