| Age | Commit message (Collapse) | Author | Lines |
|---|
|
make `compare_const_impl` a query and use it in `instance.rs`
Fixes #88365
the bug in #88365 was caused by some `instance.rs` code using the `PartialEq` impl on `Ty` to check that the type of the associated const in an impl is the same as the type of the associated const in the trait definition. This was wrong for two reasons:
- the check typeck does is that the impl type is a subtype of the trait definition's type (see `mismatched_impl_ty_2.rs` which [was ICEing](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f6d60ebe6745011f0d52ab2bc712025d) before this PR on stable)
- it assumes that if two types are equal then the `PartialEq` impl will reflect that which isnt true for higher ranked types or type level constants when `feature(generic_const_exprs)` is enabled (see `mismatched_impl_ty_3.rs` for higher ranked types which was [ICEing on stable](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=d7af131a655ed515b035624626c62c71))
r? `@lcnr`
|
|
|
|
|
|
|
|
|
|
Add test for issue 82633
Fixes #82633
r? `@estebank`
The current stderr looks slightly different from [source](https://github.com/rust-lang/rust/pull/83915/files#diff-8c64c576ccaceb816e71d2279a6ee4bf79211bc06f55c46dda3f98a18748ad7a), so I used the latest one from nightly. Do let me know if anything is wrong.
|
|
Suggest `==` to wrong assign expr
Given the following code:
```rust
fn main() {
let x = 3;
let y = 3;
if x == x && y = y {
println!("{}", x);
}
}
```
Current output is:
```
error[E0308]: mismatched types
--> src/main.rs:4:18
|
4 | if x == x && y = y {
| ^ expected `bool`, found integer
error[E0308]: mismatched types
--> src/main.rs:4:8
|
4 | if x == x && y = y {
| ^^^^^^^^^^^^^^^ expected `bool`, found `()`
```
This adds a suggestion:
```diff
error[E0308]: mismatched types
--> src/main.rs:6:18
|
6 | if x == x && y = y {
| ^ expected `bool`, found integer
error[E0308]: mismatched types
--> src/main.rs:6:8
|
6 | if x == x && y = y {
| ^^^^^^^^^^^^^^^ expected `bool`, found `()`
|
+ help: you might have meant to compare for equality
+ |
+ 6 | if x == x && y == y {
+ | +
```
And this fixes a part of #97469
|
|
Suggest calling method if fn does not exist
I tried to split this up into two commits, the first where we stash the resolution error until typeck (which causes a bunch of diagnostics changes because the ordering of error messages change), then the second commit is the actual logic that actually implements the suggestion.
I am not in love with the presentation of the suggestion, so I could use some advice for how to format the actual messaging.
r? diagnostics
Fixes #102518
|
|
IfExpressionWithNoElse
this will fix #102397
|
|
Fix unwind drop glue for if-then scopes
cc `@est31`
Fix #102317
Fix #99852
This PR fixes the drop glue for unwinding from a panic originated in a drop while breaking out for the else block in an `if-then` scope.
MIR validation does not fail for the synchronous versions of the test program, because `StorageDead` statements are skipped over in the unwinding process. It is only becoming a problem when it is inside a generator where `StorageDead` must be kept around.
|
|
|
|
|
|
|
|
Suggest `.into()` when all other coercion suggestions fail
Also removes some bogus suggestions because we now short-circuit when offering coercion suggestions(instead of, for example, suggesting every one that could possibly apply)
Fixes #102415
|
|
panic-on-uninit: adjust checks to 0x01-filling
Now that `mem::uninitiailized` actually fills memory with `0x01` (https://github.com/rust-lang/rust/pull/99182), we can make it panic in a few less cases without risking a lot more UB -- which hopefully slightly improves compatibility with some old code, and which might increase the chance that we can check inside arrays in the future.
We detect almost all of these with our lint, so authors of such code should still be warned -- but if this happens deep inside a dependency, the panic can be quite interruptive, so it might be better not to do it when there is no risk of LLVM UB. Therefore, adjust the `might_permit_raw_init` logic to care primarily about LLVM UB. To my knowledge, it actually covers all cases of LLVM UB now.
Fixes https://github.com/rust-lang/rust/issues/66151
Cc ``@5225225``
|
|
TaKO8Ki:do-not-suggest-adding-generic-args-for-turbofish, r=compiler-errors
Stop suggesting adding generic args for turbofish
Fixes #100137
|
|
|
|
|
|
|
|
|
|
|
|
|
|
follow-up fix about 101866 to print the self type.
modified: compiler/rustc_trait_selection/src/traits/error_reporting/mod.rs
modified: src/test/ui/error-codes/E0283.stderr
modified: src/test/ui/error-codes/E0790.stderr
modified: src/test/ui/traits/static-method-generic-inference.stderr
modified: src/test/ui/type/issue-101866.stderr
|
|
Rageking8:slightly-improve-no-return-for-returning-function-error, r=compiler-errors
Slightly improve no return for returning function error
Fixes #100607
The rationale is that absolute beginners will be slightly confused as to why certain lines of code in a function does not require a semicolon. (I have actually witness a beginner having this confusion). Hence, a slight rationale is added "to return this value", which signals to the user that after removing said semicolon the value is returned resolving that error.
However, if this is not desirable, I welcome any other suggestions. Thanks.
|
|
|
|
|
|
|
|
modified: compiler/rustc_trait_selection/src/traits/error_reporting/mod.rs
modified: src/test/ui/error-codes/E0283.stderr
modified: src/test/ui/error-codes/E0790.stderr
modified: src/test/ui/traits/static-method-generic-inference.stderr
modified: src/test/ui/type/issue-101866.stderr
|
|
Add test for #102605
Fixes #102605
|
|
Only allow ~const bounds for traits with #[const_trait]
r? `@fee1-dead`
|
|
Check generic argument compatibility when projecting assoc ty
Fixes #102114
|
|
|
|
|
|
Lint against nested opaque types that don't satisfy associated type bounds
See the test failures for examples of places where this lint would fire.
r? `@oli-obk`
|
|
Don't ICE when trying to copy unsized value in const prop
When we have a trivially false where-clause predicate like `Self: Sized` where `Self = dyn Trait`, we sometimes don't throw an error during typeck for an illegal operation such as copying an unsized type.
This, unfortunately, cannot be made into an error (at least not without some migration -- see #95611 for example), but we should at least not ICE, since this function will never actually be reachable from main, for example.
r? `@RalfJung` since I think you added these assertions? but feel free to reassign.
Fixes #102553
|
|
Normalize substs before resolving instance in `NoopMethodCall` lint
Fixes #102074
r? types
|
|
|
|
|
|
|
|
|
|
Improve spans when splitting multi-char operator tokens for proc macros.
When a two-char (or three-char) operator token is split into single-char operator tokens before being passed to a proc macro, the single-char tokens are given the original span of length two (or three). This PR gives them more accurate spans.
r? `@Aaron1011`
cc `@petrochenkov`
|
|
Ignore fuchsia on two compiler tests
Adding `ignore-fuchsia` to two irrelevant compiler tests
cc. `@djkoloski`
r? `@tmandry`
|
|
Delay evaluating lint primary message until after it would be suppressed
Fixes #102561
Fixes #102572
|
|
r=compiler-errors
Suggest unwrap_or_else when a closure is given
Fixes #102320
r? `@compiler-errors`
|
|
|
|
|
|
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #98218 (Document the conditional existence of `alloc::sync` and `alloc::task`.)
- #99216 (docs: be less harsh in wording for Vec::from_raw_parts)
- #99460 (docs: Improve AsRef / AsMut docs on blanket impls)
- #100470 (Tweak `FpCategory` example order.)
- #101040 (Fix `#[derive(Default)]` on a generic `#[default]` enum adding unnecessary `Default` bounds)
- #101308 (introduce `{char, u8}::is_ascii_octdigit`)
- #102486 (Add diagnostic struct for const eval error in `rustc_middle`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
danielhenrymantilla:no-bounds-for-default-annotated-derive, r=joshtriplett
Fix `#[derive(Default)]` on a generic `#[default]` enum adding unnecessary `Default` bounds
That is, given something like:
```rs
// #[default] on a generic enum does not add `Default` bounds to the type params.
#[derive(Default)]
enum MyOption<T> {
#[default]
None,
Some(T),
}
```
then `MyOption<T> : Default`_as currently implemented_ only holds when `T : Default`, as reported by ```@5225225``` [over Zulip](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/.23.5Bderive.28Default.29.5D.20for.20enums.20with.20fields).
This is contrary to [what the accepted RFC proposes](https://rust-lang.github.io/rfcs/3107-derive-default-enum.html#generated-bounds) (_i.e._, that `T` be allowed not to be itself `Default`), and indeed seems to be a rather unnecessary limitation.
|
