| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
When encountering a moved value of a type that isn't `Clone` because of unmet obligations, but where all the unmet predicates reference crate-local types, mention them and suggest cloning, as we do in other cases already:
```
error[E0507]: cannot move out of `foo`, a captured variable in an `Fn` closure
--> f111.rs:14:25
|
13 | fn do_stuff(foo: Option<Foo>) {
| --- captured outer variable
14 | require_fn_trait(|| async {
| -- ^^^^^ `foo` is moved here
| |
| captured by this `Fn` closure
15 | if foo.map_or(false, |f| f.foo()) {
| ---
| |
| variable moved due to use in coroutine
| move occurs because `foo` has type `Option<Foo>`, which does not implement the `Copy` trait
|
note: if `Foo` implemented `Clone`, you could clone the value
--> f111.rs:4:1
|
4 | struct Foo;
| ^^^^^^^^^^ consider implementing `Clone` for this type
...
15 | if foo.map_or(false, |f| f.foo()) {
| --- you could clone this value
```
|
|
|
|
|
|
|
|
|
|
Remove dead code and extend test coverage and diagnostics around it
I was staring a bit at the `dont_niche_optimize_enum` variable and figured out that part of it is dead code (at least today it is). I changed the diagnostic and test around the code that makes that part dead code, so everything that makes removing that code sound is visible in this PR
|
|
UI test suite clarity changes: Rename `tests/ui/SUMMARY.md` and update rustc dev guide on `error-pattern`
To match convention, rename `tests/ui/SUMMARY.md` to `tests/ui/README.md`.
Also, remove misleading lines in the rustc development guide about `error-pattern` being "not recommended", when it really is just a last resort which *should* be used in the niche situations where it is useful.
r? ````@jieyouxu````
|
|
Don't emit two `assume`s in transmutes when one is a subset of the other
For example, transmuting between `bool` and `Ordering` doesn't need two `assume`s because one range is a superset of the other.
Multiple are still used for things like `char` <-> `NonZero<u32>`, which overlap but where neither fully contains the other.
|
|
Tweak output for non-`Clone` values moved into closures
When we encounter a non-`Clone` value being moved into a closure, try to find the corresponding type of the binding being moved, if it is a `let`-binding or a function parameter. If any of those cases, we point at them with the note explaining that the type is not `Copy`, instead of giving that label to the place where it is captured. When it is a `let`-binding with no explicit type, we point at the initializer (if it fits in a single line).
```
error[E0507]: cannot move out of `foo`, a captured variable in an `Fn` closure
--> f111.rs:14:25
|
13 | fn do_stuff(foo: Option<Foo>) {
| --- ----------- move occurs because `foo` has type `Option<Foo>`, which does not implement the `Copy` trait
| |
| captured outer variable
14 | require_fn_trait(|| async {
| -- ^^^^^ `foo` is moved here
| |
| captured by this `Fn` closure
15 | if foo.map_or(false, |f| f.foo()) {
| --- variable moved due to use in coroutine
```
instead of
```
error[E0507]: cannot move out of `foo`, a captured variable in an `Fn` closure
--> f111.rs:14:25
|
13 | fn do_stuff(foo: Option<Foo>) {
| --- captured outer variable
14 | require_fn_trait(|| async {
| -- ^^^^^ `foo` is moved here
| |
| captured by this `Fn` closure
15 | if foo.map_or(false, |f| f.foo()) {
| ---
| |
| variable moved due to use in coroutine
| move occurs because `foo` has type `Option<Foo>`, which does not implement the `Copy` trait
```
|
|
Test fixes for Arm64EC Windows
* `tests/ui/cfg/conditional-compile-arch.rs` needs an Arm64EC case.
* `tests/ui/runtime/backtrace-debuginfo.rs` should skip Arm64EC as it suffers from the same truncated backtraces as Arm64 Windows.
* `tests/ui/linkage-attr/incompatible-flavor.rs` is a general issue: it assumes that the Rust compiler is always built with the x86 target enabled in the backend, but I only enabled AArch64 when building locally to speed up the LLVM compilation.
|
|
r=davidtwco
tests: Don't check for self-printed output in std-backtrace.rs test
The `Display` implementation for `Backtrace` used to print
stack backtrace:
but that print was since removed. See https://github.com/rust-lang/backtrace-rs/pull/286 and https://github.com/rust-lang/rust/pull/69042. To make the existing test pass, the print was added to the test instead. But it doesn't make sense to check for something that the test itself does since that will not detect any regressions in the implementation of `Backtrace`.
What the test _should_ check is that "stack backtrace:" is _not_ printed in `Display` of `Backtrace`. So do that instead.
This is one small steps towards resolving https://github.com/rust-lang/rust/issues/71706. The next steps after this step involves extending and hardening that test further.
|
|
Suggest clone in user-write-code instead of inside macro
Fixes rust-lang/rust#139253
Inspired by rust-lang/rust#142543
r? ````@fmease````
|
|
|
|
|
|
|
|
Since this test is limited to aarch64 and linux hosts, the --target
flag is entirely unnecessary and only breaks this on musl hosts. Let the
compiler use the default target instead.
Signed-off-by: Jens Reidel <adrian@travitia.xyz>
|
|
|
|
|
|
MIR-build: No longer emit assumes in enum-as casting
This just uses the `valid_range` from the backend, so it's duplicating the range metadata that now we include on parameters and loads, and thus no longer seems to be useful -- notably there's no codegen test failures from removing it.
(Because it's using data from the same source as the backend annotations, it doesn't do anything to mitigate things like rust-lang/rust#144388 where the range in the layout is more permissive than the actual possible discriminants. A variant of this that actually checked the discriminants more specifically might be useful, so could potentially be added in future, but I don't think the *current* checks are actually providing value.)
r? mir
Randomly turns out that this
Fixes https://github.com/rust-lang/rust/issues/121097
|
|
|
|
|
|
This just uses the `valid_range` from the backend, so it's duplicating the range metadata that now we include on parameters and loads.
|
|
|
|
collapsed links and reference links have a pretty particular syntax,
it seems unlikely they would show up on accident.
Co-authored-by: León Orell Valerian Liehr <me@fmease.dev>
|
|
|
|
|
|
rustdoc will not try to do intra-doc linking if the "path"
of a link looks too much like a "real url".
however, only inline links ([text](url)) can actually contain
a url, other types of links (reference links, shortcut links)
contain a *reference* which is later resolved to an actual url.
the "path" in this case cannot be a url, and therefore it should
not be skipped due to looking like a url.
Co-authored-by: Michael Howell <michael@notriddle.com>
|
|
|
|
Stop using the old `validate_attr` logic for stability attributes
I think this was accidentally missed when implementing the stability attributes?
r? `````@oli-obk`````
cc `````@jdonszelmann`````
|
|
Don't suggest assoc ty bound on non-angle-bracketed problematic assoc ty binding
Fixes https://github.com/rust-lang/rust/issues/140543.
|
|
Use less HIR in check_private_in_public.
r? ````````@petrochenkov````````
|
|
yuk1ty:false-sealed-traits-note-reported-in-another-issue, r=fee1-dead
Add more test case to check if the false note related to sealed trait suppressed
Closes rust-lang/rust#143121
I started to fix the issue but I found that this one has already been addressed in this PR (https://github.com/rust-lang/rust/pull/143431). I added an additional test to prove the reported thing has been resolved just in case.
I think we can discard this pull request if there's no need to add such kind of tests👍🏻
|
|
generate elf symbol version in raw-dylib
For link names like `aaa@bbb`, it generates a symbol named `aaa` and a version named `bbb`.
For link names like `aaa\0bbb`, `aaa@`@bbb`` or `aa@bb@cc`, it emits errors.
It adds a test that the executable is linked with glibc using raw-dylib.
cc rust-lang/rust#135694
|
|
Use serde for target spec json deserialize
The previous manual parsing of `serde_json::Value` was a lot of complicated code and extremely error-prone. It was full of janky behavior like sometimes ignoring type errors, sometimes erroring for type errors, sometimes warning for type errors, and sometimes just ICEing for type errors (the icing on the top).
Additionally, many of the error messages about allowed values were out of date because they were in a completely different place than the FromStr impls. Overall, the system caused confusion for users.
I also found the old deserialization code annoying to read. Whenever a `key!` invocation was found, one had to first look for the right macro arm, and no go to definition could help.
This PR replaces all this manual parsing with a 2-step process involving serde.
First, the string is parsed into a `TargetSpecJson` struct. This struct is a 1:1 representation of the spec JSON. It already parses all the enums and is very simple to read and write.
Then, the fields from this struct are copied into the actual `Target`. The reason for this two-step process instead of just serializing into a `Target` is because of a few reasons
1. There are a few transformations performed between the two formats
2. The default logic is implemented this way. Otherwise all the default field values would have to be spelled out again, which is suboptimal. With this logic, they fall out naturally, because everything in the json struct is an `Option`.
Overall, the mapping is pretty simple, with the vast majority of fields just doing a 1:1 mapping that is captured by two macros. I have deliberately avoided making the macros generic to keep them simple.
All the `FromStr` impls now have the error message right inside them, which increases the chance of it being up to date. Some "`from_str`" impls were turned into proper `FromStr` impls to support this.
The new code is much less involved, delegating all the JSON parsing logic to serde, without any manual type matching.
This change introduces a few breaking changes for consumers. While it is possible to use this format on stable, it is very much subject to change, so breaking changes are expected. The hope is also that because of the way stricter behavior, breaking changes are easier to deal with, as they come with clearer error messages.
1. Invalid types now always error, everywhere. Previously, they would sometimes error, and sometimes just be ignored (which meant the users JSON was still broken, just silently!)
2. This now makes use of `deny_unknown_fields` instead of just warning on unused fields, which was done previously. Serde doesn't make it easy to get such warning behavior, which was the primary reason that this now changed. But I think error behavior is very reasonable too. If someone has random stale fields in their JSON, it is likely because these fields did something at some point but no longer do, and the user likely wants to be informed of this so they can figure out what to do.
This is also relevant for the future. If we remove a field but someone has it set, it probably makes sense for them to take a look whether they need this and should look for alternatives, or whether they can just delete it. Overall, the JSON is made more explicit.
This is the only expected breakage, but there could also be small breakage from small mistakes. All targets roundtrip though, so it can't be anything too major.
fixes rust-lang/rust#144153
|
|
Ensure we codegen the main fn
This fixes two bugs. The one that was identified in the linked issue is that when we have a `main` function, mono collection didn't consider it as an extra collection root.
The other is that since CGU partitioning doesn't know about the call edges between the entrypoint functions, naively it can put them in different CGUs and mark them all as internal. Which would result in LLVM just deleting all of them. There was an existing hack to exclude `lang = "start"` from internalization, which I've extended to include `main`.
Fixes https://github.com/rust-lang/rust/issues/144052
|
|
don't link to the nightly version of the Edition Guide in stable lints
As reported in rust-lang/rust#143557 for `rust_2024_incompatible_pat`, most future-Edition-incompatibility lints link to the nightly version of the Edition Guide; the lints were written before their respective Editions (and their guides) stabilized. But now that Rusts 2021 and 2024 are stable, these lints are emitted on stable versions of the compiler, where it makes more sense to present users with links that don't say "nightly" in them.
This does not change the link for `rust_2024_incompatible_pat`. That's handled in rust-lang/rust#144006.
|
|
|
|
|
|
We lost the following comment during refactorings:
The current code for niche-filling relies on variant indices instead of actual discriminants, so enums with explicit discriminants (RFC 2363) would misbehave.
|
|
|
|
|
|
Consider parent predicates in ImpossiblePredicates pass.
This pass is double edged. It avoids some ICEs (yay!) but also degrades diagnostics from constant evaluation.
Fixes rust-lang/rust#121363
Fixes rust-lang/rust#131507
Fixes rust-lang/rust#140100
Fixes rust-lang/rust#140365
|
|
Given
```rust
fn main() {
let maybe_vec = Some(vec![1,2,3]);
assert_eq!(maybe_vec.len(), 3);
}
```
suggest unwraping `maybe_vec` to call `.len()` on the `Vec<_>`.
```
error[E0624]: method `len` is private
--> $DIR/enum-method-probe.rs:61:9
|
LL | res.len();
| ^^^ private method
--> $SRC_DIR/core/src/option.rs:LL:COL
|
= note: private method defined here
|
note: the method `len` exists on the type `Vec<{integer}>`
--> $SRC_DIR/alloc/src/vec/mod.rs:LL:COL
help: consider using `Option::expect` to unwrap the `Vec<{integer}>` value, panicking if the value is an `Option::None`
|
LL | res.expect("REASON").len();
| +++++++++++++++++
```
|
|
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#144173 (Remove tidy checks for `tests/ui/issues/`)
- rust-lang/rust#144234 (Fix broken TLS destructors on 32-bit win7)
- rust-lang/rust#144239 (Clean `rustc/parse/src/lexer` to improve maintainability)
- rust-lang/rust#144256 (Don't ICE on non-TypeId metadata within TypeId)
- rust-lang/rust#144290 (update tests/ui/SUMMARY.md)
- rust-lang/rust#144292 (mbe: Use concrete type for `get_unused_rule`)
- rust-lang/rust#144298 (coverage: Enlarge empty spans during MIR instrumentation, not codegen)
- rust-lang/rust#144311 (Add powerpc64le-unknown-linux-musl to CI rustc targets)
- rust-lang/rust#144315 (bootstrap: add package.json and package-lock.json to dist tarball)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
For example, transmuting between `bool` and `Ordering` doesn't need two `assume`s because one range is a superset of the other.
Multiple are still used for things like `char` <-> `NonZero<u32>`, which overlap but where neither fully contains the other.
|
|
This is already warn-by-default, and a future compatibility warning
(FCW) that warns in dependencies. Upgrade it to deny-by-default, as the
next step towards hard error.
|
|
|
