The new git submodule src/llvm-project is a monorepo replacing src/llvm
and src/tools/{clang,lld,lldb}. This also serves as a rebase for these
projects to the new 8.x branch from trunk.
The src/llvm-emscripten fork is unchanged for now.
Rollup of 5 pull requests
Successful merges:
- #56233 (Miri and miri-related code contains repetitions of `(n << amt) >> amt`)
- #57645 (distinguish "no data" from "heterogeneous" in ABI)
- #57734 (Fix evaluating trivial drop glue in constants)
- #57886 (Add suggestion for moving type declaration before associated type bindings in generic arguments.)
- #57890 (Fix wording in diagnostics page)
Failed merges:
r? @ghost
Update Cargo.lock to use the latest `compiler_builtins`
A very tiny PR per the request of @alexcrichton : rust-lang-nursery/compiler-builtins#267 (comment)
Rewrite of #57414
cc @Lokathor
r? @alexcrichton
This commit stabilizes the `Atomic{I,U}{8,16,32,64}` APIs in the
`std::sync::atomic` and `core::sync::atomic` modules. Proposed in #56753
and tracked in #32976 this feature has been unstable for quite some time
and is hopefully ready to go over the finish line now!
The API is being stabilized as-is. The API of `AtomicU8` and friends
mirrors that of `AtomicUsize`. A list of changes made here are:
* A portability documentation section has been added to describe the
current state of affairs.
* Emulation of smaller-size atomics with larger-size atomics has been
documented.
* As an added bonus, `ATOMIC_*_INIT` is now scheduled for deprecation
across the board in 1.34.0 now that `const` functions can be invoked
in statics.
Note that the 128-bit atomic types are omitted from this stabilization
explicitly. They have far less platform support than the other atomic
types, and will likely require further discussion about their best
location.
Closes#32976Closes#56753
Fix evaluating trivial drop glue in constants
```rust
struct A;
impl Drop for A {
fn drop(&mut self) {}
}
const FOO: Option<A> = None;
const BAR: () = (FOO, ()).1;
```
was erroring with
```
error: any use of this value will cause an error
--> src/lib.rs:9:1
|
9 | const BAR: () = (FOO, ()).1;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^-^
| |
| calling non-const function `std::ptr::real_drop_in_place::<(std::option::Option<A>, ())> - shim(Some((std::option::Option<A>, ())))`
|
= note: #[deny(const_err)] on by default
error: aborting due to previous error
```
before this PR. According to godbolt this last compiled successfully in 1.27
distinguish "no data" from "heterogeneous" in ABI
Ignore zero-sized types when computing whether something is a homogeneous aggregate, except be careful of VLA.
cc #56877
r? @arielb1
cc @eddyb
Miri and miri-related code contains repetitions of `(n << amt) >> amt`
I reduced some code repetitions contains `(n << amt) >> amt`.
This pull request is related to #49937.
[NLL] Clean up handling of type annotations
* Renames (Canonical)?UserTypeAnnotation -> (Canonical)?UserType so that the name CanonicalUserTypeAnnotation is free.
* Keep the inferred type associated to user type annotations in the MIR, so that it can be compared against the annotated type, even when the annotated expression gets removed from the MIR. (#54943)
* Use the inferred type to allow infallible handling of user type projections (#57531)
* Uses revisions for the tests in #56993
* Check the types of `Unevaluated` constants with no annotations (#46702)
* Some drive-by cleanup
Closes#46702Closes#54943Closes#57531Closes#57731
cc #56993 leaving this open to track the underlying issue: we are not running tests with full NLL enabled on CI at the moment
r? @nikomatsakis
bootstrap: Don't rely on any default settings regarding incr. comp. in Cargo
https://github.com/rust-lang/cargo/pull/6564 (temporarily) makes incremental compilation the default for release builds. We don't want this default to apply to building the compiler itself, that is, `bootstrap`'s `incremental` flag should always be respected. Otherwise we'll get incrementally build releases, which we really don't want `:)`.
r? @Mark-Simulacrum
Anybody else from @rust-lang/release should feel free to r+ this too if they get around to it earlier.
This commit extends existing suggestions to move lifetimes before types
in generic arguments to also suggest moving types behind associated type
bindings.
submodules: update clippy from 280069dd to f1753522
Changes:
````
Rustup
allow assertions_on_constants for collapsible_if and missing_test_files
Improving comments.
Added rustfix to the test.
Improve span shortening.
Added "make_return" and "blockify" convenience methods in Sugg and used them in "needless_bool".
Fixed potential mistakes with nesting. Added tests.
Fix automatic suggestion on `use_self`.
run ./util/dev update_lints
add assert(true/false, some message) tests
change assert_checks to assertions_on_constants
run ./util/dev update_lints
Add unreachable!() as option
Add assert(true) and assert(false) lints
````
Fixes clippy toolstate
r? @oli-obk
Rollup of 5 pull requests
Successful merges:
- #56217 (Add grammar in docs for {f32,f64}::from_str, mention known bug.)
- #57294 (When using value after move, point at span of local)
- #57652 (Update/remove some old readmes)
- #57802 (Print visible name for types as well as modules.)
- #57865 (Don't ICE when logging unusual types)
Failed merges:
r? @ghost
Don't ICE when logging unusual types
MonoItemExt#to_string is used for both debug logging and LLVM symbol
name generation. When debugging, we want to print out any type we
encounter, even if it's something weird like GeneratorWitness. However,
during codegen, we still want to error if we encounter an unexpected
type when generating a name.
To resolve this issue, this commit introduces a new 'debug' parameter to
the relevant methods. When set to 'true', it allows any type to be
printed - when set to 'false', it 'bug!'s when encountering an
unexpected type.
This prevents an ICE when enabling debug logging (via RUST_LOG) while
running rustc on generator-related code.
Print visible name for types as well as modules.
Fixes#56943 and fixes#57713.
This commit extends previous work in #55007 where the name from the
visible parent was used for modules. Now, we also print the name from
the visible parent for types.
r? @estebank
When using value after move, point at span of local
When trying to use a value after move, instead of using a note, point
at the local declaration that has a type that doesn't implement `Copy`
trait.
```
error[E0382]: use of moved value: `x`
--> $DIR/issue-34721.rs:27:9
|
LL | pub fn baz<T: Foo>(x: T) -> T {
| - - move occurs because `x` has type `T`, which does not implement the `Copy` trait
| |
| consider adding a `Copy` constraint to this type argument
LL | if 0 == 1 {
LL | bar::bar(x.zero())
| - value moved here
LL | } else {
LL | x.zero()
| - value moved here
LL | };
LL | x.zero()
| ^ value used here after move
```
Fix#34721.
Changes:
````
Rustup
allow assertions_on_constants for collapsible_if and missing_test_files
Improving comments.
Added rustfix to the test.
Improve span shortening.
Added "make_return" and "blockify" convenience methods in Sugg and used them in "needless_bool".
Fixed potential mistakes with nesting. Added tests.
Fix automatic suggestion on `use_self`.
run ./util/dev update_lints
add assert(true/false, some message) tests
change assert_checks to assertions_on_constants
run ./util/dev update_lints
Add unreachable!() as option
Add assert(true) and assert(false) lints
````
Stabilize no_panic_pow
This would close#48320.
I'm not sure if I've done this right, I've just changed attribute name to stable and set `since` to two minor versions above current stable since that seemed like what others were doing.
Add suggestion for incorrect field syntax.
Fixes#57684.
This commit adds a suggestion when a `=` character is used when
specifying the value of a field in a struct constructor incorrectly
instead of a `:` character.
r? @estebank
