make matching on NaN a hard error, and remove the rest of illegal_floating_point_literal_pattern
These arms would never be hit anyway, so the pattern makes little sense. We have had a future-compat lint against float matches in general for a *long* time, so I hope we can get away with immediately making this a hard error.
This is part of implementing https://github.com/rust-lang/rfcs/pull/3535.
Closes https://github.com/rust-lang/rust/issues/41620 by removing the lint.
https://github.com/rust-lang/reference/pull/1456 updates the reference to match.
The Rust LoongArch targets have been using the default LLVM code model
so far, which is "small" in LLVM-speak and "normal" in LoongArch-speak.
As described in the "Code Model" section of LoongArch ELF psABI spec
v20231219 [1], one can only make function calls as far as ±128MiB with
the "normal" code model; this is insufficient for very large software
containing Rust components that needs to be linked into the big text
section, such as Chromium.
Because:
* we do not want to ask users to recompile std if they are to build
such software,
* objects compiled with larger code models can be linked with those
with smaller code models without problems, and
* the "medium" code model is comparable to the "small"/"normal" one
performance-wise (same data access pattern; each function call
becomes 2-insn long and indirect, but this may be relaxed back into
the direct 1-insn form in a future LLVM version), but is able to
perform function calls within ±128GiB,
it is better to just switch the targets to the "medium" code model,
which is also "medium" in LLVM-speak.
[1]: https://github.com/loongson/la-abi-specs/blob/v2.30/laelf.adoc#code-models
coverage: Improve handling of function/closure spans
This is a combination of some loosely-related changes that touch the same code:
1. Make unexpansion of closure bodies more precise, by unexpanding back to the context of the closure declaration, instead of unexpanding all the way back to the top-level context. This preserves the way we handle async desugaring and closures containing a single bang-macro, while also giving better results for closures defined in macros.
2. Skip the normal span-refinement code when dealing with the trivial outer part of an async function.
3. Be more explicit about the fact that `fn_sig_span` has been extended to the start of the function body, and is not necessarily present.
---
`@rustbot` label +A-code-coverage
Move predicate, region, and const stuff into their own modules in middle
This PR mostly moves things around, and in a few cases adds some `ty::` to the beginning of names to avoid one-off imports.
I don't mean this to be the most *thorough* move/refactor. I just generally wanted to begin to split up `ty/mod.rs` and `ty/sty.rs` which are huge and hard to distinguish, and have a lot of non-ty stuff in them.
r? lcnr
This sidesteps the normal span refinement code in cases where we know that we
are only dealing with the special signature span that represents having called
an async function.
The two kinds of delayed bug have quite different semantics so a
stronger conceptual separation is nice. (`is_error` is a good example,
because the two kinds have different behaviour.)
The commit also moves the `DelayedBug` variant after `Error` in `Level`,
to reflect the fact that it's weaker than `Error` -- it might trigger an
error but also might not. (The pre-existing `downgrade_to_delayed_bug`
function also reflects the notion that delayed bugs are lower/after
normal errors.)
Plus it condenses some of the comments on `Level` into a table, for
easier reading, and introduces `can_be_top_or_sub` to indicate which
levels can be used in top-level diagnostics vs. subdiagnostics.
Finally, it renames `DiagCtxtInner::span_delayed_bugs` as
`DiagCtxtInner::delayed_bugs`. The `span_` prefix is unnecessary because
some delayed bugs don't have a span.
- Combine two different blocks involving
`diagnostic.level.get_expectation_id()` into one.
- Combine several `if`s involving `diagnostic.level` into a single
`match`.
This requires reordering some of the operations, but this has no
functional effect.
Rollup of 8 pull requests
Successful merges:
- #119759 (Add FileCheck annotations to dataflow-const-prop tests)
- #120323 (On E0277 be clearer about implicit `Sized` bounds on type params and assoc types)
- #120473 (Only suggest removal of `as_*` and `to_` conversion methods on E0308)
- #120540 (add test for try-block-in-match-arm)
- #120547 (`#![feature(inline_const_pat)]` is no longer incomplete)
- #120552 (Correctly check `never_type` feature gating)
- #120555 (put pnkfelix (me) back on the review queue.)
- #120556 (Improve the diagnostics for unused generic parameters)
r? `@ghost`
`@rustbot` modify labels: rollup
It doesn't affect behaviour, but makes sense with (a) `FailureNote` having
`()` as its emission guarantee, and (b) in `Level` the `is_error` levels
now are all listed before the non-`is_error` levels.
Rollup of 8 pull requests
Successful merges:
- #120484 (Avoid ICE when is_val_statically_known is not of a supported type)
- #120516 (pattern_analysis: cleanup manual impls)
- #120517 (never patterns: It is correct to lower `!` to `_`.)
- #120523 (Improve `io::Read::read_buf_exact` error case)
- #120528 (Store SHOULD_CAPTURE as AtomicU8)
- #120529 (Update data layouts in custom target tests for LLVM 18)
- #120531 (Remove a bunch of `has_errors` checks that have no meaningful or the wrong effect)
- #120533 (Correct paths for hexagon-unknown-none-elf platform doc)
r? `@ghost`
`@rustbot` modify labels: rollup
Improve the diagnostics for unused generic parameters
* Don't emit two errors (namely E0091 *and* E0392) for unused type parameters on *lazy* type aliases
* Fix the diagnostic help message of E0392 for *lazy* type aliases: Don't talk about the “fields” of lazy type aliases (use the term “body” instead) and don't suggest `PhantomData` for them, it doesn't make much sense
* Consolidate the diagnostics for E0091 (unused type parameters in type aliases) and E0392 (unused generic parameters due to bivariance) and make it translatable
* Still keep the error codes distinct (for now)
* Naturally leads to better diagnostics for E0091
r? ```@oli-obk``` (to ballast your review load :P) or compiler
Correctly check `never_type` feature gating
Fixes#120542.
The feature wasn't tested on return type of a generic function type, so it got under the radar in https://github.com/rust-lang/rust/pull/120316.
r? ```@compiler-errors```
`#![feature(inline_const_pat)]` is no longer incomplete
Now that borrow checking and safety checking is implemented for inline constant patterns, the incomplete feature status is not necessary. Stabilizing this feature requires more testing and has some of the same unresolved questions as inline constants.
cc #76001
never patterns: It is correct to lower `!` to `_`.
This is just a comment update but a non-trivial one: it is correct to lower `!` patterns as `_`. The reasoning is that `!` matches all the possible values of the type, since the type is empty. Moreover, we do want to warn that the `Err` is redundant in:
```rust
match x {
!,
Err(!),
}
```
which is consistent with `!` behaving like a wildcard.
I did try to introduce `Constructor::Never` and it ended up needing to behave exactly like `Constructor::Wildcard`.
r? ```@compiler-errors```
Avoid ICE when is_val_statically_known is not of a supported type
2 ICE with 1 stone!
1. Implement `llvm.is.constant.ptr` to avoid first ICE in linked issue.
2. return `false` when the argument is not one of `i*`/`f*`/`ptr` to avoid second ICE.
fixes#120480
hir: Remove the generic type parameter from `MaybeOwned`
It's only ever used with a reference to `OwnerInfo` as an argument.
Follow up to https://github.com/rust-lang/rust/pull/120346.
Remove `BorrowckErrors::tainted_by_errors`
This PR removes one of the `tainted_by_errors` occurrences, replacing it with direct use of `ErrorGuaranteed`.
r? `@oli-obk`
Suggest changing type to const parameters if we encounter a type in the trait bound position
The first commit is just drive-by cleanup.
Provide a structured suggestion if the user forgot to prefix a “const parameter” with `const`, e.g., in `struct Tagged<TAG: u64>;`. This happens to me from time to time. Maybe C++ devs are also prone to this mistake given template syntax looks like `template<typename T, uint32_t N>`.
`emit_future_breakage` calls
`self.dcx().take_future_breakage_diagnostics()` and then passes the
result to `self.dcx().emit_future_breakage_report(diags)`. This commit
removes the first of these and lets `emit_future_breakage_report` do the
taking.
It also inlines and removes what is left of `emit_future_breakage`,
which has a single call site.
- `emitted_at` isn't used outside the crate.
- `code` and `messages` are public fields, so there's no point have
trivial getters/setters for them.
- `suggestions` is public, so the comment about "functionality on
`Diagnostic`" isn't needed.
`BorrowckErrors` stores a mix of error and non-error diags in
`buffered`. As a result, it downgrades `DiagnosticBuilder`s to
`Diagnostic`s, losing the emission guarantees, and so has to use a
`tainted_by_errors` field to record whether an error has occurred.
This commit splits `buffered` into `buffered_errors` and
`buffered_non_errors`, keeping them as `DiagnosticBuilder`s and
preserving the emission guarantees.
This also requires fixing a bunch of incorrect lifetimes on
`DiagnosticBuilder` use points.
* Get rid of a typo in a function name
* Rename `currently_processing_generics`: The old name confused me at first since
I assumed it referred to generic *parameters* when it was in fact referring to
generic *arguments*. Generics are typically short for generic params.
* Get rid of a few unwraps by properly leveraging slice patterns
When there are two possibilities, both of which use a `String`, it's
nicer to use a struct than an enum. Especially when mapping the contents
into a tuple.
It contains an `i128`, but when creating them we convert any number
outside the range -100..100 to a string, because Fluent uses an `f64`.
It's all a bit strange.
This commit changes the `i128` to an `i32`, which fits safely in
Fluent's `f64`, and removes the -100..100 range check. This means that
only integers outside the range of `i32` will be converted to strings.
```
error[E0277]: the size for values of type `[i32]` cannot be known at compilation time
--> f100.rs:2:33
|
2 | let _ = std::mem::size_of::<[i32]>();
| ^^^^^ doesn't have a size known at compile-time
|
= help: the trait `Sized` is not implemented for `[i32]`
note: required by an implicit `Sized` bound in `std::mem::size_of`
--> /home/gh-estebank/rust/library/core/src/mem/mod.rs:312:22
|
312 | pub const fn size_of<T>() -> usize {
| ^ required by the implicit `Sized` requirement on this bound in `size_of`
```
Fix#120178.
Since the only use of `TypeCx::bug` is in `Constructor::is_covered_by`,
it is tempting to return `false` instead of `Err()`, but that would
cause "non-exhaustive match" false positives.
Don't hash lints differently to non-lints.
`Diagnostic::keys`, which is used for hashing and equating diagnostics, has a surprising behaviour: it ignores children, but only for lints. This was added in #88493 to fix some duplicated diagnostics, but it doesn't seem necessary any more.
This commit removes the special case and only four tests have changed output, with additional errors. And those additional errors aren't exact duplicates, they're just similar. For example, in src/tools/clippy/tests/ui/same_name_method.rs we currently have this error:
```
error: method's name is the same as an existing method in a trait
--> $DIR/same_name_method.rs:75:13
|
LL | fn foo() {}
| ^^^^^^^^^^^
|
note: existing `foo` defined here
--> $DIR/same_name_method.rs:79:9
|
LL | impl T1 for S {}
| ^^^^^^^^^^^^^^^^
```
and with this change we also get this error:
```
error: method's name is the same as an existing method in a trait
--> $DIR/same_name_method.rs:75:13
|
LL | fn foo() {}
| ^^^^^^^^^^^
|
note: existing `foo` defined here
--> $DIR/same_name_method.rs:81:9
|
LL | impl T2 for S {}
|
```
I think printing this second argument is reasonable, possibly even preferable to hiding it. And the other cases are similar.
r? `@estebank`
Provide more context on derived obligation error primary label
Expand the primary span of E0277 when the immediate unmet bound is not what the user wrote:
```
error[E0277]: the trait bound `i32: Bar` is not satisfied
--> f100.rs:6:6
|
6 | <i32 as Foo>::foo();
| ^^^ the trait `Bar` is not implemented for `i32`, which is required by `i32: Foo`
|
help: this trait has no implementations, consider adding one
--> f100.rs:2:1
|
2 | trait Bar {}
| ^^^^^^^^^
note: required for `i32` to implement `Foo`
--> f100.rs:3:14
|
3 | impl<T: Bar> Foo for T {}
| --- ^^^ ^
| |
| unsatisfied trait bound introduced here
```
Fix#40120.
pattern_analysis: cleanup the contexts
This cleans up a bit the various `*Ctxt`s I had left lying around. As a bonus this made it possible to make `PatternColumn` public. I don't have a use for that yet but that could come useful.
`UsefulnessCtxt` looks useless right now but I'll be adding a field or two in subsequent PRs.
r? `````@compiler-errors`````
Further improve `space_between`
`space_between` is used by `print_tts` to decide when spaces should be put between tokens. This PR improves it in two ways:
- avoid unnecessary spaces before semicolons, and
- don't omit some necessary spaces before/after some punctuation symbols.
r? `@petrochenkov`
Disable packed/unpacked options for riscv linux/android.
Other riscv targets already only have the off option.
The packed/unpacked options might be supported in the future.
See upstream issue for more details:
https://github.com/llvm/llvm-project/issues/56642Fixes#110224
Expand the primary span of E0277 when the immediate unmet bound is not what the user wrote:
```
error[E0277]: the trait bound `i32: Bar` is not satisfied
--> f100.rs:6:6
|
6 | <i32 as Foo>::foo();
| ^^^ the trait `Bar` is not implemented for `i32`, which is required by `i32: Foo`
|
help: this trait has no implementations, consider adding one
--> f100.rs:2:1
|
2 | trait Bar {}
| ^^^^^^^^^
note: required for `i32` to implement `Foo`
--> f100.rs:3:14
|
3 | impl<T: Bar> Foo for T {}
| --- ^^^ ^
| |
| unsatisfied trait bound introduced here
```
Fix#40120.
`Diagnostic::keys`, which is used for hashing and equating diagnostics,
has a surprising behaviour: it ignores children, but only for lints.
This was added in #88493 to fix some duplicated diagnostics, but it
doesn't seem necessary any more.
This commit removes the special case and only four tests have changed
output, with additional errors. And those additional errors aren't
exact duplicates, they're just similar. For example, in
src/tools/clippy/tests/ui/same_name_method.rs we currently have this
error:
```
error: method's name is the same as an existing method in a trait
--> $DIR/same_name_method.rs:75:13
|
LL | fn foo() {}
| ^^^^^^^^^^^
|
note: existing `foo` defined here
--> $DIR/same_name_method.rs:79:9
|
LL | impl T1 for S {}
| ^^^^^^^^^^^^^^^^
```
and with this change we also get this error:
```
error: method's name is the same as an existing method in a trait
--> $DIR/same_name_method.rs:75:13
|
LL | fn foo() {}
| ^^^^^^^^^^^
|
note: existing `foo` defined here
--> $DIR/same_name_method.rs:81:9
|
LL | impl T2 for S {}
| ^^^^^^^^^^^^^^^^
```
I think printing this second argument is reasonable, possibly even
preferable to hiding it. And the other cases are similar.
When a method not found on a type parameter could have been provided by any
of multiple traits, suggest each trait individually, instead of a single
suggestion to restrict the type parameter with *all* of them.
Before:
```
error[E0599]: the method `cmp` exists for reference `&T`, but its trait bounds were not satisfied
--> $DIR/method-on-unbounded-type-param.rs:5:10
|
LL | (&a).cmp(&b)
| ^^^ method cannot be called on `&T` due to unsatisfied trait bounds
|
= note: the following trait bounds were not satisfied:
`T: Ord`
which is required by `&T: Ord`
`&T: Iterator`
which is required by `&mut &T: Iterator`
`T: Iterator`
which is required by `&mut T: Iterator`
help: consider restricting the type parameters to satisfy the trait bounds
|
LL | fn g<T>(a: T, b: T) -> std::cmp::Ordering where T: Iterator, T: Ord {
| +++++++++++++++++++++++++
```
After:
```
error[E0599]: the method `cmp` exists for reference `&T`, but its trait bounds were not satisfied
--> $DIR/method-on-unbounded-type-param.rs:5:10
|
LL | (&a).cmp(&b)
| ^^^ method cannot be called on `&T` due to unsatisfied trait bounds
|
= note: the following trait bounds were not satisfied:
`T: Ord`
which is required by `&T: Ord`
`&T: Iterator`
which is required by `&mut &T: Iterator`
`T: Iterator`
which is required by `&mut T: Iterator`
= help: items from traits can only be used if the type parameter is bounded by the trait
help: the following traits define an item `cmp`, perhaps you need to restrict type parameter `T` with one of them:
|
LL | fn g<T: Ord>(a: T, b: T) -> std::cmp::Ordering {
| +++++
LL | fn g<T: Iterator>(a: T, b: T) -> std::cmp::Ordering {
| ++++++++++
```
Fix#108428.
Normalize region obligation in lexical region resolution with next-gen solver
This normalizes region obligations when we `resolve_regions`, since they may be unnormalized with deferred projection equality.
It's pretty hard to add tests that exercise this without also triggering MIR borrowck errors (because we don't normalize there yet). I've added one test with two revisions that should test that we both 1. normalize region obligations in the param env, and 2. normalize registered region obligations during lexical region resolution.
When encountering
```rust
fn f<T>(a: T, b: T) -> std::cmp::Ordering {
a.cmp(&b) //~ ERROR E0599
}
```
output
```
error[E0599]: no method named `cmp` found for type parameter `T` in the current scope
--> $DIR/method-on-unbounded-type-param.rs:2:7
|
LL | fn f<T>(a: T, b: T) -> std::cmp::Ordering {
| - method `cmp` not found for this type parameter
LL | a.cmp(&b)
| ^^^ method cannot be called on `T` due to unsatisfied trait bounds
|
= help: items from traits can only be used if the type parameter is bounded by the trait
help: the following traits define an item `cmp`, perhaps you need to restrict type parameter `T` with one of them:
|
LL | fn f<T: Ord>(a: T, b: T) -> std::cmp::Ordering {
| +++++
LL | fn f<T: Iterator>(a: T, b: T) -> std::cmp::Ordering {
| ++++++++++
```
Fix#120186.
