The signature of a denotation.
Same-named denotations with different signatures are considered to be
overloads, see SingleDenotation#matches for more details.
A method signature (a value of type Signature, excluding NotAMethod
and OverloadedSignature) is composed of a list of parameter signatures,
plus a type signature for the final result type.
A parameter signature (a value of type ParamSig) is either an integer,
representing the number of type parameters in a type parameter section, or
the type signature of a term parameter.
A type signature is the fully qualified name of the type symbol of the type's erasure.
For instance a definition
def f[T, S](x: Int)(y: List[T]): S
would have signature
Signature(
List(2, "scala.Int".toTypeName, "scala.collection.immutable.List".toTypeName),
"java.lang.Object".toTypeName)
Note that paramsSig has one entry for a whole type parameter section but
one entry for each term parameter (currently, methods in Dotty can only
have one type parameter section but this encoding leaves the door open for
supporting multiple sections).
The signatures of non-method types are always NotAMethod.
There are three kinds of "missing" parts of signatures:
- tpnme.EMPTY Result type marker for NotAMethod and OverloadedSignature
- tpnme.WILDCARD Arises from a Wildcard or error type
- tpnme.Uninstantiated Arises from an uninstantiated type variable
- Companion:
- object
Value members
Concrete methods
Does this signature coincide with that signature on their parameter parts? This is the case if all parameter signatures are consistent, i.e. they are either equal or on of them is tpnme.Uninstantiated.
Does this signature coincide with that signature on their parameter parts? This is the case if all parameter signatures are consistent, i.e. they are either equal or on of them is tpnme.Uninstantiated.
A signature is under-defined if its paramsSig part contains at least one
tpnme.Uninstantiated. Under-defined signatures arise when taking a signature
of a type that still contains uninstantiated type variables.
A signature is under-defined if its paramsSig part contains at least one
tpnme.Uninstantiated. Under-defined signatures arise when taking a signature
of a type that still contains uninstantiated type variables.
The degree to which this signature matches that.
If parameter signatures are consistent and result types names match (i.e. they are the same
or one is a wildcard), the result is FullMatch.
If only the parameter signatures are consistent, the result is either
MethodNotAMethodMatch (if one side is a method signature and the other isn't),
or ParamMatch.
If the parameters are inconsistent, the result is always NoMatch.
The degree to which this signature matches that.
If parameter signatures are consistent and result types names match (i.e. they are the same
or one is a wildcard), the result is FullMatch.
If only the parameter signatures are consistent, the result is either
MethodNotAMethodMatch (if one side is a method signature and the other isn't),
or ParamMatch.
If the parameters are inconsistent, the result is always NoMatch.
Construct a signature by prepending the signature names of the given params
to the parameter part of this signature.
Construct a signature by prepending the signature names of the given params
to the parameter part of this signature.
Like Signature#apply, the result is only cacheable if isUnderDefined == false.
Construct a signature by prepending the length of a type parameter section to the parameter part of this signature.
Construct a signature by prepending the length of a type parameter section to the parameter part of this signature.
Like Signature#apply, the result is only cacheable if isUnderDefined == false.