Yeet the effects feature, move it onto const_trait_impl

[compiler-errors]

This PR merges the effects feature into the const_trait_impl feature. There's really no need to have two feature gates for one feature.

After this PR, if const_trait_impl is enabled:

• Users can use and define const traits
• HostEffect const conditions will be enforced on the HIR
• We re-check the predicates in MIR just to make sure that we don't "leak" anything during MIR lowering

And if const_trait_impl is not enabled:

• Users cannot use nor define const traits
• HostEffect const conditions are not enforced on the HIR
• We will raise a const validation error if we call a function that has any const conditions (i.e. const traits and functions with any ~const in their where clasues)

This should be the last step for us to be able to enable const traits in the standard library. We still need to re-constify Drop and Destruct and stuff for const traits to be particularly useful for some cases, but this is a good step :D

r? fee1-dead
cc @rust-lang/project-const-traits

[rustbot]

HIR ty lowering was modified

cc @fmease

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[compiler-errors]

Lots of files changed, but most of it is just removing feature(effects) from the ui tests, and renaming FIXME(effects) to FIXME(const_trait_impl) ✨

[fee1-dead]

r=me after nits and rebases that become necessary

The const_closure and some other feature gates remain incomplete, so there are still a few effects tests that still need allow(incomplete_features). I tried to remove the rest though.

@bors r=fee1-dead

📌 Commit 6b96103 has been approved by fee1-dead

It is now in the queue for this repository.

⌛ Testing commit 6b96103 with merge b8c8287...

☀️ Test successful - checks-actions
Approved by: fee1-dead
Pushing b8c8287 to master...

Finished benchmarking commit (b8c8287): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

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

Max RSS (memory usage)

Results (primary 1.8%, secondary 4.5%)

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.8%	[1.8%, 1.8%]	1
Regressions ❌ (secondary)	4.5%	[4.5%, 4.5%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.8%	[1.8%, 1.8%]	1

Cycles

Results (primary 3.7%)

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)	3.7%	[3.7%, 3.7%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	3.7%	[3.7%, 3.7%]	1

Binary size

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

Bootstrap: 780.261s -> 780.466s (0.03%)
Artifact size: 335.33 MiB -> 335.33 MiB (0.00%)

This should be the last step for us to be able to enable const traits in the standard library.

Do we have checks ensuring that const trait fns cannot be called from stable const fns? I don't think so (just some leftovers in check.rs you said you were not happy with, and I don't know if we can trust them).

IMO that is a blocker for enabling the feature in the standard library.

The effects feature name still appears a few lines down in this file

rust/compiler/rustc_const_eval/src/check_consts/check.rs

Lines 680 to 684 in 6b96103

	Some(if tcx.features().const_trait_impl() {
	sym::effects
	} else {
	sym::const_trait_impl
	})

Do we have checks ensuring that const trait fns cannot be called from stable const fns? I don't think so (just some leftovers in check.rs you said you were not happy with, and I don't know if we can trust them).

So specifically, I am concerned about this line

rust/compiler/rustc_const_eval/src/check_consts/check.rs

Line 662 in 6b96103

if tcx.features().const_trait_impl() && trait_is_const {

This does not take into account whether the current function must be recursively const-stable.

So I think what the logic here should be more like

if let Some(trait_did) = tcx.trait_of_item(callee) {
  if !trait_is_const {
    // Trigger `ops::FnCallNonConst`.
    // ...
    return;
  }

  // Ensure we have `const_trait_impl` and are allowed to use it in this function.
  self.check_op(ops::ConstTraitCall);

  // We don't know which function is being called here, so we can't run the checks below.
  // FIXME: apply more fine-grained per-trait const stability checks
  // (see https://github.com/rust-lang/project-const-traits/issues/5).
  return;
}

Also it seems a bit odd that const_trait_impl guards calling const trait functions. Maybe const_trait would make more sense as the name for this feature?

Do we have checks ensuring that const trait fns cannot be called from stable const fns? I don't think so (just some leftovers in check.rs you said you were not happy with, and I don't know if we can trust them).

noting here for completeness, that was done in #132823.