Fix memory leak if C++ catches a Rust panic and discards it
If C++ catches a Rust panic using `catch (...)` and then chooses not to rethrow it, the `Box<dyn Any>` in the exception may be leaked. This PR fixes this by adding the necessary destructors to the exception object.
r? @Mark-Simulacrum
Prepare for LLVM 10 upgrade
Split off from #67759, this just adds the necessary compatibility bits and updates codegen tests, without performing the actual LLVM upgrade.
r? @alexcrichton
Compile some CGUs in parallel at the start of codegen
This brings the compilation time for `syntex_syntax` from 11.542s to 10.453s with 6 threads in non-incremental debug mode. Just compiling `n` CGUs in parallel at the beginning of codegen seems sufficient to get rid of the staircase effect, at least for `syntex_syntax`.
Based on https://github.com/rust-lang/rust/pull/67777.
r? @michaelwoerister
cc @alexcrichton @Mark-Simulacrum
Add simpler entry points to const eval for common usages.
I found the `tcx.const_eval` API to be complex/awkward to work with, because of the inherent complexity from all of the different situations it is called from. Though it mainly used in one of the following ways:
- Evaluates the value of a constant without any substitutions, e.g. evaluating a static, discriminant, etc.
- Evaluates the value of a resolved instance of a constant. this happens when evaluating unevaluated constants or normalising trait constants.
- Evaluates a promoted constant.
This PR adds three new functions `const_eval_mono`, `const_eval_resolve`, and `const_eval_promoted` to `TyCtxt`, which each cater to one of the three ways `tcx.const_eval`
is normally used.
Enable opting out of specific default LLVM arguments.
`rustc` by default adds a few arguments to LLVM (like `-mergefunc-use-aliases` for example). With this PR `rustc` will only emit these arguments if the same argument has not already been specified by the user via `-Cllvm-args`. This enables opting out of these defaults.
The PR also removes a PGO specific `-Z` flag the effect of which can also be easily achieved by `-Cllvm-args`.
Fixes https://github.com/rust-lang/rust/issues/64310.
save LTO import info and check it when trying to reuse build products
Fix#59535
Previous runs of LTO optimization on the previous incremental build can import larger portions of the dependence graph into a codegen unit than the current compilation run is choosing to import. We need to take that into account when we choose to reuse PostLTO-optimization object files from previous compiler invocations.
This PR accomplishes that by serializing the LTO import information on each incremental build. We load up the previous LTO import data as well as the current LTO import data. Then as we decide whether to reuse previous PostLTO objects or redo LTO optimization, we check whether the LTO import data matches. After we finish with this decision process for every object, we write the LTO import data back to disk.
----
What is the scenario where comparing against past LTO import information is necessary?
I've tried to capture it in the comments in the regression test, but here's yet another attempt from me to summarize the situation:
1. Consider a call-graph like `[A] -> [B -> D] <- [C]` (where the letters are functions and the modules are enclosed in `[]`)
2. In our specific instance, the earlier compilations were inlining the call to`B` into `A`; thus `A` ended up with a external reference to the symbol `D` in its object code, to be resolved at subsequent link time. The LTO import information provided by LLVM for those runs reflected that information: it explicitly says during those runs, `B` definition and `D` declaration were imported into `[A]`.
3. The change between incremental builds was that the call `D <- C` was removed.
4. That change, coupled with other decisions within `rustc`, made the compiler decide to make `D` an internal symbol (since it was no longer accessed from other codegen units, this makes sense locally). And then the definition of `D` was inlined into `B` and `D` itself was eliminated entirely.
5. The current LTO import information reported that `B` alone is imported into `[A]` for the *current compilation*. So when the Rust compiler surveyed the dependence graph, it determined that nothing `[A]` imports changed since the last build (and `[A]` itself has not changed either), so it chooses to reuse the object code generated during the previous compilation.
6. But that previous object code has an unresolved reference to `D`, and that causes a link time failure!
----
The interesting thing is that its quite hard to actually observe the above scenario arising, which is probably why no one has noticed this bug in the year or so since incremental LTO support landed (PR #53673).
I've literally spent days trying to observe the bug on my local machine, but haven't managed to find the magic combination of factors to get LLVM and `rustc` to do just the right set of the inlining and `internal`-reclassification choices that cause this particular problem to arise.
----
Also, I have tried to be careful about injecting new bugs with this PR. Specifically, I was/am worried that we could get into a scenario where overwriting the current LTO import data with past LTO import data would cause us to "forget" a current import. ~~To guard against this, the PR as currently written always asserts, at overwrite time, that the past LTO import-set is a *superset* of the current LTO import-set. This way, the overwriting process should always be safe to run.~~
* The previous note was written based on the first version of this PR. It has since been revised to use a simpler strategy, where we never attempt to merge the past LTO import information into the current one. We just *compare* them, and act accordingly.
* Also, as you can see from the comments on the PR itself, I was quite right to be worried about forgetting past imports; that scenario was observable via a trivial transformation of the regression test I had devised.
Fix handling of wasm import modules and names
The WebAssembly targets of rustc have weird issues around name mangling
and import the same name from different modules. This all largely stems
from the fact that we're using literal symbol names in LLVM IR to
represent what a function is called when it's imported, and we're not
using the wasm-specific `wasm-import-name` attribute. This in turn leads
to two issues:
* If, in the same codegen unit, the same FFI symbol is referenced twice
then rustc, when translating to LLVM IR, will only reference one
symbol from the first wasm module referenced.
* There's also a bug in LLD [1] where even if two codegen units
reference different modules, having the same symbol names means that
LLD coalesces the symbols and only refers to one wasm module.
Put another way, all our imported wasm symbols from the environment are
keyed off their LLVM IR symbol name, which has lots of collisions today.
This commit fixes the issue by implementing two changes:
1. All wasm symbols with `#[link(wasm_import_module = "...")]` are
mangled by default in LLVM IR. This means they're all given unique names.
2. Symbols then use the `wasm-import-name` attribute to ensure that the
WebAssembly file uses the correct import name.
When put together this should ensure we don't trip over the LLD bug [1]
and we also codegen IR correctly always referencing the right symbols
with the right import module/name pairs.
Closes#50021Closes#56309Closes#63562
[1]: https://bugs.llvm.org/show_bug.cgi?id=44316
adopts simple strategy devised with assistance from mw: Instead of accumulating
(and acting upon) LTO import information over an unbounded number of prior
compilations, just see if the current import set matches the previous import set.
if they don't match, then you cannot reuse the PostLTO build product for that
module.
In either case (of a match or a non-match), we can (and must) unconditionally
emit the current import set as the recorded information in the incremental
compilation cache, ready to be loaded during the next compiler run for use in
the same check described above.
resolves issue 59535.
The WebAssembly targets of rustc have weird issues around name mangling
and import the same name from different modules. This all largely stems
from the fact that we're using literal symbol names in LLVM IR to
represent what a function is called when it's imported, and we're not
using the wasm-specific `wasm-import-name` attribute. This in turn leads
to two issues:
* If, in the same codegen unit, the same FFI symbol is referenced twice
then rustc, when translating to LLVM IR, will only reference one
symbol from the first wasm module referenced.
* There's also a bug in LLD [1] where even if two codegen units
reference different modules, having the same symbol names means that
LLD coalesces the symbols and only refers to one wasm module.
Put another way, all our imported wasm symbols from the environment are
keyed off their LLVM IR symbol name, which has lots of collisions today.
This commit fixes the issue by implementing two changes:
1. All wasm symbols with `#[link(wasm_import_module = "...")]` are
mangled by default in LLVM IR. This means they're all given unique names.
2. Symbols then use the `wasm-import-name` attribute to ensure that the
WebAssembly file uses the correct import name.
When put together this should ensure we don't trip over the LLD bug [1]
and we also codegen IR correctly always referencing the right symbols
with the right import module/name pairs.
Closes#50021Closes#56309Closes#63562
[1]: https://bugs.llvm.org/show_bug.cgi?id=44316
rustllvm relies on the `LLVMRustStringWriteImpl` symbol existing, but
this symbol was previously defined in a *downstream* crate
(rustc_codegen_llvm, which depends on rustc_llvm.
While this somehow worked under the old 'separate bootstrap step for
codegen' scheme, it meant that rustc_llvm could not actually be built by
itself, since it relied linking to the downstream rustc_codegen_llvm
crate.
Now that librustc_codegen_llvm is just a normal crate, we actually try
to build a standalone rustc_llvm when we run tests. This commit moves
`LLVMRustStringWriteImpl` into rustc_llvm (technically the rustllvm
directory, which has its contents built by rustc_llvm). This ensures
that we can build each crate in the graph by itself, without requiring
that any downstream crates be linked in as well.
