Tweak multispan rendering to reduce output length
Consider comments and bare delimiters the same as an "empty line" for purposes of hiding rendered code output of long multispans. This results in more aggressive shortening of rendered output without losing too much context, specially in `*.stderr` tests that have "hidden" comments. We do that check not only on the first 4 lines of the multispan, but now also on the previous to last line as well.
The recently landed PR to adjust arbitrary self types was a bit
overenthusiastic, advising folks to use the new Receiver trait even
before it's been stabilized. Revert to the older wording of the lint in
such cases.
Consider comments and bare delimiters the same as an "empty line" for purposes of hiding rendered code output of long multispans. This results in more aggressive shortening of rendered output without losing too much context, specially in `*.stderr` tests that have "hidden" comments.
Arbitrary self types v2: main compiler changes
This is the main PR in a series of PRs related to Arbitrary Self Types v2, tracked in #44874. Specifically this is step 7 of the plan [described here](https://github.com/rust-lang/rust/issues/44874#issuecomment-2122179688), for [RFC 3519](https://github.com/rust-lang/rfcs/pull/3519).
Overall this PR:
* Switches from the `Deref` trait to the new `Receiver` trait when the unstable `arbitrary_self_types` feature is enabled (the simple bit)
* Introduces new algorithms to spot "shadowing"; that is, the case where a newly-added method in an outer smart pointer might end up overriding a pre-existing method in the pointee (the complex bit). Most of this bit was explored in [this earlier perf-testing PR](https://github.com/rust-lang/rust/pull/127812#issuecomment-2236911900).
* Lots of tests
This should not break compatibility for:
* Stable users, where it should have no effect
* Users of the existing `arbitrary_self_types` feature (because we implement `Receiver` for `T: Deref`) _unless_ those folks have added methods which may shadow methods in inner types, which we no longer want to allow
Subsequent PRs will add better diagnostics.
It's probably easiest to review this commit-by-commit.
r? `@wesleywiser`
In this new version of Arbitrary Self Types, we no longer use the Deref trait
exclusively when working out which self types are valid. Instead, we follow a
chain of Receiver traits. This enables methods to be called on smart pointer
types which fundamentally cannot support Deref (for instance because they are
wrappers for pointers that don't follow Rust's aliasing rules).
This includes:
* Changes to tests appropriately
* New tests for:
* The basics of the feature
* Ensuring lifetime elision works properly
* Generic Receivers
* A copy of the method subst test enhanced with Receiver
This is really the heart of the 'arbitrary self types v2' feature, and
is the most critical commit in the current PR.
Subsequent commits are focused on:
* Detecting "shadowing" problems, where a smart pointer type can hide
methods in the pointee.
* Diagnostics and cleanup.
Naming: in this commit, the "Autoderef" type is modified so that it no
longer solely focuses on the "Deref" trait, but can now consider the
"Receiver" trait instead. Should it be renamed, to something like
"TraitFollower"? This was considered, but rejected, because
* even in the Receiver case, it still considers built-in derefs
* the name Autoderef is short and snappy.
Validate self in host predicates correctly
`assert_only_contains_predicates_from` was added to make sure that we are computing predicates for the correct self type for a given `PredicateFilter`. That was not implemented correctly for `PredicateFilter::SelfOnly` when there are const predicates.
Fixes#133526
Deeply normalize when computing implied outlives bounds
r? lcnr
Unfortunately resolving regions is still slightly scuffed (though in an unrelated way). Specifically, we should be normalizing our param-env outlives when constructing the `OutlivesEnv`; otherwise, these assumptions (dd2837ec5d/compiler/rustc_infer/src/infer/outlives/env.rs (L78)) are not constructed correctly.
Let me know if you want us to track that somewhere.
Get rid of HIR const checker
As far as I can tell, the HIR const checker was implemented in https://github.com/rust-lang/rust/pull/66170 because we were not able to issue useful const error messages in the MIR const checker.
This seems to have changed in the last 5 years, probably due to work like #90532. I've tweaked the diagnostics slightly and think the error messages have gotten *better* in fact.
Thus I think the HIR const checker has reached the end of its usefulness, and we can retire it.
cc `@RalfJung`
Make `compare_impl_item` into a query
Turns `compare_impl_item` into a query (generalizing the existing query for `compare_impl_const`), and uses that in `Instance::resolve` to fail resolution when an implementation is incompatible with the trait it comes from.
Fixes#119701Fixes#121127Fixes#121411Fixes#129075Fixes#129127Fixes#129214Fixes#131294
tests: Add regression test for self referential structs with cow as last field
Making compilation pass for this code was retroactively stabilized via FCP in 1.79. The code does not compile in 1.78.
See https://github.com/rust-lang/rust/issues/129541 for details.
Closes#107481
I was surprised to find that running with `-Zparse-only` only parses the
crate root file. Other files aren't parsed because that happens later
during expansion.
This commit renames the option and updates the help message to make this
clearer.
Rollup of 12 pull requests
Successful merges:
- #129409 (Expand std::os::unix::fs::chown() doc with a warning)
- #133320 (Add release notes for Rust 1.83.0)
- #133368 (Delay a bug when encountering an impl with unconstrained generics in `codegen_select`)
- #133428 (Actually use placeholder regions for trait method late bound regions in `collect_return_position_impl_trait_in_trait_tys`)
- #133512 (Add `as_array` and `as_mut_array` conversion methods to slices.)
- #133519 (Check `xform_ret_ty` for WF in the new solver to improve method winnowing)
- #133520 (Structurally resolve before applying projection in borrowck)
- #133534 (extend group-forbid-always-trumps-cli test)
- #133537 ([rustdoc] Fix new clippy lints)
- #133543 ([AIX] create shim for lgammaf_r)
- #133547 (rustc_span: Replace a `HashMap<_, ()>` with `HashSet`)
- #133550 (print generated doc paths)
r? `@ghost`
`@rustbot` modify labels: rollup
Structurally resolve before applying projection in borrowck
As far as I can tell, all other `.normalize` calls in borrowck are noops and can remain that way. This is the only one that actually requires structurally resolving the type.
r? lcnr
Check `xform_ret_ty` for WF in the new solver to improve method winnowing
This is a bit interesting. Method probing in the old solver is stronger than the new solver because eagerly normalizing types causes us to check their corresponding trait goals. This is important because we don't end up checking all of the where clauses of a method when method probing; just the where clauses of the impl. i.e., for:
```
impl Foo
where
WC1,
{
fn method()
where
WC2,
{}
}
```
We only check WC1 and not WC2. This is because at this point in probing the method is instantiated w/ infer vars, and checking the where clauses in WC2 will lead to cycles if we were to check them (at least that's my understanding; I could investigate changing that in general, incl. in the old solver, but I don't have much confidence that it won't lead to really bad overflows.)
This PR chooses to emulate the old solver by just checking that the return type is WF. This is theoretically stronger, but I'm not too worried about it. I think we alternatively have several approaches we can take here, though this one seems the simplest. Thoughts?
r? lcnr
Delay a bug when encountering an impl with unconstrained generics in `codegen_select`
Despite its name, `codegen_select` is what powers `Instance::try_resolve`, which is used in pre-codegen contexts to try to resolve a method where possible. One place that it's used is in the "recursion MIR lint" that detects recursive MIR bodies.
If we encounter an impl in `codegen_select` that contains unconstrained generic parameters, we expect that impl to caused an error to be reported; however, there's no temporal guarantee that this error is reported *before* we call `codegen_select`. This is what a delayed bug is *for*, and this PR makes us use a delayed bug rather than asserting something about errors already having been emitted.
Fixes #126646
Structurally resolve before matching on type of projection
Another missing structural resolve in closure upvar analysis. I think it's better to place the normalization here rather than trying to guarantee that all types returned by the expr use visitor are structurally normalized, which I don't think we do now. Thoughts?
r? lcnr
do not constrain infer vars in `find_best_leaf_obligation`
This ended up causing an ICE by making the following code path reachable by incorrectly constraining an inference variable while computing the best obligation for a preceding ambiguity. Closes#129444.
f2abf827c1/compiler/rustc_trait_selection/src/solve/fulfill.rs (L312-L314)
I have to be honest, I don't fully understand how that change removes all the additional diagnostics :3
r? `@compiler-errors`
Bail on more errors in dyn ty lowering
If we have more than one principal trait, or if we have a principal trait with errors in it, then bail with `TyKind::Error` rather than attempting lowering. Lowering a dyn trait with more than one principal just arbitrarily chooses the first one and drops the subsequent ones, and lowering a dyn trait path with errors in it is just kinda useless.
This suppresses unnecessary errors which I think is net-good, but also is important to make sure that we don't end up leaking `{type error}` in https://github.com/rust-lang/rust/issues/133388 error messaging :)
r? types
