The signature of a denotation. Overloaded denotations with the same name are distinguished by their signatures. A signature of a method (of type PolyType,MethodType, or ExprType) is composed of a list of signature names, one for each parameter type, plus a signature for the result type. Methods are uncurried before taking their signatures. The signature name of a type is the fully qualified name of the type symbol of the type's erasure.
For instance a definition
def f(x: Int)(y: List[String]): String
would have signature
Signature( List("scala.Int".toTypeName, "scala.collection.immutable.List".toTypeName), "scala.String".toTypeName)
The signatures of non-method types are always
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
Does this signature potentially clash with
Two names are consistent if they are the same or one of them is tpnme.Uninstantiated
Does this signature coincide with that signature on their parameter parts? This is the case if all parameter names 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.
name.toString == "" or name.toString == "_"
The degree to which this signature matches
If parameter names are consistent and result types names match (i.e. they are the same
or one is a wildcard), the result is
If only the parameter names are consistent, the result is
ParamMatch before erasure and
If the parameters are inconsistent, the result is always
Construct a signature by prepending the signature names of the given
to the parameter part of this signature.
Like Signature#apply, the result is only cacheable if
isUnderDefined == false.