Upgrade Emscripten targets to use upstream LLVM backend
- Refactors the Emscripten target spec to share code with other wasm
targets.
- Replaces the incorrect wasm32 C call ABI with the old asmjs
version, which is correct for both wasm32 and JS.
- Updates the varargs ABI used by Emscripten and deletes the old one.
- Removes the obsolete wasm32-experimental-emscripten target.
- Temporarily makes Emscripten targets use panic=abort by default
because supporting unwinding will require an LLVM patch.
- Refactors the Emscripten target spec to share code with other wasm
targets.
- Replaces the incorrect wasm32 C call ABI with the old asmjs
version, which is correct for both wasm32 and JS.
- Updates the varargs ABI used by Emscripten and deletes the old one.
- Removes the obsolete wasm32-experimental-emscripten target.
- Temporarily makes Emscripten targets use panic=abort by default
because supporting unwinding will require an LLVM patch.
SelfProfiler API refactoring and part one of event review
This PR refactors the `SelfProfiler` a little bit so that most profiling methods are RAII-based. The codegen backend code already had something similar, this refactoring pulls this functionality up into `SelfProfiler` itself, for general use.
The second commit of this PR is a review and update of the existing events we are already recording. Names have been made more consistent. CGU names have been removed from event names. They will be added back in when function parameter recording is implemented.
There is still some work to be done for adding new events, especially around trait resolution and the incremental system.
r? @wesleywiser
No StableHasherResult everywhere
This removes the generic parameter on `StableHasher`, instead moving it to the call to `finish`. This has the side-effect of making all `HashStable` impls nicer, since we no longer need the verbose `<W: StableHasherResult>` that previously existed -- often forcing line wrapping.
This is done for two reasons:
* we should avoid false "generic" dependency on the result of StableHasher
* we don't need to codegen two/three copies of all the HashStable impls when they're transitively used to produce a fingerprint, u64, or u128. I haven't measured, but this might actually make our artifacts somewhat smaller too.
* Easier to understand/read/write code -- the result of the stable hasher is irrelevant when writing a hash impl.
Rename `*.node` to `*.kind`, and `hair::Pattern*` to `hair::Pat*`
In both `ast::Expr` and `hir::Expr`:
- Rename `Expr.node` to `Expr.kind`.
- Rename `Pat.node` to `Pat.kind`.
- Rename `ImplItem.node` to `ImplItem.kind`.
- Rename `Lit.node` to `Lit.kind`.
- Rename `TraitItem.node` to `TraitItem.kind`.
- Rename `Ty.node` to `Ty.kind`.
- Rename `Stmt.node` to `Stmt.kind`.
- Rename `Item.node` to `Item.kind`.
- Rename `ForeignItem.node` to `ForeignItem.kind`.
- Rename `MetaItem.node` to `MetaItem.kind`.
Also:
- Rename `hair::FieldPattern` to `hair::FieldPat`.
- Rename `hair::PatternKind` to `hair::PatKind`.
- Rename `hair::PatternRange` to `hair::PatRange`.
- Rename `PatternContext` to `PatCtxt`.
- Rename `PatternTypeProjection` to `PatTyProj`.
- Rename `hair::Pattern` to `hair::Pat`.
These two sets of changes are grouped together to aid with merging. The only changes are renamings.
r? @petrochenkov
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`.
rustc: Fix mixing crates with different `share_generics`
This commit addresses #64319 by removing the `dylib` crate type from the
list of crate type that exports generic symbols. The bug in #64319
arises because a `dylib` crate type was trying to export a symbol in an
uptream crate but it miscalculated the symbol name of the uptream
symbol. This isn't really necessary, though, since `dylib` crates aren't
that heavily used, so we can just conservatively say that the `dylib`
crate type never exports generic symbols, forcibly removing them from
the exported symbol lists if were to otherwise find them.
The fix here happens in two places:
* First is in the `local_crate_exports_generics` method, indicating that
it's now `false` for the `Dylib` crate type. Only rlibs actually
export generics at this point.
* Next is when we load exported symbols from upstream crate. If, for our
compilation session, the crate may be included from a dynamic library,
then its generic symbols are removed. When the crate was linked into a
dynamic library its symbols weren't exported, so we can't consider
them a candidate to link against.
Overally this should avoid situations where we incorrectly calculate the
upstream symbol names in the face of differnet `share_generics` options,
ultimately...
Closes#64319
This commit addresses #64319 by removing the `dylib` crate type from the
list of crate type that exports generic symbols. The bug in #64319
arises because a `dylib` crate type was trying to export a symbol in an
uptream crate but it miscalculated the symbol name of the uptream
symbol. This isn't really necessary, though, since `dylib` crates aren't
that heavily used, so we can just conservatively say that the `dylib`
crate type never exports generic symbols, forcibly removing them from
the exported symbol lists if were to otherwise find them.
The fix here happens in two places:
* First is in the `local_crate_exports_generics` method, indicating that
it's now `false` for the `Dylib` crate type. Only rlibs actually
export generics at this point.
* Next is when we load exported symbols from upstream crate. If, for our
compilation session, the crate may be included from a dynamic library,
then its generic symbols are removed. When the crate was linked into a
dynamic library its symbols weren't exported, so we can't consider
them a candidate to link against.
Overally this should avoid situations where we incorrectly calculate the
upstream symbol names in the face of differnet `share_generics` options,
ultimately...
Closes#64319
This commit converts a field of `Session`, `dependency_formats`, into a
query of `TyCtxt`. This information then also needed to be threaded
through to other remaining portions of the linker, but it's relatively
straightforward. The only change here is that instead of
`HashMap<CrateType, T>` the data structure changed to `Vec<(CrateType,
T)>` to make it easier to deal with in queries.
Refactor librustc_errors::Handler API
This should be reviewed by-commit.
The last commit moves all fields into an inner struct behind a single lock; this is done to prevent possible deadlocks in a multi-threaded compiler, as well as inconsistent state observation.
codegen: use "_N" (like for other locals) instead of "argN", for argument names.
Based on #64408 (second commit is new), fixing something I mentioned in #64408 (which turned to be an immediate blocker for unifying relevant codepaths).
Closes#64408 (by containing it).
r? @rkruppe
[Place 2.0] Convert Place's projection to a boxed slice
This is still work in progress, it's not compiling right now I need to review a bit more to see what's going on but wanted to open the PR to start discussing it.
r? @oli-obk
place: Passing `align` = `layout.align.abi`, when also passing `layout`
Of the calls changed:
7/12 use `align` = `layout.align.abi`.
`from_const_alloc` uses `alloc.align`, but that is `assert_eq!` to `layout.align.abi`.
only 4/11 use something interesting for `align`.
so rename it `new_sized_aligned`.
6/11 use `align` = `layout.align.abi`.
`from_const_alloc` uses `alloc.align`, but that is `assert_eq!` to `layout.align.abi`.
only 4/11 use something interesting for `align`.
