Does this signature coincide with that signature on their parameter parts? This is the case if all parameter names are _consistent_, i.e.
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
.
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. They are eliminated
by fixSignature
in PostTyper
.
The degree to which this signature matches that
.
The degree to which this signature matches that
.
If parameter names 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 names are consistent, the result is ParamMatch
before erasure and
NoMatch
otherwise.
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.
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
NotAMethod
.There are three kinds of "missing" parts of signatures: