Use no_default_libraries for all NetBSD flavors
The no_default_libraries was introduced in #28578 because the
NetBSD-based rumprun needed to disable the link flag.
This moves the definition to be used by all NetBSD linker flavors to
close#49627.
A different solution would be adding -lc but as there is no platform
with explicit -lc, this approach is used.
add -Zui-testing to rustdoc
Before we depend on the `rustdoc-ui` tests some more, let's make rustdoc act the same as the compiler when they're actually being executed.
Improve handling of type bounds in `bit_set.rs`.
Currently, `BitSet` doesn't actually know its own domain size; it just
knows how many words it contains. We can make it better.
remove (more) CAS API from Atomic* types where not natively supported
closes#54276
In PR #51953 I made the Atomic* types available on targets like thumbv6m and
msp430 with the intention of *only* exposing the load and store API on those
types -- the rest of the API doesn't work on those targets because the are no
native instructions to implement CAS loops.
Unfortunately, it seems I didn't properly cfg away all the CAS API on those
targets, as evidenced in #54276. This PR amends the issue by removing the rest
of the CAS API.
This is technically a breaking change because *libraries* that were using this
API and were being compiled for e.g. thumbv6m-none-eabi will stop compiling.
However, using those libraries (before this change) in programs (binaries) would
lead to linking errors when compiled for e.g. thumbv6m so this change
effectively shifts a linker error in binaries to a compiler error in libraries.
On a side note: extending the Atomic API is a bit error prone because of these
non-cas targets. Unless the author of the change is aware of these targets and
properly uses `#[cfg(atomic = "cas")]` they could end up exposing new CAS API on
these targets. I can't think of a test to check that an API is not present on
some target, but we could extend the `tidy` tool to check that *all* newly added
atomic API has the `#[cfg(atomic = "cas")]` attribute unless it's whitelisted in
`tidy` then the author of the change would have to verify if the API can be used
on non-cas targets.
In any case, I'd like to plug this hole ASAP. We can revisit testing in a
follow-up issue / PR.
r? @alexcrichton
cc @mvirkkunen
define copy_within on slices
This is a safe wrapper around `ptr::copy`, for regions within a single slice. Previously, safe in-place copying was only available as a side effect of `Vec::drain`.
I've wanted this API a couple times in the past, and I figured I'd just whip up a PR to help discuss it. It's possible something like this exists elsewhere and I just missed it. It might also be a big enough addition to warrant an RFC, I'm not sure.
Stabilize crate_in_paths, extern_absolute_paths and extern_prelude on all editions.
Needed for beta, path-related migrations to Rust 2018 don't work on RC1 without these stabilizations.
r? @aturon cc @nikomatsakis @Centril @alexcrichton
`ui`ify run-pass
This addresses the remainder of #53764 by first converting `src/test/run-pass` into another `ui`-style test suite, and then turning on `compare-mode=nll` for that new suite.
After this lands, we can address #54047 for the short term by moving all the `src/test/ui/run-pass` tests back to `src/test/run-pass`.
(Longer term, the compiler team's current (hypothetical sketch of a) plan (see [1][], [2][]) is unify all the tests by embedding these meta-properties like "// run-pass` into their headers explicitly and dropping the significance of their location on the file system.)
[1]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/weekly.20meeting.202018-09-13/near/133889370
[2]: https://github.com/rust-lang/rust/issues/54047#issuecomment-421030356
This commit brings in a few Cargo updates
* Updates Cargo with experimental HTTP/2 support - a post on the forums
will be made about testing this when available.
* Bumps Cargo's own version number
* 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.)
Profiling shows that the `(reader, writer, used)` triples used by
liveness analysis almost always have invalid `reader` and `writer`
fields. We can take advantage of this knowledge to use a compressed
representation for them, falling back to a secondary table for the
uncommon cases.
This change reduces instruction counts on numerous benchmarks, the best
by 16%. It also reduces max-rss on numerous benchmarks, the best by 38%.
The patch also renames these triples from `Users` to `RWU`, because it's
confusing having a type whose name is plural and then used within
vectors whose names are also plural.
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)
`src/test/ui/extern/extern-const.rs` seems to have an inconsistent behaviour across build configurations, possibly non-deterministically. This is tracked in issue 54388.
For this PR, disable running rustfix on it because it failed on CI, until that issue is fixed.
The no_default_libraries was introduced in #28578 because the
NetBSD-based rumprun needed to disable the link flag.
This moves the definition to be used by all NetBSD linker flavors to
close#49627.
A different solution would be adding -lc but as there is no platform
with explicit -lc, this approach is used.
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
