Disallow private opaque type aliases

[odersky]

Fixes #14660

[prolativ]

Opaque types whose usage is limited to the scope where they are defined (and where they are not seen as opaque) indeed seem to make no sense so they can be disabled. But I think it makes sense to allow scoped private access like this

trait Foo:
  class Bar:
    private[Foo] opaque type Baz = Int
    
  def foo: Bar#Baz

Even when the current changes from this PR are applied the code snippet above crashes the compiler. Instead this should compile successfully.
Not sure about the situation when we make it private[Bar]. This seems equivalent to private without a scope modifier.

[adampauls]

Sorry for butting in, why do private opaque types make no sense? Suppose I have a private method checkFoo(foo: Foo): CheckedFoo that checks an invariant and I want the compiler to make sure I never accidentally pass an unchecked Foo into a method expecting a CheckedFoo. Doesn't it seem reasonable to use an opaque type for this case? And if Foo itself private, won't trying to make a public type alias fail to compile because it leaks info about Foo?

[odersky]

@adampauls The idea is that private opaque gives you nothing extra over what private gives you.

[adampauls]

It does remove the compiler's ability to type check for you right? private def acceptsFoo(foo: CheckedFoo) will compile if I pass a regular Foo to it?

[odersky]

@adampauls That's true whether Foo is opaque or not.

[odersky]

We also needed to fix a problem when merging denotations with hidden symbols

The hidden test is unreliable after typer, since we cannot guarantee that the
current owner is accurate. This addresses the pos test.

[odersky]

In fact, to fix #14660, only the last commit is necessary. Forbidding private opaque combinations is optional. But I think it makes sense to do so, since opaque is redundant for private aliases.

[adampauls]

Thanks, sorry I did not carefully RTFM. I had thought from a first read that the scope of transparency was the companion object of the type alias. If I want to make the equivalent of a private opaque type CheckedFoo = Foo, I can do

private object CheckedFooScope {
   opaque type CheckedFoo = Foo
   object CheckedFoo {
     def apply(foo: Foo): CheckedFoo = foo
   }
}
import CheckedFooScope.CheckedFoo

[prolativ]

I think we should point out that private[OuterScope] is allowed however.
Another thing that might not be very clear here is that one can define an abstract type and then override (or implement) it with an opaque type

[odersky]

I think that could be elsewhere, maybe in a tutorial. The doc here is a spec and conciseness is good. If we say however it can be private[X] the we'd have to go to all other places where we say private and include or exclude private X.

[prolativ]

If it's consistent across the docs that private[Scope] is not private then it's OK