| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Implement RFC 1861: Extern types
A few notes :
- Type parameters are not supported. This was an unresolved question from the RFC. It is not clear how useful this feature is, and how variance should be treated. This can be added in a future PR.
- `size_of_val` / `align_of_val` can be called with extern types, and respectively return 0 and 1. This differs from the RFC, which specified that they should panic, but after discussion with @eddyb on IRC this seems like a better solution.
If/when a `DynSized` trait is added, this will be disallowed statically.
- Auto traits are not implemented by default, since the contents of extern types is unknown. This means extern types are `!Sync`, `!Send` and `!Freeze`. This seems like the correct behaviour to me.
Manual `unsafe impl Sync for Foo` is still possible.
- This PR allows extern type to be used as the tail of a struct, as described by the RFC :
```rust
extern {
type OpaqueTail;
}
#[repr(C)]
struct FfiStruct {
data: u8,
more_data: u32,
tail: OpaqueTail,
}
```
However this is undesirable, as the alignment of `tail` is unknown (the current PR assumes an alignment of 1). Unfortunately we can't prevent it in the general case as the tail could be a type parameter :
```rust
#[repr(C)]
struct FfiStruct<T: ?Sized> {
data: u8,
more_data: u32,
tail: T,
}
```
Adding a `DynSized` trait would solve this as well, by requiring tail fields to be bound by it.
- Despite being unsized, pointers to extern types are thin and can be casted from/to integers. However it is not possible to write a `null<T>() -> *const T` function which works with extern types, as I've explained here : https://github.com/rust-lang/rust/issues/43467#issuecomment-321678621
- Trait objects cannot be built from extern types. I intend to support it eventually, although how this interacts with `DynSized`/`size_of_val` is still unclear.
- The definition of `c_void` is unmodified
|
|
|
|
|
|
This commit updates the bootstrap compiler, bumps the version to 1.23, updates
Cargo, updates books, and updates crates.io dependencies
|
|
Initially MIR differentiated between arguments and locals, which
introduced a need to add extra copies assigning the argument to a
local, even for simple bindings. This differentiation no longer exists,
but we're still creating those copies, bloating the MIR and LLVM IR we
emit.
Additionally, the current approach means that we create debug info for
both the incoming argument (marking it as an argument), and then
immediately shadow it a local that goes by the same name. This can be
confusing when using e.g. "info args" in gdb, or when e.g. a debugger
with a GUI displays the function arguments separately from the local
variables, especially when the binding is mutable, because the argument
doesn't change, while the local variable does.
|
|
Use 128 bit instead of Symbol for crate disambiguator
As discussed on gitter, this changes `crate_disambiguator` from Strings to what they are represented as, a 128 bit number.
There's also one bit I think also needs to change, but wasn't 100% sure how: [create_root_def](https://github.com/rust-lang/rust/blob/f338dba29705e144bad8b2a675284538dd514896/src/librustc/hir/map/definitions.rs#L468-L482). Should I change `DefKey::root_parent_stable_hash` to accept `Fingerprint` as crate_disambiguator to quickly combine the hash of `crate_name` with the new 128 bit hash instead of a string for a disambiguator?
r? @michaelwoerister
EDIT: Are those 3 tests `mir-opt` failing, because the hash is different, because we calculate it a little bit differently (storing directly instead of hashing the hex-string representation)? Should it be updated like in #45319?
|
|
|
|
Create NormalizeTy query
As part of the effort to solve #44891, I've created the normalize_ty query.
As outlined in the issue this meant:
- renamed `normalize_associated_type()` to `normalize_associated_type_in()`
- created the `normalize_ty` query
- substituted the use of memoize with the query
This PR is not ready. While running tests, one of the incremental ones failed. [This](https://pastebin.com/vGhH6bv6) is the error I got.
|
|
|
|
|
|
incremental test-suite.
|
|
|
|
This commit moves compression of the bytecode from the `link` module to the
`write` module, namely allowing it to be (a) cached by incremental compilation
and (b) produced in parallel. The parallelization may show up as some nice wins
during normal compilation and the caching in incremental mode should be
beneficial for incremental compiles! (no more need to recompress the entire
crate's bitcode on all builds)
|
|
Move collector to rustc_trans_utils
|
|
rustc: Add `_imp_` symbols later in compilation
On MSVC targets rustc will add symbols prefixed with `_imp_` to LLVM modules to
"emulate" dllexported statics as that workaround is still in place after #27438
hasn't been solved otherwise. These statics, however, were getting gc'd by
ThinLTO accidentally which later would cause linking failures.
This commit updates the location we add such symbols to happen just before
codegen to ensure that (a) they're not eliminated by the optimizer and (b) the
optimizer doesn't even worry about them.
Closes #45347
|
|
incr.comp.: Use 128bit SipHash for fingerprinting
This PR switches incr. comp. result fingerprinting from 128 bit BLAKE2 to 128 bit SipHash. When we started using BLAKE2 for fingerprinting, the 128 bit version of SipHash was still experimental. Now that it isn't anymore we should be able to get a nice performance boost without significantly increasing collision probability.
~~I'm going to start a try-build for this, so we can gauge the performance impact before merging (hence the `WIP` in the title).~~
EDIT: Performance improvements look as expected. Tests seem to be passing.
Fixes #41215.
|
|
|
|
On MSVC targets rustc will add symbols prefixed with `_imp_` to LLVM modules to
"emulate" dllexported statics as that workaround is still in place after #27438
hasn't been solved otherwise. These statics, however, were getting gc'd by
ThinLTO accidentally which later would cause linking failures.
This commit updates the location we add such symbols to happen just before
codegen to ensure that (a) they're not eliminated by the optimizer and (b) the
optimizer doesn't even worry about them.
Closes #45347
|
|
The extra alloca was only necessary because it made LLVM implicitly
handle the necessary deref to get to the actual value. The same happens
for indirect arguments that have the byval attribute. But the Rust ABI
does not use the byval attribute and so we need to manually add the
deref operation to the debuginfo.
|
|
aarch64 is not whitelisted for ARM features
This prevents the target feature `neon` from being enabled on aarch64.
|
|
rustc: Handle #[inline(always)] at -O0
This commit updates the handling of `#[inline(always)]` functions at -O0 to
ensure that it's always inlined regardless of the number of codegen units used.
Closes #45201
|
|
|
|
|
|
|
|
First the `addPreservedGUID` function forgot to take care of "alias" summaries.
I'm not 100% sure what this is but the current code now matches upstream. Next
the `computeDeadSymbols` return value wasn't actually being used, but it needed
to be used! Together these should...
Closes #45195
|
|
Add x86_64-unknown-linux-gnux32 target
This adds X32 ABI support for Linux on X86_64. Let's package and dist it so we can star testing libc, libstd, etc.
Fixes https://github.com/rust-lang/rfcs/issues/1339
|
|
Queryify Vtable methods
This query might come with a downside: It converts an iterator to a Vec, which may increase the working set of rustc on programs that use many many traits (I think that's where this is used).
|
|
cleanup: rustc doesn't use an external archiver
cc https://github.com/rust-lang/rust/pull/45090
r? @alexcrichton
|
|
r=nikomatsakis
incr.comp.: Bring back output of -Zincremental-info.
This got kind lost during the transition to red/green.
I also switched back from `eprintln!()` to `println!()` since the former never actually produced any output. I suspect this has to do with `libterm` somehow monopolizing `stderr`.
r? @nikomatsakis
|
|
|
|
|
|
|
|
rustc: Allow target-specific default cgus
Some targets, like msp430 and nvptx, don't work with multiple codegen units
right now for bugs or fundamental reasons. To expose this allow targets to
express a default.
Closes #45000
|
|
rustc: Add LLVM `nounwind` with `-C panic=abort`
This informs LLVM that functions can't unwind, which while it should typically
have already been inferred when necessary or otherwise not impact codegen is
apparently needed on targets like ARM to avoid references to unnecessary
symbols.
Closes #44992
|
|
r=nikomatsakis
incr.comp.: Fix HashStable for ty::RegionKind and trans item order
Fixes #45161 and the failing rust-icci tests.
r? @nikomatsakis
|
|
Turn `trans_fulfill_obligation` into a query
Part of #44891
|
|
|
|
This commit updates the handling of `#[inline(always)]` functions at -O0 to
ensure that it's always inlined regardless of the number of codegen units used.
Closes #45201
|
|
This informs LLVM that functions can't unwind, which while it should typically
have already been inferred when necessary or otherwise not impact codegen is
apparently needed on targets like ARM to avoid references to unnecessary
symbols.
Closes #44992
|
|
|
|
Some targets, like msp430 and nvptx, don't work with multiple codegen units
right now for bugs or fundamental reasons. To expose this allow targets to
express a default.
Closes #45000
|
|
|
|
Don't panic in the coordinator thread, bubble up the failure
Fixes #43402 (take 2)
Followup to #45019, this makes the coordinator thread not panic on worker failures since they can be reported reasonably back in the main thread.
The output also now has no evidence of backtraces at all, unlike the previous PR:
```
$ ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc -o "" x.rs
error: could not write output to : No such file or directory
error: aborting due to previous error
```
r? @alexcrichton
|
|
rustc: Don't inline in CGUs at -O0
This commit tweaks the behavior of inlining functions into multiple codegen
units when rustc is compiling in debug mode. Today rustc will unconditionally
treat `#[inline]` functions by translating them into all codegen units that
they're needed within, marking the linkage as `internal`. This commit changes
the behavior so that in debug mode (compiling at `-O0`) rustc will instead only
translate `#[inline]` functions into *one* codegen unit, forcing all other
codegen units to reference this one copy.
The goal here is to improve debug compile times by reducing the amount of
translation that happens on behalf of multiple codegen units. It was discovered
in #44941 that increasing the number of codegen units had the adverse side
effect of increasing the overal work done by the compiler, and the suspicion
here was that the compiler was inlining, translating, and codegen'ing more
functions with more codegen units (for example `String` would be basically
inlined into all codegen units if used). The strategy in this commit should
reduce the cost of `#[inline]` functions to being equivalent to one codegen
unit, which is only translating and codegen'ing inline functions once.
Collected [data] shows that this does indeed improve the situation from [before]
as the overall cpu-clock time increases at a much slower rate and when pinned to
one core rustc does not consume significantly more wall clock time than with one
codegen unit.
One caveat of this commit is that the symbol names for inlined functions that
are only translated once needed some slight tweaking. These inline functions
could be translated into multiple crates and we need to make sure the symbols
don't collideA so the crate name/disambiguator is mixed in to the symbol name
hash in these situations.
[data]: https://github.com/rust-lang/rust/issues/44941#issuecomment-334880911
[before]: https://github.com/rust-lang/rust/issues/44941#issuecomment-334583384
|
|
rustc: Don't create empty codegen units
This'll end up just creating a bunch of object files that otherwise wouldn't
exist, so skip that extra work if possible.
|
|
rustc_trans: do not set NoCapture for anonymous lifetime &T arguments.
This was both unsound (due to lifetime elision & unsafe code) and dead code (we erase lifetimes).
r? @nikomatsakis
|
|
Fixes #43402 (take 2)
|
|
Part of #44891
|
