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
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
`ty::Predicate` was being used as a key for a hash map, but its hash
implementation indirectly hashed addresses, which vary between each
compiler run. This is fixed by sorting predicates by their ID before
encoding them.
In my tests, rustc is now able to produce deterministic results when
compiling libcore and libstd.
I've beefed up `run-make/reproducible-build` to compare the produced
artifacts bit-by-bit. This doesn't catch everything, but should be a
good start.
cc #34902
* A step towards #34902
* More stable error messages in some places related to crate loading
* Possible slight performance improvements since all `HashMap`s
replaced had small keys where `FnvHashMap` should be faster
(although I didn't measure)
rustc_borrowck: Don't hash types in loan paths
1) Types for equal loan paths are not always equal, they can sometimes differ in lifetimes, making equal loan paths hash differently.
Example:
71bdeea561/src/libcollections/linked_list.rs (L835-L856)
One of `self.list`s has type
```
&ReFree(CodeExtent(15013/CallSiteScope { fn_id: 18907, body_id: 18912 }), BrNamed(0:DefIndex(3066), 'a(397), WontChange)) mut linked_list::LinkedList<T>
```
and other has type
```
&ReScope(CodeExtent(15018/Remainder(BlockRemainder { block: 18912, first_statement_index: 0 }))) mut linked_list::LinkedList<T>
```
(... but I'm not sure it's not a bug actually.)
2) Not hashing types is faster than hashing types.
r? @arielb1
Combine types and regions in Substs into one interleaved list.
Previously, `Substs` would contain types and regions, in two separate vectors, for example:
```rust
<X as Trait<'a, 'b, A, B>>::method::<'p, 'q, T, U>
/* corresponds to */
Substs { regions: ['a, 'b, 'p, 'q], types: [X, A, B, T, U] }
```
This PR continues the work started in #35605 by further removing the distinction.
A new abstraction over types and regions is introduced in the compiler, `Kind`.
Each `Kind` is a pointer (`&TyS` or `&Region`), with the lowest two bits used as a tag.
Two bits were used instead of just one (type = `0`, region = `1`) to allow adding more kinds.
`Substs` contain only a `Vec<Kind>`, with `Self` first, followed by regions and types (in the definition order):
```rust
Substs { params: [X, 'a, 'b, A, B, 'p, 'q, T, U] }
```
The resulting interleaved list has the property of being the concatenation of parameters for the (potentially) nested generic items it describes, and can be sliced back into those components:
```rust
params[0..5] = [X, 'a, 'b, A, B] // <X as Trait<'a, 'b, A, B>>
params[5..9] = ['p, 'q, T, U] // <_>::method::<'p, 'q, T, U>
```
r? @nikomatsakis
Improve error message when failing to parse a block
We want to catch this error:
```
if (foo)
bar;
```
as it's valid syntax in other languages, and say how to fix it.
Unfortunately it didn't care if the suggestion made sense and just
highlighted the unexpected token.
Now it attempts to parse a statement, and if it succeeds, it shows the
help message.
Fixes#35907
Remove style guide.
We originally imported this into the repository with the intent of
fixing it up. Instead, nothing happened.
Its appearance on rust-lang.org makes it seem semi-official, but it's
not. The rustfmt strike team will end up producing something like this
anyway, and leaving it around does nothing but mislead people.
r? @aturon
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 be cross compiled
for this target.
[MIR] track Location in MirVisitor, combine Location
All the users of MirVisitor::visit_statement implement their own statement index tracking. This PR move the tracking into MirVisitor itself.
Also, there were 2 separate implementations of Location that were identical. This PR eliminates one of them.
