Adjust and slightly generalize operator error suggestion
(in no particular order)
* Stop passing around a whole extra `ProjectionPredicate`
* Add spaces around `=` in `Trait<..., Output = Ty>` suggestion
* Some code clean-ups, including
* add `lang_item_for_op` to turn a `Op` into a `DefId`
* avoid `SourceMap` because we don't really need to render an expr
* Remove `TypeParamVisitor` in favor of just checking `ty.has_param_types_or_consts` -- this acts a bit differently, but shouldn't cause erroneous suggestions (actually might generalize them a bit)
* We now suggest `Output = Ty` in the `where` clause suggestion when we fail to add `Struct<T>` and `T`.
I can split this out into more PRs if needed, but they're all just miscellaneous generalizations, changes, and nitpicks I saw when messing with this operator code.
const_generics: correctly deal with bound variables
removes the hack in `resolve` which was needed because we evaluated constants without caring about their bound variables.
Each commit should be fairly self-contained, even if they build on each other
r? `@jackh726`
rustc: Parameterize `ty::Visibility` over used ID
It allows using `LocalDefId` instead of `DefId` when possible, and also encode cheaper `Visibility<DefIndex>` into metadata.
Update `SessionDiagnostic::into_diagnostic` to take `Handler` instead of `ParseSess`
Suggested by the team in [this Zulip Topic](https://rust-lang.zulipchat.com/#narrow/stream/336883-i18n/topic/.23100717.20SessionDiagnostic.20on.20Handler).
`Handler` already has almost all the capabilities of `ParseSess` when it comes to diagnostic emission, in this migration we only needed to add the ability to access `source_map` from the emitter in order to get a `Snippet` and the `start_point`. Not sure if adding these two methods [`span_to_snippet_from_emitter` and `span_start_point_from_emitter`] is the best way to address this gap.
P.S. If this goes in the right direction, then we probably may want to move `SessionDiagnostic` to `rustc_errors` and rename it to `DiagnosticHandler` or something similar.
r? `@davidtwco`
r? `@compiler-errors`
Point out when a callable is not actually callable because its return is not sized
Fixes#100755
I didn't add a UI test for that one because it's equivalent to the UI test that already exists in the suite.
`BindingAnnotation` refactor
* `ast::BindingMode` is deleted and replaced with `hir::BindingAnnotation` (which is moved to `ast`)
* `BindingAnnotation` is changed from an enum to a tuple struct e.g. `BindingAnnotation(ByRef::No, Mutability::Mut)`
* Associated constants added for convenience `BindingAnnotation::{NONE, REF, MUT, REF_MUT}`
One goal is to make it more clear that `BindingAnnotation` merely represents syntax `ref mut` and not the actual binding mode. This was especially confusing since we had `ast::BindingMode`->`hir::BindingAnnotation`->`thir::BindingMode`.
I wish there were more symmetry between `ByRef` and `Mutability` (variant) naming (maybe `Mutable::Yes`?), and I also don't love how long the name `BindingAnnotation` is, but this seems like the best compromise. Ideas welcome.
Suggested by the team in this Zulip Topic https://rust-lang.zulipchat.com/#narrow/stream/336883-i18n/topic/.23100717.20SessionDiagnostic.20on.20Handler
Handler already has almost all the capabilities of ParseSess when it comes to diagnostic emission, in this migration we only needed to add the ability to access source_map from the emitter in order to get a Snippet and the start_point. Not sure if this is the best way to address this gap
safe transmute: use `Assume` struct to provide analysis options
This task was left as a TODO in #92268; resolving it brings [`BikeshedIntrinsicFrom`](https://doc.rust-lang.org/nightly/core/mem/trait.BikeshedIntrinsicFrom.html) more in line with the API defined in [MCP411](https://github.com/rust-lang/compiler-team/issues/411).
**Before:**
```rust
pub unsafe trait BikeshedIntrinsicFrom<
Src,
Context,
const ASSUME_ALIGNMENT: bool,
const ASSUME_LIFETIMES: bool,
const ASSUME_VALIDITY: bool,
const ASSUME_VISIBILITY: bool,
> where
Src: ?Sized,
{}
```
**After:**
```rust
pub unsafe trait BikeshedIntrinsicFrom<Src, Context, const ASSUME: Assume = { Assume::NOTHING }>
where
Src: ?Sized,
{}
```
`Assume::visibility` has also been renamed to `Assume::safety`, as library safety invariants are what's actually being assumed; visibility is just the mechanism by which it is currently checked (and that may change).
r? `@oli-obk`
---
Related:
- https://github.com/rust-lang/compiler-team/issues/411
- https://github.com/rust-lang/rust/issues/99571
Attempt to normalize `FnDef` signature in `InferCtxt::cmp`
Stashes a normalization callback in `InferCtxt` so that the signature we get from `tcx.fn_sig(..).subst(..)` in `InferCtxt::cmp` can be properly normalized, since we cannot expect for it to have normalized types since it comes straight from astconv.
This is kind of a hack, but I will say that `@jyn514` found the fact that we present unnormalized types to be very confusing in real life code, and I agree with that feeling. Though altogether I am still a bit unsure about whether this PR is worth the effort, so I'm open to alternatives and/or just closing it outright.
On the other hand, this isn't a ridiculously heavy implementation anyways -- it's less than a hundred lines of changes, and half of that is just miscellaneous cleanup.
This is stacked onto #100471 which is basically unrelated, and it can be rebased off of that when that lands or if needed.
---
The code:
```rust
trait Foo { type Bar; }
impl<T> Foo for T {
type Bar = i32;
}
fn foo<T>(_: <T as Foo>::Bar) {}
fn needs_i32_ref_fn(f: fn(&'static i32)) {}
fn main() {
needs_i32_ref_fn(foo::<()>);
}
```
Before:
```
= note: expected fn pointer `fn(&'static i32)`
found fn item `fn(<() as Foo>::Bar) {foo::<()>}`
```
After:
```
= note: expected fn pointer `fn(&'static i32)`
found fn item `fn(i32) {foo::<()>}`
```
Rollup of 9 pull requests
Successful merges:
- #95376 (Add `vec::Drain{,Filter}::keep_rest`)
- #100092 (Fall back when relating two opaques by substs in MIR typeck)
- #101019 (Suggest returning closure as `impl Fn`)
- #101022 (Erase late bound regions before comparing types in `suggest_dereferences`)
- #101101 (interpret: make read-pointer-as-bytes a CTFE-only error with extra information)
- #101123 (Remove `register_attr` feature)
- #101175 (Don't --bless in pre-push hook)
- #101176 (rustdoc: remove unused CSS selectors for `.table-display`)
- #101180 (Add another MaybeUninit array test with const)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Avoid reporting overflow in `is_impossible_method`
Fixes#100620
We're evaluating a new predicate in a different param-env than it was checked during typeck, so be more careful about handling overflow errors. Instead of using `FulfillmentCtxt`, using `InferCtxt::evaluate_obligation` by itself will give us back the overflow error, so we can throw it away properly.
This may give us more false-positives, but it doesn't regress the `<HashMap as Iterator>::rev` example that originally motivated adding `is_impossible_method` in the first place.
Coherence negative impls implied bounds
Fixes#93875
This PR is rebased on top of #100789 and it would need to include that one which is already r+ed.
r? ``@nikomatsakis``
cc ``@lcnr`` (which I've talked about 3222f420d9, I guess after you finish your reordering of modules and work with OutlivesEnvironmentEnv this commit can just be reverted).
InferCtxt tainted_by_errors_flag should be Option<ErrorGuaranteed>
Fixes#100321.
Use Cell<Option<ErrorGuaranteed>> to guarantee that we emit an error when that flag is set.
Use separate infcx to solve obligations during negative coherence
I feel like I fixed this already but I may have fixed it then forgot to push the branch...
Also fixes up some redundant param-envs being passed around (since they're already passed around in the `Obligation`)
Fixes#99662
r? ``@spastorino``
implied bounds: explicitly state which types are assumed to be wf
Adds a new query which maps each definition to the types which that definition assumes to be well formed. The intent is to make it easier to reason about implied bounds.
This change should not influence the user-facing behavior of rustc. Notably, `borrowck` still only assumes that the function signature of associated functions is well formed while `wfcheck` assumes that the both the function signature and the impl trait ref is well formed. Not sure if that by itself can trigger UB or whether it's just annoying.
As a next step, we can add `WellFormed` predicates to `predicates_of` of these items and can stop adding the wf bounds at each place which uses them. I also intend to move the computation from `assumed_wf_types` to `implied_bounds` into the `param_env` computation. This requires me to take a deeper look at `compare_predicate_entailment` which is currently somewhat weird wrt implied bounds so I am not touching this here.
r? `@nikomatsakis`
Refactor: remove unnecessary string searchings
This patch removes unnecessary string searchings for checking if function arguments have `&` and `&mut`.
Revert "Rollup merge of #97346 - JohnTitor:remove-back-compat-hacks, …
…r=oli-obk"
This reverts commit c703d11dcc, reversing
changes made to 64eb9ab869.
it didn't apply cleanly, so now it works the same for RPIT and for TAIT instead of just working for RPIT, but we should keep those in sync anyway. It also exposed a TAIT bug (see the feature gated test that now ICEs).
r? `@pnkfelix`
fixes#99536
orphan check: rationalize our handling of constants
cc `@rust-lang/types` `@rust-lang/project-const-generics` on whether you agree with this reasoning.
r? types
Keep going if normalized projection has unevaluated consts in `QueryNormalizer`
#100312 was the wrong approach, I think this is the right one.
When normalizing a type, if we see that it's a projection, we currently defer to `tcx.normalize_projection_ty`, which normalizes the projections away but doesn't touch the unevaluated constants. So now we just continue to fold the type if it has unevaluated constants so we make sure to evaluate those too, if we can.
Fixes#100217Fixes#83972Fixes#84669Fixes#86710Fixes#82268Fixes#73298
consider unnormalized types for implied bounds
extracted, and slightly modified, from #98900
The idea here is that generally, rustc is split into things which can assume its inputs are well formed[^1], and things which have verify that themselves.
Generally most predicates should only deal with well formed inputs, e.g. a `&'a &'b (): Trait` predicate should be able to assume that `'b: 'a` holds. Normalization can loosen wf requirements (see #91068) and must therefore not be used in places which still have to check well formedness. The only such place should hopefully be `WellFormed` predicates
fixes#87748 and #98543
r? `@jackh726` cc `@rust-lang/types`
[^1]: These places may still encounter non-wf inputs and have to deal with them without causing an ICE as we may check for well formedness out of order.
Don't document impossible to call default trait items on impls
Closes#100176
This only skips documenting _default_ trait items on impls, not ones that are written inside the impl block. This is a conservative approach, since I think we should document all items written in an impl block (I guess unless hidden or whatever), but the existence of this new query I added makes this easy to extend to other rustdoc cases.
Delay a bug when failed to normalize trait ref during specialization
The error messages still kinda suck here but they don't ICE anymore...
Fixes#45814Fixes#43037
r? types
Use `TraitEngine` in more places that don't specifically need `FulfillmentContext::new_in_snapshot`
Not sure if this change is worthwhile, but couldn't hurt re: chalkification
r? types
remove `commit_unconditionally`
`commit_unconditionally` is a noop unless we somehow inspect the current state of our snapshot. The only thing which does that is the leak check which was only used in one place where `commit_if_ok` is probably at least as, or even more, correct.
r? rust-lang/types
Always include a position span in `rustc_parse_format::Argument`
Moves the spans from the `Position` enum to always be included in the `Argument` struct. Doesn't make any changes to use it in rustc, but it will be useful for some upcoming Clippy lints
make `PlaceholderConst` not store the type of the const
Currently the `Placeholder` variant on `ConstKind` is 28 bytes when with this PR its 8 bytes, i am not sure this is really useful at all rn since `Unevaluated` and `Value` variants are huge still but eventually it should be possible to get both down to 16 bytes 🤔. Mostly opening this to see if this change has any perf impact when done before it can make `ConstKind`/`ConstS` smaller
`codegen_fulfill_obligation` expect erased regions
it's a query, so by erasing regions before calling it, we get better caching.
This doesn't actually change anything as its already the status quo.
Improve type mismatch w/ function signatures
This PR makes use of `note: expected/found` (instead of labeling types in labels) in type mismatch with function signatures. Pros: it's easier to compare the signatures, cons: the error is a little more verbose now.
This is especially nice when
- The signatures differ in a small subset of parameters (same parameters are elided)
- The difference is in details, for example `isize` vs `usize` (there is a better chance that the types align)
Also this PR fixes the inconsistency in variable names in the edited code (`expected` and `found`).
A zulip thread from which this pr started: [[link]](https://rust-lang.zulipchat.com/#narrow/stream/147480-t-compiler.2Fwg-diagnostics/topic/Type.20error.20regression.3F.2E.2E.2E/near/289756602).
An example diagnostic:
<table>
<tr>
<th>this pr</th>
<th>nightly</th>
</tr>
<tr>
<td>
```text
error[E0631]: type mismatch in function arguments
--> ./t.rs:4:12
|
4 | expect(&f);
| ------ ^^ expected due to this
| |
| required by a bound introduced by this call
...
10 | fn f(_: isize, _: u8, _: Vec<u32>) {}
| ---------------------------------- found signature defined here
|
= note: expected function signature `fn(usize, _, Vec<u64>) -> _`
found function signature `fn(isize, _, Vec<u32>) -> _`
note: required because of the requirements on the impl of `Trait` for `fn(isize, u8, Vec<u32>) {f}`
--> ./t.rs:8:9
|
8 | impl<F> Trait for F where F: Fn(usize, u8, Vec<u64>) -> u8 {}
| ^^^^^ ^
= note: required for the cast from `fn(isize, u8, Vec<u32>) {f}` to the object type `dyn Trait`
```
</td>
<td>
```text
error[E0631]: type mismatch in function arguments
--> ./t.rs:4:12
|
4 | expect(&f);
| ------ ^^ expected signature of `fn(usize, u8, Vec<u64>) -> _`
| |
| required by a bound introduced by this call
...
10 | fn f(_: isize, _: u8, _: Vec<u32>) {}
| ---------------------------------- found signature of `fn(isize, u8, Vec<u32>) -> _`
|
note: required because of the requirements on the impl of `Trait` for `fn(isize, u8, Vec<u32>) {f}`
--> ./t.rs:8:9
|
8 | impl<F> Trait for F where F: Fn(usize, u8, Vec<u64>) -> u8 {}
| ^^^^^ ^
= note: required for the cast to the object type `dyn Trait`
```
</td>
</tr>
</table>
<details><summary>code</summary>
<p>
```rust
fn main() {
fn expect(_: &dyn Trait) {}
expect(&f);
}
trait Trait {}
impl<F> Trait for F where F: Fn(usize, u8, Vec<u64>) -> u8 {}
fn f(_: isize, _: u8, _: Vec<u32>) {}
```
</p>
</details>
r? `@compiler-errors`
use `check_region_obligations_and_report_errors` to avoid ICEs
If we don't call `process_registered_region_obligations` before `resolve_regions_and_report_errors` then we'll ICE if we have any region obligations, and `check_region_obligations_and_report_errors` just does both of these for us in a nice convenient function.
Fixes#53475
r? types
Generate correct suggestion with named arguments used positionally
Address issue #99265 by checking each positionally used argument
to see if the argument is named and adding a lint to use the name
instead. This way, when named arguments are used positionally in a
different order than their argument order, the suggested lint is
correct.
For example:
```
println!("{b} {}", a=1, b=2);
```
This will now generate the suggestion:
```
println!("{b} {a}", a=1, b=2);
```
Additionally, this check now also correctly replaces or inserts
only where the positional argument is (or would be if implicit).
Also, width and precision are replaced with their argument names
when they exists.
Since the issues were so closely related, this fix for issue #99265
also fixes issue #99266.
Fixes#99265Fixes#99266
This initial implementation handles transmutations between types with specified layouts, except when references are involved.
Co-authored-by: Igor null <m1el.2027@gmail.com>
Deeply deny fn and raw ptrs in const generics
I think this is right -- just because we wrap a fn ptr in a wrapper type does not mean we should allow it in a const parameter.
We now reject both of these in the same way:
```
#![feature(adt_const_params)]
#[derive(Eq, PartialEq)]
struct Wrapper();
fn foo<const W: Wrapper>() {}
fn foo2<const F: fn()>() {}
```
This does regress one test (`src/test/ui/consts/refs_check_const_eq-issue-88384.stderr`), but I'm not sure it should've passed in the first place.
cc: ``@b-naber`` who introduced that test^
fixes#99641
Restore `Opaque` behavior to coherence check
Fixes#99663.
This broke in 84c3fcd2a0. I'm not exactly certain that adding this behavior back is necessarily correct, but at least the UI test I provided may stimulate some thoughts.
I think delaying a bug here is certainly not correct in the case of opaques -- if we want to change coherence behavior for opaques, then we should at least be emitting a new error.
r? ``@lcnr``
handle consts with param/infer in `const_eval_resolve` better
This PR addresses [this thread here](https://github.com/rust-lang/rust/pull/99449#discussion_r924141230). Was this the change you were looking for ``@lcnr?``
Interestingly, one test has begun to pass. Was that expected?
r? ``@lcnr``
Address issue #99265 by checking each positionally used argument
to see if the argument is named and adding a lint to use the name
instead. This way, when named arguments are used positionally in a
different order than their argument order, the suggested lint is
correct.
For example:
```
println!("{b} {}", a=1, b=2);
```
This will now generate the suggestion:
```
println!("{b} {a}", a=1, b=2);
```
Additionally, this check now also correctly replaces or inserts
only where the positional argument is (or would be if implicit).
Also, width and precision are replaced with their argument names
when they exists.
Since the issues were so closely related, this fix for issue #99265
also fixes issue #99266.
Fixes#99265Fixes#99266
Do not resolve associated const when there is no provided value
Fixes#98629, since now we just delay a bug when we're not able to evaluate a const item due to the value not actually being provided by anything. This means compilation proceeds forward to where the "missing item in impl" error is emitted.
----
The root issue here is that when we're looking for the defining `LeafDef` in `resolve_associated_item`, we end up getting the trait's AssocItem instead of the impl's AssocItem (which does not exist). This resolution "succeeds" even if the trait's item has no default value, and then since this item has no value to evaluate, it turns into a const eval error.
This root issue becomes problematic (as in #98629) when this const eval error happens in wfcheck (for example, due to normalizing the param-env of something that references this const). Since this happens sooner than the check that an impl actually provides all of the items that a trait requires (which happens during later typecheck), we end up aborting compilation early with only this un-informative message.
I'm not exactly sure _why_ this bug arises due to #96591 -- perhaps valtrees are evaluated more eagerly than in the old system?
r? ``@oli-obk`` or ``@lcnr`` since y'all are familiar with const eval and reviewed #96591, though feel free to reassign.
This is a regression from stable to beta, so I would be open to considering this for beta backport. It seems correct to me, especially given the improvements in the other UI tests this PR touches, but may have some side-effects that I'm unaware of...?
Fix hack that remaps env constness.
WARNING: might have perf implications.
Are there any more problems with having a constness in the `ParamEnv` now? :)
r? `@oli-obk`
Improve suggestions for returning binding
Fixes#99525
Also reworks the cause codes for match and if a bit, I think cleaning them up in a positive way.
We no longer need to call `could_remove_semicolon` in successful code, which might save a few cycles?
move `considering_regions` to the infcx
it seems weird to prove some obligations which constrain inference vars while ignoring regions in a context which considers regions. This is especially weird because even for a fulfillment context with ignored regions, we still added region outlives bounds when directly relating regions.
tbh our handling of regions is still very weird, but at least this is a step in the right direction imo.
r? rust-lang/types
