Unify `CoroutineWitness` sooner in typeck, and stall coroutine obligations based off of `TypingEnv`
* Stall coroutine obligations based off of `TypingMode` in the old solver.
* Eagerly assign `TyKind::CoroutineWitness` to the witness arg of coroutines during typeck, rather than deferring them to the end of typeck.
r? lcnr
This is part of https://github.com/rust-lang/rust/issues/143017.
Use relative visibility when noting sealed trait to reduce false positive
Fixesrust-lang/rust#143392
I used relative visibility instead of just determining if it's public or not.
r? compiler
trait_sel: `MetaSized` always holds temporarily
As a temporary measure while a proper fix for `tests/ui/sized-hierarchy/incomplete-inference-issue-143992.rs` is implemented, make `MetaSized` obligations always hold. In effect, temporarily reverting the `sized_hierarchy` feature. This is a small change that can be backported.
cc rust-lang/rust#143992
r? ```@lcnr```
As a temporary measure while a proper fix for
`tests/ui/sized-hierarchy/incomplete-inference-issue-143992.rs`
is implemented, make `MetaSized` obligations always hold. In effect,
temporarily reverting the `sized_hierarchy` feature. This is a small
change that can be backported.
Split up the `unknown_or_malformed_diagnostic_attributes` lint
This splits up the lint into the following lint group:
- `unknown_diagnostic_attributes` - triggers if the attribute is unknown to the current compiler
- `misplaced_diagnostic_attributes` - triggers if the attribute exists but it is not placed on the item kind it's meant for
- `malformed_diagnostic_attributes` - triggers if the attribute's syntax or options are invalid
- `malformed_diagnostic_format_literals` - triggers if the format string literal is invalid, for example if it has unpaired curly braces or invalid parameters
- this pr doesn't create it, but future lints for things like deprecations can also go here.
This PR does not start emitting lints in places that previously did not.
## Motivation
I want to have finer control over what `unknown_or_malformed_diagnostic_attributes` does
I have a project with fairly low msrv that is/will have a lower msrv than future diagnostic attributes. So lints will be emitted when I or others compile it on a lower msrv.
At this time, there are two options to silence these lints:
- `#[allow(unknown_or_malformed_diagnostic_attributes)]` - this risks diagnostic regressions if I (or others) mess up using the attribute, or if the attribute's syntax ever changes.
- write a build script to detect the compiler version and emit cfgs, and then conditionally enable the attribute:
```rust
#[cfg_attr(rust_version_99, diagnostic::new_attr_in_rust_99(thing = ..))]`
struct Foo;
```
or conditionally `allow` the lint:
```rust
// lib.rs
#![cfg_attr(not(current_rust), allow(unknown_or_malformed_diagnostic_attributes))]
```
I like to avoid using build scripts if I can, so the following works much better for me. That is what this PR will let me do in the future:
```rust
#[allow(unknown_diagnostic_attribute, reason = "attribute came out in rust 1.99 but msrv is 1.70")]
#[diagnostic::new_attr_in_rust_99(thing = ..)]`
struct Foo;
Rework borrowing suggestions to use `Expr` instead of just `Span`
In the suggestion machinery for borrowing expressions and types, always use the available obligation `Span` to find the appropriate `Expr` to perform appropriateness checks no the `ExprKind` instead of on the textual snippet corresponding to the `Span`. (We were already doing this, but only for a subset of cases.) This now better handles situations where parentheses and `<>` are needed for correct syntax (`&(foo + bar)`, `(&foo).bar()`, `<&Foo>::bar()`, etc.).
Unify the logic for the case where `&` *and* `&mut` are appropriate with the logic for only one of those cases. (Instead of having two branches for emitting the suggestion, we now have a single one, using `Diag::multipart_suggestions` always.)
Handle the case when `S::foo()` should have been `<&S>::foo()` (instead of suggesting the prior `&S::foo()`. Fixrust-lang/rust#143393.
Make `Diag::multipart_suggestions` always verbose. CC rust-lang/rust#141973.
Constify `Fn*` traits
r? `@compiler-errors` `@fee1-dead`
this should unlock a few things. A few `const_closures` tests have broken even more than before, but that feature is marked as incomplete anyway
cc rust-lang/rust#67792
In the suggestion machinery for borrowing expressions and types, always use the available obligation `Span` to find the appropriate `Expr` to perform appropriateness checks no the `ExprKind` instead of on the textual snippet corresponding to the `Span`.
Unify the logic for the case where `&` *and* `&mut` are appropriate with the logic for only one of those cases.
Handle the case when `S::foo()` should have been `<&S>::foo()` (instead of suggesting the prior `&S::foo()`.
Instantiate auto trait/`Copy`/`Clone`/`Sized` before computing constituent types binder
This makes the binder logic w.r.t. coroutines a bit simpler.
r? lcnr
More carefully consider span context when suggesting remove `&mut`
Use `find_ancestor_inside` to compute a relative span that is macro-aware, rather than falling back to using BytePos arithmetic which is wrong for `&mut`.
Fixes https://github.com/rust-lang/rust/issues/143523
Do not suggest borrow that is already there in fully-qualified call
When encountering `&str::from("value")` do not suggest `&&str::from("value")`.
Fix#132041.
Fix some comments and related types and locals where it is obvious, e.g.
- bare_fn -> fn_ptr
- LifetimeBinderKind::BareFnType -> LifetimeBinderKind::FnPtrType
Co-authored-by: León Orell Valerian Liehr <me@fmease.dev>
Fast path nitpicks
Miscellaneous commits that I didn't really want to fold into anything else.
Fixes one theoretical bug with the fast path not considering polarity for `T: !Sized` bounds.
