Tait must be constrained if in sig

[oli-obk]

r? @compiler-errors

kind of reverts #62423, but that PR only removed cycles in cases that we want to forbid now anyway.

see https://rust-lang.zulipchat.com/#narrow/stream/315482-t-compiler.2Fetc.2Fopaque-types/topic/lcnr.20oli.20meeting/near/370712246 for related discussion and motivating example

a TAIT showing up in a signature doesn't just mean it can register a hidden type, but that it must.

This is the design the types team decided upon for the following reasons

• avoids a hypothetical situation where getting smarter in trait solving could cause new cycle errors or new inference errors to show up, where today something is treated as opaque.
• avoids having the situation where a (minor?) change to a function body causes an error, because its TAIT usage suddenly isn't "opaque enough" anymore.
• avoids having to explain why in some cases you need to put a Tait into a tiny module together with its defining usages. Now you basically gotta always do this, the moment a Tait is in a signature that isn't in the defining scope.
• avoids false-cycle errors
• anything diverging from this pattern needs to either
  • move the TAIT declaration and defining function into their own helper sub module
  • use the attributes we'll provide in the future to explicitly opt in or out of being in the defining scope

[rustbot]

rustc_error_messages was changed

cc @davidtwco, @compiler-errors, @JohnTitor, @TaKO8Ki

[oli-obk]

This is the only test for which there was no workaround after this change.

[bors]

☔ The latest upstream changes (presumably #113370) made this pull request unmergeable. Please resolve the merge conflicts.

[oli-obk]

This PR "reopens" #61863

the test doesn't really add too much new test coverage compared with other tests we already have.

[bors]

☔ The latest upstream changes (presumably #117076) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔ The latest upstream changes (presumably #117172) made this pull request unmergeable. Please resolve the merge conflicts.

[rustbot]

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

[oli-obk]

@rustbot ready

[compiler-errors]

I need to take another look at this, but blocking until it's been approved from the T-lang side.

@rustbot blocked

[bors]

☔ The latest upstream changes (presumably #117278) made this pull request unmergeable. Please resolve the merge conflicts.

[oli-obk]

Nominating for lang team discussion. The explanation is entirely in the main post of this PR.

The question we want T-lang to answer is:

Is it ok from your side that we disallow

type Tait = impl Sized;
fn foo(x: Tait) -> Tait { x } // not allowed, because not defining in defining scope
fn bar() -> Tait { }

but allow the same code if the foo function is removed (or moved to a parent or sibling module)

[traviscross]

This is also nominated as #117861. Also see #117865.

[traviscross]

@rustbot labels -I-lang-nominated

Let's unnominate this in favor of #117861 which gets at the same question.

[Dylan-DPC]

@oli-obk what's the status of this? it was blocked as it was nominated but then unnominated for a different pr, so i'm assuming that it is either superseded or blocked by it