* In the case of `derive-same-struct`, it seemed cleaner to add the
output than to try to modify the macro itself (which is where the
output is coming from).
* In the case of `custom-derive-partial-eq`, it was just easier to add
the output than to attempt to port the test to use a procedural
macro.
Namely, this adds support for:
* `// dont-check-compiler-stdout`, and
* `// dont-check-compiler-stderr`.
Obviously almost all ui tests wont want to opt into these, since the whole point
of a ui test is to check the compiler ui. However, since this PR is converting
run-pass into (another set of) ui tests, these header options make sense in that
context.
(Also this puts us into a better position for eventually turning
*every* test suite into a ui test suite, by making ui-ness the default
and forcing tests to opt out explicitly.)
std: Check for overflow in `str::repeat`
This commit fixes a buffer overflow issue in the standard library
discovered by Scott McMurray where if a large number was passed to
`str::repeat` it may cause and out of bounds write to the buffer of a `Vec`.
This bug was accidentally introduced in #48657 when optimizing the
`str::repeat` function. The bug affects stable Rust releases 1.26.0 to
1.29.0. We plan on backporting this fix to create a 1.29.1 release, and
the 1.30.0 release onwards will include this fix.
The fix in this commit is to introduce a deterministic panic in the case of
capacity overflow. When repeating a slice where the resulting length is larger
than the address space, there’s no way it can succeed anyway!
The standard library and surrounding libraries were briefly checked to see if
there were othere instances of preallocating a vector with a calculation that
may overflow. No instances of this bug (out of bounds write due to a calculation
overflow) were found at this time.
Note that this commit is the first steps towards fixing this issue,
we'll be making a formal post to the Rust security list once these
commits have been merged.
Rollup of 15 pull requests
Successful merges:
- #52813 (Duration div mul extras)
- #53470 (Warn about metadata loader errors)
- #54233 (Remove LLVM 3.9 workaround.)
- #54257 (Switch wasm math symbols to their original names)
- #54258 (Enable fatal warnings for the wasm32 linker)
- #54266 (Update LLVM to fix "bool" arguments on PPC32)
- #54290 (Switch linker for aarch64-pc-windows-msvc from LLD to MSVC)
- #54292 (Suggest array indexing when tuple indexing on an array)
- #54295 (A few cleanups and minor improvements to rustc/traits)
- #54298 (miri: correctly compute expected alignment for field)
- #54333 (Update The Book to latest)
- #54337 (Remove unneeded clone() from tests in librustdoc)
- #54346 (rustc: future-proof error reporting for polymorphic constants in types.)
- #54362 (Pass --batch to gdb)
- #54367 (Add regression test for thread local static mut borrows)
This commit fixes a buffer overflow issue in the standard library
discovered by Scott McMurray where if a large number was passed to
`str::repeat` it may cause and out of bounds write to the buffer of a `Vec`.
This bug was accidentally introduced in #48657 when optimizing the
`str::repeat` function. The bug affects stable Rust releases 1.26.0 to
1.29.0. We plan on backporting this fix to create a 1.29.1 release, and
the 1.30.0 release onwards will include this fix.
The fix in this commit is to introduce a deterministic panic in the case of
capacity overflow. When repeating a slice where the resulting length is larger
than the address space, there’s no way it can succeed anyway!
The standard library and surrounding libraries were briefly checked to see if
there were othere instances of preallocating a vector with a calculation that
may overflow. No instances of this bug (out of bounds write due to a calculation
overflow) were found at this time.
Note that this commit is the first steps towards fixing this issue,
we'll be making a formal post to the Rust security list once these
commits have been merged.
Add regression test for thread local static mut borrows
FIXME(#54366) - We probably shouldn't allow `#[thread_local] static mut` to get a `'static` lifetime, but for now, we should at least test the behavior that `rustc` currently has.
Pass --batch to gdb
In one of my travis builds, I was surprised to find that the gdb
pager was in use and caused travis to time out. Adding `--batch`
to the gdb invocation will disable the pager. Note that the
`-ex q` is retained, to make sure gdb exits with status 0, just in
case `set -e` is in effect somehow.
rustc: future-proof error reporting for polymorphic constants in types.
Currently, we have 3 categories of positions where a constant can be used (`const` and associated `const` can be considered "aliases" for an expression):
* runtime - if the function is polymorphic, we could even just warn and emit a panic
* `static` - always monomorphic, so we can error at definition site
* type-system - **must** *enforce* evaluation success where it was written
That last one is the tricky one, because we can't easily turn *the presence* a type with an erroring const into a runtime panic, and we'd have to do post-monomorphization errors (which we'd rather avoid).
<hr/>
The solution we came up with, as part of the plans for const generics, is to require successful evaluation wherever a constant shows up in a type (currently in array lengths, and values for const parameters in the future), *through* the WF system, which means that in certain situations (e.g. function signatures) we can assume evaluation *will* succeed, and require it of users (e.g. callers) instead (we've been doing this for lifetime bounds, for a long time now, and it's pretty ergonomic).
So once we do sth about #43408, this example *should* work, by propagating the responsability, to callers of `foo::<X>`, of proving `std::mem::size_of::<X>()` succeeds (and those callers can do the same).
```rust
pub fn foo<T>(_: [u8; std::mem::size_of::<T>()]) {}
```
But this one *shouldn't*, as there is nothing in the signature/bounds to indicate it:
```rust
pub fn bar<T>() {
let _: [u8; std::mem::size_of::<T>()];
}
```
<hr/>
I've come across some bit of code in the compiler that ignores const-evaluation errors *even when* they come from a constant in a type, and I've added an ICE *only when* there are no other reported errors (e.g. it's fine to ignore evaluation errors if the constant doesn't even type-check).
r? @nikomatsakis cc @oli-obk @RalfJung @Centril
Remove unneeded clone() from tests in librustdoc
The expected.clone() calls were not needed for the tests. This is
just to keep consistency between the test cases.
rustdoc: collect trait impls as an early pass
Fixes https://github.com/rust-lang/rust/issues/52545, fixes https://github.com/rust-lang/rust/issues/41480, fixes https://github.com/rust-lang/rust/issues/36922
Right now, rustdoc pulls all its impl information by scanning a crate's HIR for any items it finds. However, it doesn't recurse into anything other than modules, preventing it from seeing trait impls that may be inside things like functions or consts. Thanks to https://github.com/rust-lang/rust/pull/53002, now these items actually *exist* for rustdoc to see, but they still weren't getting collected for display.
But there was a secret. Whenever we pull in an item from another crate, we don't have any of its impls in the local HIR, so instead we ask the compiler for *everything* and filter out after the fact. This process is only triggered if there's a cross-crate re-export in the crate being documented, which can sometimes leave this info out of the docs. This PR instead moves this collection into an early pass, which occurs immediately after crate cleaning, so that that collection occurs regardless. In addition, by including the HIR's own `trait_impls` in addition to the existing `all_trait_implementations` calls, we can collect all these tricky trait impls without having to scan for them!
A few cleanups and minor improvements to rustc/traits
It's a little bigger than usual, so bear with me ^^:
- introduce `TyCtxt::all_impls` and use it to avoid inefficiently allocating push loops
- modify `ArgKind::from_expected_ty` to take an `Option<Span>` argument to make it more versatile
- replace `ArgKind::Arg("_".to_owned(), "_".to_owned())` with `ArgKind::empty`
- move early `return`s earlier where possible
- if all branches of a `match` end with the same expression, move it after it
- change a hacky `match` expression to an `if else` chain
- move the `push` out from a push loop closure to reduce the number of allocations
- correct the vector size for `pretty_predicates` (under `specialize`)
- take advantage of the fact that `if else` is an expression
- prefer `cloned()` to `map(|&x| x)` and `map(|x| *x)`
- prefer `vec![x; y.len()]` to `y.map(|_| x).collect()`
- use `unwrap_or_else` instead of `match` where applicable
- use `if let` instead of `match` when only one branch matters
- prefer `to_owned` to `to_string` for string literals
- remove explicit `return`s
- remove superfluous braces
- whitespace fixes
- several other minor improvements
Switch linker for aarch64-pc-windows-msvc from LLD to MSVC
The MSVC linker does not seem to have the same problems with Rust symbols that LLD currently has on Windows (see https://github.com/rust-lang/rust/issues/54190#issuecomment-421288625). This PR makes MSVC the default linker for `aarch64-pc-windows-msvc`.
r? @alexcrichton
Enable fatal warnings for the wasm32 linker
Historically LLD has emitted warnings for various reasons but all the bugs have
since been fixed (yay!) and by enabling fatal warnings we should be able to head
off bugs like #53390 sooner.
Switch wasm math symbols to their original names
The names `Math_*` were given to help undefined symbol messages indicate how to
implement them, but these are all implemented in compiler-rt now so there's no
need to rename them! This change should make it so wasm binaries by default, no
matter the math symbols used, will not have unresolved symbols.
Warn about metadata loader errors
Output when writing corrupting to libcore.rlib
```
warning: no metadata found: failed to read rlib metadata in '/Users/bjorn/Documents/rust_fork/build/x86_64-apple-darwin/stage1-std/x86_64-apple-darwin/release/deps/libcore-857d662d379c5d0c.rlib': File too small to be an archive
error[E0463]: can't find crate for `core`
error: aborting due to previous error
```
Fixes#53381
Duration div mul extras
Successor of #52556.
This PR adds the following `impl`s:
- `impl Mul<Duration> for u32` (to allow `10*SECOND` in addition to `SECOND*10`)
- `impl Mul<f64> for Duration` (to allow `2.5*SECOND` vs `2*SECOND + 500*MILLISECOND`)
- `impl Mul<Duration> for f64`
- `impl MulAssign<f64> for Duration`
- `impl Div<f64> for Duration`
- `impl DivAssign<f64> for Duration`
- `impl Div<Duration> for Duration` (`Output = f64`, can be useful e.g. for `duration/MINUTE`)
`f64` is chosen over `f32` to minimize rounding errors. (52 bits fraction precision vs `Duration`'s ~94 bit)
constraints:
- clean/inline.rs needs this map to fill in traits when inlining
- fold.rs needs this map to allow passes to fold trait items
- html/render.rs needs this map to seed the Cache.traits map of all
known traits
The first two are the real problem, since `DocFolder` only operates on
`clean::Crate` but `clean/inline.rs` only sees the `DocContext`. The
introduction of early passes means that these two now exist at the same
time, so they need to share ownership of the map. Even better, the use
of `Crate` in a rustc thread pool means that it needs to be Sync, so it
can't use `Lrc<Lock>` to manually activate thread-safety.
`parking_lot` is reused from elsewhere in the tree to allow use of its
`ReentrantMutex`, as the relevant parts of rustdoc are still
single-threaded and this allows for easier use in that context.
