Update E0194 to new error format
Fixes#35280 to update E0194 to support new error message format. Part of #35233.
A separate Github issue #36057 tracks the bonus portion of the original ticket.
r? @jonathandturner
improve `BitAnd` trait documentation
This pull request is based on the discussion in PR #35927.
Add a module-level note that `&&` and `||` are short-circuiting operators and not overloadable.
Add a simple `Scalar` example that lifts the `&` operator to a trivial struct tuple.
Make `BooleanVector` a struct tuple.
Derive `PartialEq` for `BooleanVector` instead of implementing it.
Adds a `fn main` wrapper so that the example can integrate with Rust Playground.
Updated code sample in chapter on syntax extensions.
The affected API apparently had changed with commit d59accfb06.
---
Further more I had to add
```toml
[lib]
name = "roman_numerals"
crate-type = ["dylib"]
```
to `Cargo.toml` as I otherwise got this compiler error (despite `#![crate_type="dylib"]`):
[E0457]: plugin `roman_numerals` only found in rlib format, but must be available in dylib format
Might be worth adding a note about that?
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
