This applies the same fix as added in 595d5b2f which is to just compile all
valgrind tests statically instead of dynamically. It looks like this is a
resurgence of either #30383 or #31328 in some weird fashion.
I'm not actually sure what's going on with the bots, and it's unclear whether
this is a valgrind bug or a libstd bug, but for now let's just get things
landing again.
Closes#30383
This commit is the result of the FCPs ending for the 1.8 release cycle for both
the libs and the lang suteams. The full list of changes are:
Stabilized
* `braced_empty_structs`
* `augmented_assignments`
* `str::encode_utf16` - renamed from `utf16_units`
* `str::EncodeUtf16` - renamed from `Utf16Units`
* `Ref::map`
* `RefMut::map`
* `ptr::drop_in_place`
* `time::Instant`
* `time::SystemTime`
* `{Instant,SystemTime}::now`
* `{Instant,SystemTime}::duration_since` - renamed from `duration_from_earlier`
* `{Instant,SystemTime}::elapsed`
* Various `Add`/`Sub` impls for `Time` and `SystemTime`
* `SystemTimeError`
* `SystemTimeError::duration`
* Various impls for `SystemTimeError`
* `UNIX_EPOCH`
* `ops::{Add,Sub,Mul,Div,Rem,BitAnd,BitOr,BitXor,Shl,Shr}Assign`
Deprecated
* Scoped TLS (the `scoped_thread_local!` macro)
* `Ref::filter_map`
* `RefMut::filter_map`
* `RwLockReadGuard::map`
* `RwLockWriteGuard::map`
* `Condvar::wait_timeout_with`
Closes#27714Closes#27715Closes#27746Closes#27748Closes#27908Closes#29866
For summary descriptions we need the first paragraph (adjacent lines
until a blank line) - but the rendered markdown of a code block did not
leave a blank line in the html and was thus included in the summary line.
Make sure formatter errors are emitted by the default Write::write_fmt
Previously, if an error was returned from the formatter that did not
originate in an underlying writer error, Write::write_fmt would return
successfully even if the formatting did not complete (was interrupted by
an `fmt::Error` return).
Now we choose to emit an io::Error with kind Other for formatter errors.
Since this may reveal error returns from `write!()` and similar that
previously passed silently, it's a kind of a [breaking-change].
Fixes#31879
suggest: Put the `use` in suggested code inside the quotes
Change import a trait suggestion from:
help: candidate #1: use `std::io::Write`
to
help: candidate #1: `use std::io::Write`
so that the code can be copied directly.
Fixes#31864
This fixes a bug (#31845) introduced in #31105 in which lexical scopes contain items from all anonymous module ancestors, even if the path to the anonymous module includes a normal module:
```rust
fn f() {
fn g() {}
mod foo {
fn h() {
g(); // This erroneously resolves on nightly
}
}
}
```
This is a [breaking-change] on nightly but not on stable or beta.
r? @nikomatsakis
Previously, if an error was returned from the formatter that did not
originate in an underlying writer error, Write::write_fmt would return
successfully even if the formatting did not complete (was interrupted by
an `fmt::Error` return).
Now we choose to emit an io::Error with kind Other for formatter errors.
Since this may reveal error returns from `write!()` and similar that
previously passed silently, it's a kind of a [breaking-change].
You can now group tests into directories like `run-pass/borrowck` or `compile-fail/borrowck`. By default, all `.rs` files within any directory are considered tests: to ignore some directory, create a placeholder file called `compiletest-ignore-dir` (I had to do this for several existing directories).
r? @alexcrichton
cc @brson
Change import a trait suggestion from:
help: candidate #1: use `std::io::Write`
to
help: candidate #1: `use std::io::Write`
so that the code can be copied directly.
This will correctly add the thread_local attribute to the external static variable ```errno```:
```rust
extern {
#[thread_local]
static errno: c_int;
}
```
Before this commit, the thread_local attribute is ignored. Fixes#30795.
Thanks @alexcrichton for pointing out the solution.
This PR changes the visibility of extern crate declarations to match that of items (fixes#26775).
To avoid breakage, the PR makes it a `public_in_private` lint to reexport a private extern crate, and it adds the lint `inaccessible_extern_crate` for uses of an inaccessible extern crate.
The lints can be avoided by making the appropriate `extern crate` declaration public.
Windows is not #[cfg(target_thread_local)] and as such should link
to the external symbol. But it fails with:
thread '<main>' panicked at 'assertion failed: `(left == right)` (left: `272246271`, right: `3`)', C:/bot/slave/auto-win-msvc-64-opt/build/src/test/run-pass/thread-local-extern-static.rs:24
Tracking issue: #31756
RFC: rust-lang/rfcs#1467
I've made these unstable for now. Should they be stabilized straight away since we've had plenty of experience with people using the unstable intrinsics?
This warning was introduced on Nov 28, 2015 and got into 1.6 stable, it was later requalified from a hardwired warning to a warn-by-default lint.
If this patch is landed soon enough, then `match_of_unit_variant_via_paren_dotdot` will get into 1.8 stable as a deny-by-default lint.
My intention is to turn it into a hard error after March 3, 2016, then it will hit stable at 1.9.
r? @nikomatsakis
cc @pnkfelix
Now that #31461 is merged, a failing resolution can never become indeterminate or succeed, so we no longer have to keep trying to resolve failing import directives.
r? @nrc
This commit adds functionality that allows the name resolution pass
to search for entities (traits/types/enums/structs) by name, in
order to show recommendations along with the errors.
For now, only E0405 and E0412 have suggestions attached, as per the
request in bug #21221, but it's likely other errors can also benefit
from the ability to generate suggestions.
In #31717 we rebased our LLVM fork over the 3.8 release branch, and it was
thought that this fixed#31702. The testing, however, must have been erroneous,
as it unfortunately didn't fix the issue! Our MUSL nightly builders are failing
from the same assertion reported in the issue, so we at least know the test case
is a reproduction!
I believe the failure is only happening on the MUSL nightly builders because
none of the auto builders have LLVM assertions enabled, and the Linux nightly
builder *does* have assertions enabled for the binaries we generate but the
distcheck run doesn't test a compiler with LLVM assertions enabled.
It's unclear to me whether this test failing under valgrind is actually legit.
The test only fails in valgrind when everything is dynamically linked, and it
appears to work when statically linked.
For now just add the `// no-prefer-dynamic` directive and let's just chalk it up
to a weird valgrind issue.
Closes#31328
