skip known panics lint for impossible items

[lukas-code]

fixes #123134

For items with impossible predicates like [u8]: Sized it's possible to have locals that are "Sized", but cannot be const-propped in any meaningful way. To avoid this issue, we can just skip the known panics lint for items that have impossible predicates.

[rustbot]

r? @TaKO8Ki

rustbot has assigned @TaKO8Ki.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[oli-obk]

@bors try @rust-timer queue

[bors]

⌛ Trying commit 7b46e02 with merge 76192f0...

[compiler-errors]

This is kind of strange. Can you just use elaborate(tcx.predicates_of().instantiate_identity).filter(|clause| !clause.has_param()).collect()?

It shouldn't matter to eagerly fold opaques -- we're already processing impossible_predicates with a reveal_all param-env.

[lukas-code]

That doesn't work, because it would filter out local predicates like T::Assoc: Sized, even if they normalize to global predicates like [u8]: Sized, which is exactly the case here:

impl<T> Adapter for T
{
    type A = ApiS;
    fn open() -> OpenDevice<Self::A>
    where
        <Self::A as Api>::Device: Sized,
      // ^^^^ This `Self` is an alias for the type parameter `T`
      // The `predicates_of` has the "local" predicate `<T::A as Api>::Device: Sized`,
      // but the `param_env` (with or without reveal all) has the "global" predicate `[u8]: Sized`
    {
        unreachable!()
    }
}

So, we need to normalize the predicates_of before filtering out !clause.has_param(). And the the normalized + elaborated predicates_of is exactly the param_env. I'm using param_env_reveal_all_normalized instead of param_env here as an optimization, exactly because impossible_predicates will normalize in the empty reveal-all env anyway.

[compiler-errors]

Okay. Still feels a bit hacky that you're using param_env.caller_bounds() as a substitute for, e.g. normalize_erasing_regions-ing the elaborated caller bounds or something. This should at least be documented.

I'm using param_env_reveal_all_normalized instead of param_env here as an optimization, exactly because impossible_predicates will normalize in the empty reveal-all env anyway.

I don't think this is a particularly compelling optimization, especially because the param_env query has definitely been fetched for all items we care about, and the likelihood of having an opaque in a where clause anyways is very small. I'd prefer if we write the code more explicitly unless it's proven to be hot, which I doubt is the case for this code, since it's gonna be only running once per item.

[lukas-code]

Still feels a bit hacky that you're using param_env.caller_bounds() as a substitute for, e.g. normalize_erasing_regions-ing the elaborated caller bounds or something.

Do you mean normalize_erasing_regions-ing the elaborated predicates_of?

[compiler-errors]

ya typo

[lukas-code]

Ok so normalizing the predicates individually doesn't work, because sometimes we have two predicates like <T as Foo>::Assoc: Bar and <T as Foo>::Assoc == SomeType so that one predicate can only be normalized if the other predicate is in the param env. That's why the implementation of param_env does that whole normalizing the param env in itself thing. This also means that my implementation here will stop working once we stop eagerly normalizing the param env.

Also one UI test will overflow if we normalize the predicates individually.

[lukas-code]

Alright I found a way that seems to work: We can just normalize the predicates_of individually inside the param_env of the item.

[bors]

☀️ Try build successful - checks-actions
Build commit: 76192f0 (76192f036189e2ee162445ee163df829c3c2d3c4)

[compiler-errors]

Unrelated to the above discussion, but I'm somewhat worried that this is a spot-fix for a more general class of issues where we're calling layout_of on types in param-envs that have trivially impossible preds throughout the later stages of the compiler.

I wonder if it's better to just fix this in the layout code, e.g. only asserting these validity requirements if we're totally monomorphic, like if param_env == ty::ParamEnv::reveal_all(), and otherwise returning a LayoutError instead.

[rust-timer]

Finished benchmarking commit (76192f0): comparison URL.

Overall result: ❌ regressions - ACTION NEEDED

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.6%	[0.2%, 1.1%]	13
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	7.3%	[5.7%, 10.4%]	3
Improvements ✅ (primary)	-1.5%	[-1.9%, -1.0%]	14
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-1.5%	[-1.9%, -1.0%]	14

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	1.5%	[0.4%, 2.6%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.5%	[-0.5%, -0.5%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.8%	[-0.5%, 2.6%]	3

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 669.029s -> 668.895s (-0.02%)
Artifact size: 315.66 MiB -> 315.66 MiB (-0.00%)

[lukas-code]

Alright, looks like this will definitely still ICE for other MIR passes, so this PR is clearly not the solution and I'll go ahead and close it as such. Removing the delayed bug from the layout computation ( #123169 (comment) ) is probably a better approach.

code for GVN ICE

//@ build-pass

trait Api: Sized {
    type Device: ?Sized;
}

struct OpenDevice<A: Api>
where
    A::Device: Sized,
{
    device: A::Device,
    queue: (),
}

trait Adapter {
    type A: Api;

    fn open() -> usize
    where
        <Self::A as Api>::Device: Sized;
}

struct ApiS;

impl Api for ApiS {
    type Device = [u8];
}

impl<T> Adapter for T
{
    type A = ApiS;

    fn open() -> usize
    where
        <Self::A as Api>::Device: Sized,
    {
        1 + std::mem::size_of::<OpenDevice<Self::A>>()
    }
}

fn main() {}