CCState

dotty.tools.dotc.cc.CCState
See theCCState companion object
class CCState

Capture checking state, which is known to other capture checking components

Attributes

Companion
object
Graph
Supertypes
class Object
trait Matchable
class Any

Members list

Type members

Classlikes

Attributes

Supertypes
class Closed
class VarState
class Object
trait Matchable
class Any
Show all
Self type
object HardSeparate extends Separating

Attributes

Supertypes
class Separating
class Closed
class VarState
class Object
trait Matchable
class Any
Show all
Self type
object Separate extends Separating

Attributes

Supertypes
class Separating
class Closed
class VarState
class Object
trait Matchable
class Any
Show all
Self type
Separate.type
object Unrecorded extends Unrecorded

Attributes

Supertypes
class Unrecorded
class VarState
class Object
trait Matchable
class Any
Self type
Unrecorded.type

Value members

Concrete methods

def addNote(note: ErrorNote): Unit
def currentLevel(using Context): Level

The level of the current environment. Levels start at 0 and increase for each nested function or class. -1 means the level is undefined.

The level of the current environment. Levels start at 0 and increase for each nested function or class. -1 means the level is undefined.

Attributes

inline def inNestedLevel[T](inline op: T)(using Context): T

Perform op in the next inner level

Perform op in the next inner level

Attributes

inline def inNestedLevelUnless[T](inline p: Boolean)(inline op: T)(using Context): T

Perform op in the next inner level unless p holds.

Perform op in the next inner level unless p holds.

Attributes

When mapping a capture set with a BiTypeMap, should we create a BiMapped set so that future elements can also be mapped, and elements added to the BiMapped are back-propagated? Turned off when creating capture set variables for the first time, since we then do not want to change the binder to the original type without capture sets when back propagating. Error case where this shows: pos-customargs/captures/lists.scala, method m2c.

When mapping a capture set with a BiTypeMap, should we create a BiMapped set so that future elements can also be mapped, and elements added to the BiMapped are back-propagated? Turned off when creating capture set variables for the first time, since we then do not want to change the binder to the original type without capture sets when back propagating. Error case where this shows: pos-customargs/captures/lists.scala, method m2c.

Attributes

def nextIteration[T](op: => T): T
def recordLevel(sym: Symbol)(using Context): Unit
def symLevel(sym: Symbol): Level
inline def withoutMappedFutureElems[T](op: => T)(using Context): T

Don't map future elements in this op

Don't map future elements in this op

Attributes

Concrete fields

Warnings relating to upper approximations of capture sets with existentially bound variables.

Warnings relating to upper approximations of capture sets with existentially bound variables.

Attributes

Error reprting notes produces since the last call to test

Error reprting notes produces since the last call to test

Attributes

var rootId: Int

Next root id

Next root id

Attributes

var varId: Int

Next CaptureSet.Var id

Next CaptureSet.Var id

Attributes