| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
PolyProjectionPredicate<'tcx>`
|
|
This function is now used to check `#[panic_handler]`, `start` lang item, `main`, `#[start]` and intrinsic functions.
The diagnosis produced are now closer to the ones produced by trait/impl method signature mismatch.
|
|
|
|
move required_consts check to general post-mono-check function
This factors some code that is common between the interpreter and the codegen backends into shared helper functions. Also as a side-effect the interpreter now uses the same `eval` functions as everyone else to get the evaluated MIR constants.
Also this is in preparation for another post-mono check that will be needed for (the current hackfix for) https://github.com/rust-lang/rust/issues/115709: ensuring that all locals are dynamically sized.
I didn't expect this to change diagnostics, but it's just cycle errors that change.
r? `@oli-obk`
|
|
I found these by commenting out all `Lift` derives and then adding back
the ones that were necessary to successfully compile.
|
|
r=compiler-errors
`#[diagnostic::on_unimplemented]` without filters
This commit adds support for a `#[diagnostic::on_unimplemented]` attribute with the following options:
* `message` to customize the primary error message
* `note` to add a customized note message to an error message
* `label` to customize the label part of the error message
The relevant behavior is specified in [RFC-3366](https://rust-lang.github.io/rfcs/3366-diagnostic-attribute-namespace.html)
|
|
|
|
|
|
|
|
This commit adds support for a `#[diagnostic::on_unimplemented]`
attribute with the following options:
* `message` to customize the primary error message
* `note` to add a customized note message to an error message
* `label` to customize the label part of the error message
Co-authored-by: León Orell Valerian Liehr <me@fmease.dev>
Co-authored-by: Michael Goulet <michael@errs.io>
|
|
r=lcnr,compiler-errors
Bubble up opaque <eq> opaque operations instead of picking an order
In case we are in `Bubble` mode (meaning every opaque type that is defined in the current crate is treated as if it were in its defining scope), we don't try to register an opaque type as the hidden type of another opaque type, but instead bubble up an obligation to equate them at the query caller site. Usually that means we have a `DefiningAnchor::Bind` and thus can reliably figure out whether an opaque type is in its defining scope. Where we can't, we'll error out, so the default is sound.
With this change we start using `AliasTyEq` predicates in the old solver, too.
fixes https://github.com/rust-lang/rust/issues/108498
But also regresses `tests/ui/impl-trait/anon_scope_creep.rs`. Our use of `Bubble` for `check_opaque_type_well_formed` is going to keep biting us.
r? `@lcnr` `@compiler-errors`
|
|
|
|
Point out if a local trait has no implementations
Slightly helps with #115741
|
|
The `Debug` impl for `Ty` just calls the `Display` impl for `Ty`. This
is surprising and annoying. In particular, it means `Debug` doesn't show
as much information as `Debug` for `TyKind` does. And `Debug` is used in
some user-facing error messages, which seems bad.
This commit changes the `Debug` impl for `Ty` to call the `Debug` impl
for `TyKind`. It also does a number of follow-up changes to preserve
existing output, many of which involve inserting
`with_no_trimmed_paths!` calls. It also adds `Display` impls for
`UserType` and `Canonical`.
Some tests have changes to expected output:
- Those that use the `rustc_abi(debug)` attribute.
- Those that use the `EMIT_MIR` annotation.
In each case the output is slightly uglier than before. This isn't
ideal, but it's pretty weird (particularly for the attribute) that the
output is using `Debug` in the first place. They're fairly obscure
attributes (I hadn't heard of them) so I'm not worried by this.
For `async-is-unwindsafe.stderr`, there is one line that now lacks a
full path. This is a consistency improvement, because all the other
mentions of `Context` in this test lack a path.
|
|
|
|
|
|
r=compiler-errors
Fix error report for size overflow from transmute
Fixes #115402
The span in the error reporting always points to the `dst`, this is an old issue, I may open another PR to fix it.
|
|
|
|
|
|
confirming object candidate
|
|
|
|
Permit recursive weak type aliases
I saw #63097 and thought "we can do ~~better~~ funnier". So here it is. It's not useful, but it's certainly something. This may actually become feasible with lazy norm (so in 5 years (constant, not reducing over time)).
r? `@estebank`
cc `@GuillaumeGomez`
|
|
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #115164 (MIR validation: reject in-place argument/return for packed fields)
- #115240 (codegen_llvm/llvm_type: avoid matching on the Rust type)
- #115294 (More precisely detect cycle errors from type_of on opaque)
- #115310 (Document panic behavior across editions, and improve xrefs)
- #115311 (Revert "Suggest using `Arc` on `!Send`/`!Sync` types")
- #115317 (Devacationize oli-obk)
- #115319 (don't use SnapshotVec in Graph implementation, as it looks unused; use Vec instead)
- #115322 (Tweak output of `to_pretty_impl_header` involving only anon lifetimes)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Tweak output of `to_pretty_impl_header` involving only anon lifetimes
Do not print `impl<> Foo for &Bar`.
|
|
Revert "Suggest using `Arc` on `!Send`/`!Sync` types"
Closes https://github.com/rust-lang/rust/issues/114687. This is a clean revert of https://github.com/rust-lang/rust/pull/88936 + https://github.com/rust-lang/rust/pull/115210. The suggestion to Arc\<{Self}\> when Self does not implement Send is *always* wrong.
https://github.com/rust-lang/rust/pull/114842 is considering a way to make a more refined suggestion.
|
|
More precisely detect cycle errors from type_of on opaque
Not sure if this still needs work. Just putting it up for initial impressions, since it seems that a few people are frustrated with the increased error verbosity due to #113320.
Essentially we introduce a new sub-query for `type_of` specifically for opaques which returns a value that is able to distinguish "has errors" from "due to cycle recovery".
Fixes #115188
r? `@oli-obk`
|
|
Do not print `impl<> Foo for &Bar`.
|
|
This reverts commit 9de1a472b68ed85f396b2e2cc79c3ef17584d6e1.
|
|
|
|
|
|
This flag is intended for evaluation of trait upcasting
space cost for embedded use cases.
|
|
Speed up compilation of `type-system-chess`
[`type-system-chess`](https://github.com/rust-lang/rustc-perf/pull/1680) is an unusual program that implements a compile-time chess position solver in the trait system(!) This PR is about making it compile faster.
r? `@ghost`
|
|
Point at return type when it influences non-first `match` arm
When encountering code like
```rust
fn foo() -> i32 {
match 0 {
1 => return 0,
2 => "",
_ => 1,
}
}
```
Point at the return type and not at the prior arm, as that arm has type `!` which isn't influencing the arm corresponding to arm `2`.
Fix #78124.
|
|
|
|
|
|
Co-authored-by: lcnr <rust@lcnr.de>
|
|
|
|
|
|
When encountering code like
```rust
fn foo() -> i32 {
match 0 {
1 => return 0,
2 => "",
_ => 1,
}
}
```
Point at the return type and not at the prior arm, as that arm has type
`!` which isn't influencing the arm corresponding to arm `2`.
Fix #78124.
|
|
|
|
normalize in `trait_ref_is_knowable` in new solver
fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/51
Alternatively we could avoid normalizing the self type and do this at the end of the `assemble_candidates_via_self_ty` stack by splitting candidates into:
- applicable without normalizing self type
- applicable for aliases, even if they can be normalized
- applicable for stuff which cannot get normalized further
I don't think this would have any significant benefits and it also seems non-trivial to avoid normalizing only the self type in `trait_ref_is_knowable`.
r? `@compiler-errors`
|
|
|
|
|
|
|
|
|
