improve documentation for `Fn*` traits
This PR is not yet a serious attempt at contribution. Rather, I'm opening this for discussion. I can think of a few things we may want to accomplish with the documentation of the `Fn`, `FnMut`, and `FnOnce` traits:
- the relationship between these traits and the closures that implement them
- examples of non-closure implementations
- the relationship between these traits and Rust's ownership semantics
show how iterating over `RangeTo` and `RangeToInclusive` fails
Feedback on PR #35701 seems to be positive, so this does the same thing for `RangeTo` and `RangeToInclusive`.
Doc: explain why Box/Rc/Arc methods do not take self
This can be confusing for newcomers, especially due to the argument name `this` that is used for Rc and Arc.
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
