You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Special handling of experimental.captureChecking import (#17427)
The question is, how do we introduce capture checking safely. There are
two conflicting requirements:
- Capture checking should not leak into standard Scala. It should be
meaningful only in code that has capture checking explicitly enabled.
- We need to be able to build up libraries that express capture
information
and that can be consumed from other code. This needs to start with
the standard library itself.
So far, everything related to capture checking was marked experimental.
This means
all code that refers to a capture checking abstraction in any way
whatsoever needs
to be declared experimental. That clearly does not work for the new use
cases.
But fortunately, capture checking has some properties that enable a
different scheme.
Specifically, a file compiled under capture checking looks like a
completely normal
component (both Tasty and binary) to any other file that uses it and
that is not compiled
with captureChecking. Only when the consumer is also compiled with
capture checking,
the capturing types of the original file will be revealed. The same
holds for binaries.
Capture checking has no effect at all on the binaries that get generated
and all types
and annotations needed for capture checking are erased.
This allows the following more flexible scheme:
- We can turn capture checking on with a setting or language import in
any source file.
The sources do not have to be @experimental.
- If capture checking is turned on, a number of annotations and other
symbols that
are needed for capture checking and are normally experimental are also
made available.
The important property is that capture checking in one component cannot
poison other normal components. Like
@experimental itself, the whole scheme is transitive.
With the new scheme we do not need a special exemption for the dotty
package anymore, so the code
implementing the exception is dropped.
i"The type $tp - ${tp.toString} of class ${tp.getClass} of tree $tree : ${tree.tpe} / ${tree.getClass} is illegal after erasure, phase = ${ctx.phase.prev}")
i"The type $tp - ${tp.toString} of class ${tp.getClass} of tree $tree : ${tree.tpe} / ${tree.getClass} is illegal after erasure, phase = ${ctx.phase.prev}")
0 commit comments