enable Atomic*.{load,store} for ARMv6-M / MSP430
closes#45085
as proposed in https://github.com/rust-lang/rust/issues/45085#issuecomment-384825434
this commit adds an `atomic_cas` target option and extends the `#[cfg(target_has_atomic)]`
attribute to enable a subset of the `Atomic*` API on architectures that don't support atomic CAS
natively, like MSP430 and ARMv6-M.
r? @alexcrichton
Rollup of 14 pull requests
Successful merges:
- #51619 (rust: add initial changes to support powerpc64le musl)
- #51793 (Fix variant background color on hover in search results)
- #52005 (Update LLVM to bring in a wasm codegen fix)
- #52016 (Deduplicate error reports for statics)
- #52019 ([cross-lang-lto] Allow the linker to choose the LTO-plugin (which is useful when using LLD))
- #52030 (Any docs preposition change)
- #52031 (Strenghten synchronization in `Arc::is_unique`)
- #52033 ([Gardening] Update outdated comments: ByVal -> Scalar)
- #52055 (Include VS 2017 in error message.)
- #52063 (Add a link to the rustc docs)
- #52073 (Add a punch card to weird expressions test)
- #52080 (Improve dependency deduplication diagnostics)
- #52093 (rustc: Update tracking issue for wasm_import_module)
- #52096 (Fix typo in cell.rs)
Failed merges:
[Gardening] Update outdated comments: ByVal -> Scalar
ByVal enum cases in mir::interpret::value were renamed to Scalar a while ago but comments still refer to the old names.
Strenghten synchronization in `Arc::is_unique`
Previously, `is_unique` would not synchronize at all with a `drop` that returned
early because it was not the last reference, leading to a data race.
Fixes#51780
Unfortunately I have no idea how to add a test for this.
Cc @jhjourdan
Any docs preposition change
This changes the docs referring to where a user should be wary of depending on "Any" trait impls from warning about relying on them "outside" of their code to warning about relying on them "inside" of their code.
[cross-lang-lto] Allow the linker to choose the LTO-plugin (which is useful when using LLD)
This PR allows for not specifying an LTO-linker plugin but still let `rustc` invoke the linker with the correct plugin arguments. This is useful when using LLD which does not need the `-plugin` argument. Since LLD is the best linker for this scenario anyway, this change should improve ergonomics quite a bit.
r? @alexcrichton
closes#45085
this commit adds an `atomic_cas` target option and an unstable `#[cfg(target_has_atomic_cas)]`
attribute to enable a subset of the `Atomic*` API on architectures that don't support atomic CAS
natively, like MSP430 and ARMv6-M.
Fix various issues with control-flow statements inside anonymous constants
Fixes#51761.
Fixes#51963 (and the host of other reported issues there).
(Might be easiest to review per commit, as they should be standalone.)
r? @estebank
rename rustc's lld to rust-lld
to not shadow the system installed LLD when linking with LLD.
Before:
- `-C linker=lld -Z linker-flavor=ld.lld` uses rustc's LLD
- It's not possible to use a system installed LLD that's named `lld`
With this commit:
- `-C linker=rust-lld -Z linker-flavor=ld.lld` uses rustc's LLD
- `-C linker=lld -Z linker-flavor=ld.lld` uses the system installed LLD
we don't offer guarantees about the availability of LLD in the rustc sysroot so we can rename the tool as long as we don't break the wasm32-unknown-unknown target which depends on it.
r? @alexcrichton we discussed this before
in which we plug the crack where `?`-desugaring leaked into errors
Most of the time, it's not a problem that the types of the arm bodies in
a desugared-from-`?` match are different (that is, specifically: in `x?`
where x is a `Result<A, B>`, the `Ok` arm body is an `A`, whereas the
`Err` arm diverges to return a `Result<A, B>`), because they're being
assigned to different places. But in tail position, the types do need to
match, and our error message was explicitly referring to "match arms",
which is confusing when there's no `match` in the sweetly sugared
source.
It is not without some misgivings that we pollute the clarity-of-purpose
of `note_error_origin` with the suggestion to wrap with `Ok` (the other
branches are pointing out the odd-arm-out in the HIR that is the origin
of the error; the new branch that issues the `Ok` suggestion is serving
a different purpose), but it's the natural place to do it given that
we're already matching on `ObligationCauseCode::MatchExpressionArm {
arm_span, source }` there.
Resolves#51632.
[NLL] Fix various unused mut errors
Closes#51801Closes#50897Closes#51830Closes#51904
cc #51918 - keeping this one open in case there are any more issues
This PR contains multiple changes. List of changes with examples of what they fix:
* Change mir generation so that the parameter variable doesn't get a name when a `ref` pattern is used as an argument
```rust
fn f(ref y: i32) {} // doesn't trigger lint
```
* Change mir generation so that by-move closure captures don't get first moved into a temporary.
```rust
let mut x = 0; // doesn't trigger lint
move || {
x = 1;
};
```
* Treat generator upvars the same as closure upvars
```rust
let mut x = 0; // This mut is now necessary and is not linted against.
move || {
x = 1;
yield;
};
```
r? @nikomatsakis
rustdoc codeblock hash escape
So that docstring text such as the following (in a code block) can be created ergonomically:
```rust
let s = "
foo
# bar
baz
";
```
Such code in a docstring hide the <code> # bar</code> line.
Previously, using two consecutive hashes <code> ## bar</code> would turn the line into _shown_ `# bar`, losing the leading whitespace. A line of code like <code> # bar</code> (such as in the example above) **could not be represented** in the docstring text.
This commit makes the two consecutive hashes not also trim the leading whitespace — the two hashes simply **escape** into a single hash and do not hide the line, leaving the rest of that line unaffected. The new docstring text to achieve the above code block is:
```rust
/// ```
/// let s = "
/// foo
/// ## bar
/// baz
/// ";
/// ```
```
rustdoc: import cross-crate macros alongside everything else
The thrilling conclusion of the cross-crate macro saga in rustdoc! After https://github.com/rust-lang/rust/pull/51425 made sure we saw all the namespaces of an import (and prevented us from losing the `vec!` macro in std's documentation), here is the PR to handle cross-crate macro re-exports at the same time as everything else. This way, attributes like `#[doc(hidden)]` and `#[doc(no_inline)]` can be used to control how the documentation for these macros is seen, rather than rustdoc inlining every macro every time.
Fixes https://github.com/rust-lang/rust/issues/50647
Reuse the `DefsUsesVisitor` in `simulate_block()`.
This avoids a bunch of allocations for the bitsets within it,
speeding up a number of NLL benchmarks, the best by 1%.
r? @nikomatsakis
Unpin references
I also considered adding an impl for raw pointers as well, but that makes it easy to accidentally have unsound owning-collections that might otherwise be able to project pinned-ness (e.g. `Box`).
cc @RalfJung
r? @withoutboats
Move self trait predicate to items
This is a "reimagination" of @tmandry's PR #50183. The main effect is described in this comment from one of the commits:
---
Before we had the following results for `predicates_of`:
```rust
trait Foo { // predicates_of: Self: Foo
fn bar(); // predicates_of: Self: Foo (inherited from trait)
}
```
Now we have removed the `Self: Foo` from the trait. However, we still
add it to the trait ITEM. This is because when people do things like
`<T as Foo>::bar()`, they still need to prove that `T: Foo`, and
having it in the `predicates_of` seems to be the cleanest way to
ensure that happens right now (otherwise, we'd need special case code
in various places):
```rust
trait Foo { // predicates_of: []
fn bar(); // predicates_of: Self: Foo
}
```
However, we sometimes want to get the list of *just* the predicates
truly defined on a trait item (e.g., for chalk, but also for a few
other bits of code). For that, we define `predicates_defined_on`,
which does not contain the `Self: Foo` predicate yet, and we plumb
that through metadata and so forth.
---
I'm assigning @eddyb as the main reviewer, but I thought I might delegate to scalexm for this one in any case. I also want to post an alternative that I'll leave in the comments; it occurred to me as I was writing. =)
r? @eddyb
cc @scalexm @tmandry @leodasvacas
This commit updates the stage0 build of tools to use the libraries of the stage0
compiler instead of the compiled libraries by the stage0 compiler. This should
enable us to avoid any stage0 hacks (like missing SIMD).
