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
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
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.
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.
Remove alternate stack with sigaltstack before unmaping it.
Also reuse existing signal stack if already set, this is especially
useful when working with sanitizers that configure alternate stack
themselves.
This change depends on SS_DISABLE recently introduced in libc crate and updates
this git submodule accordingly.
