Remove some imports to the rustc crate
- When we have `NestedVisitorMap::None`, we use `type Map = dyn intravisit::Map<'v>;` instead of the actual map. This doesn't actually result in dynamic dispatch (in the future we may want to use an associated type default to simplify the code).
- Use `rustc_session::` imports instead of `rustc::{session, lint}`.
r? @Zoxc
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
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
Making ICEs and test them in incremental
This adds:
- A way to make the compiler ICE
- A way to check for ICE in `cfail` tests with `should-ice`
- A regression test for issue #65401
I am not sure the attribute added `should-ice` is the best for this job
Rename `LocalInternedString` and more
This PR renames `LocalInternedString` as `SymbolStr`, removes an unnecessary `impl` from it, improves comments, and cleans up some `SymbolStr` uses.
r? @estebank
It's a full conversion, except in `DefKey::compute_stable_hash()` where
a `Symbol` now is converted to an `InternedString` before being hashed.
This was necessary to avoid test failures.
Remove tx_to_llvm_workers from TyCtxt
This can be kept within the codegen backend crates entirely -- there's no reason for us to create it outside and attempt to hold it in the (global) context.
Changes here aren't really too easily reviewable I suspect -- not sure if they can be cleaned up by splitting into more commits though, it's just hard to reason about `Box<Any>` in general. If there are thoughts though I'd be happy to hear them.
The primary goal of this PR is to get rid of the field on `rustc_interface::Queries`.
