Get rid of is_min_const_fn

[RalfJung]

This removes the last trace of the min_const_fn mechanism by making the unsafety checker agnostic about whether something is a min or "non-min" const fn. It seems this distinction was used to disallow some features inside const fn, but that is the responsibility of the const checker, not of the unsafety checker. No test seems to even notice this change in the unsafety checker so I guess we are good...

r? @oli-obk
Cc #84510

[RalfJung]

Some checks used ::General before (and thus would have lead to an error in min_const_fn):

• inline assembly:

  rust/compiler/rustc_mir/src/transform/check_unsafety.rs

  Line 98 in 13a2615

  UnsafetyViolationKind::General,

• other inline assembly:

  rust/compiler/rustc_mir/src/transform/check_unsafety.rs

  Line 121 in 13a2615

  UnsafetyViolationKind::General,

• Ptr-to-int cast:

  rust/compiler/rustc_mir/src/transform/check_unsafety.rs

  Line 160 in 13a2615

  UnsafetyViolationKind::General,

• Static accesses
  

  rust/compiler/rustc_mir/src/transform/check_unsafety.rs

  Line 196 in 13a2615

  UnsafetyViolationKind::General,

  
  

  rust/compiler/rustc_mir/src/transform/check_unsafety.rs

  Line 202 in 13a2615

  UnsafetyViolationKind::General,

Those should all be rejected by our regular const checks, right?

[oli-obk]

Those should all be rejected by our regular const checks, right?

Yea, we already have feature gates for them, that is independent

[oli-obk]

Can you double check that we still make some things unsafe in const fn that are safe in regular fns? (Like pointer comparisons)

[RalfJung]

(Like pointer comparisons)

I don't think pointer comaprisons were ever unsafe? They should just be forbidden.
Ptr-to-int casts are unsafe. I extended the corresponding test in the last commit.

[RalfJung]

Raw ptr comparison is checked here

rust/compiler/rustc_mir/src/transform/check_consts/validation.rs

Line 704 in 46d09f7

self.check_op(ops::RawPtrComparison);

There is no feature gate for RawPtrComparison, it is just always forbidden... is it deliberate that ops are used both for "must never be allowed" and "is currently unstable"?

[oli-obk]

is it deliberate that ops are used both for "must never be allowed" and "is currently unstable"?

Yes, otherwise unleash can't know what checks it can skip

[oli-obk]

r=me with ci passing

[RalfJung]

I am not sure if unleashing should allow raw ptr comparisons... but yeah makes sense.

[RalfJung]

r=me with ci passing

@bors r=oli-obk

[bors]

📌 Commit 421d54e has been approved by oli-obk

[RalfJung]

@bors r=oli-obk

[bors]

📌 Commit 588530d has been approved by oli-obk

[oli-obk]

I am not sure if unleashing should allow raw ptr comparisons... but yeah makes sense.

We should skip the static check on raw pointer comparisons in unleash mode in order to demonstrate the interpretation time behaviour if there are actual relocations involved