rustbuild: smarter `git submodule`-ing
With this commit, if one bootstraps rust against system llvm then the
src/llvm submodule is not updated/checked-out. This saves considerable
network bandwith when starting from a fresh clone of rust-lang/rust as
the llvm submodule is never cloned.
cc #30107
r? @alexcrichton
cc @petevine
~~We could also avoid updating the jemalloc submodule if --disable-jemalloc is used. It just hasn't been implemented.~~ Done
This probably doesn't handle "recursive" submodules correctly but I think we don't have any of those right now.
I'm still testing a bootstrap but already confirmed that the llvm submodule doesn't get updated when `--llvm-root` is passed to `configure`.
Improve Demangling of Rust Symbols
This turns `..` into `::`, handles some more escapes and gets rid of unwanted underscores at the beginning of path elements.
Fix lifetime rules for 'if' conditions
Fixes#12033.
Changes the temporary scope rules to make the condition of an if-then-else a terminating scope. This is a [breaking-change].
Steps towards reproducible builds
cc #34902
Running `make dist` twice will result in a rustc tarball where only `librustc_back.so`, `librustc_llvm.so` and `librustc_trans.so` differ. Building `libstd` and `libcore` twice with the same compiler and flags produces identical artifacts.
The third commit should close#24473
Refactor `PathListItem`s
This refactors away variant `Mod` of `ast::PathListItemKind` and refactors the remaining variant `Ident` to a struct `ast::PathListItem_`.
rustbuild: skip filecheck check if codegen tests are disabled
to match the behavior of the old Makefile-based build system
closes#35752
r? @alexcrichton
initial support for s390x
A new target, `s390x-unknown-linux-gnu`, has been added to the compiler
and can be used to build no_core/no_std Rust programs.
Known limitations:
- librustc_trans/cabi_s390x.rs is missing. This means no support for
`extern "C" fn`.
- No support for this arch in libc. This means std can't be cross
compiled for this target.
r? @alexcrichton
This time I couldn't test running a binary cross compiled to this target under QEMU because the qemu-s390x that ships with Ubuntu 16.04 SIGABRTs with every s390x binary I run it with.
Change in binary size of `librustc_llvm.so`:
Without this commit (stage1): 41895736 bytes
With this commit (stage1): 42899016 bytes
~2.4% increase
rustc_trans: don't round up the DST prefix size to its alignment.
Fixes#35815 by using `ty::layout` and `min_size` to compute the size of the DST prefix.
`ty::layout::Struct::min_size` is not rounded up to alignment, which could be smaller for the DST field.
With this commit, if one bootstraps rust against system llvm then the
src/llvm submodule is not updated/checked-out. This saves considerable
network bandwith when starting from a fresh clone of rust-lang/rust as
the llvm submodule is never cloned.
cc #30107
This turns `..` into `::`, handles some more escapes and gets rid of
unwanted underscores at the beginning of path elements.
update error E0450 to new format
Fixes#35925 as part of #35233.
I've solve the bonus, and I wonder if any simpler way to do this. But may be possible simplify if let expressions?
r? @jonathandturner
memrchr: Correct aligned offset computation
The memrchr fallback did not compute the offset correctly. It was
intentioned to land on usize-aligned addresses but did not.
This was suspected to have resulted in a crash on ARMv7!
This bug affected non-linux platforms.
I think like this, if we have a slice with pointer `ptr` and length
`len`, we want to find the last usize-aligned offset in the slice.
The correct computation should be:
For example if ptr = 1 and len = 6, and `size_of::<usize>()` is 4:
```
[ x x x x x x ]
1 2 3 4 5 6
^-- last aligned address at offset 3 from the start.
```
The last aligned address is ptr + len - (ptr + len) % usize_size.
Compute offset from the start as:
offset = len - (ptr + len) % usize_size = 6 - (1 + 6) % 4 = 6 - 3 = 3.
I believe the function's return value was always correct previously, if
the platform supported unaligned addresses.
Fixes#35967
