Polymorphization: Look at called functions for usedness of generic params

[Nilstrieb]

When determining whether a generic param is unused, we consider it unused even if it's used as a subst to a function const as long as it's not used within this function.

For example

fn unused<T>() {}
fn caller<T>() { unused::<T>() }

caller's T is considered unused now.

This causes a query cycle with recursive functions. I couldn't think of an easy way to avoid the cycle, so I just added non-fatal cycles to the query system. I don't know whether that's a good idea or a terrible abomination, cc @cjgillot on that.

It worked for a few quick tests but this needs some very careful review to make sure that we don't accidentally consider too many things as unused, which would be very bad.

[rustbot]

r? @compiler-errors

(rustbot has picked a reviewer for you, use r? to override)

[rustbot]

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

[cjgillot]

This causes a query cycle with recursive functions. I couldn't think of an easy way to avoid the cycle, so I just added non-fatal cycles to the query system. I don't know whether that's a good idea or a terrible abomination, cc @cjgillot on that.

The query system is not structured to allow such cycles. This is bound to cause ICEs.
Consider the following code:

fn foo<T, U>() { bar::<T>() }
fn bar<T>() { foo::<u8, T>() }

If we start by computing foo, we will have the following execution:

• unused_generic_params(foo) calls unused_generic_params(bar).
• • unused_generic_params(bar) calls unused_generic_params(foo) -> cycle.
• • • unused_generic_params(foo) cycle recovery returns [T: false, U: false].
• • unused_generic_params(bar) returns [T: false].
• unused_generic_params(foo) returns [T: false, U: true].

If we start by computing bar, we will have the following execution:

• unused_generic_params(bar) calls unused_generic_params(foo).
• • unused_generic_params(foo) calls unused_generic_params(bar) -> cycle.
• • • unused_generic_params(bar) cycle recovery returns [T: false].
• • unused_generic_params(foo) returns [T: false, U: true].
• unused_generic_params(bar) returns [T: true] --> different from previous execution.

So we have the query's value change depending on the order of query computation. This is unrelated to the contents of foo or bar, but may only depend on whether main calls foo or bar first. In this case, we'd have an "unstable fingerprint" ICE.

[Nilstrieb]

yeah that's what i thought and why i set it back to S-waiting-on-author, i need to find something better

[Nilstrieb]

this needs a bunch of work if i continue working on this (which im not intending to do right now), so i'm closing this for now