Previously trying to convert constant of enum type, where this enum type has no
entry with given constant position leaded to "internal error: opConv for enum".
Instead of producing error, now we gracefully convert it to "EnumType position".
Since immediate templates are not subjected to the standard sigmatching
algorithm, they will have a number of deficiencies when it comes to generic
params: Type dependencies between the parameters won't be honoured
and the bound generic symbols won't be resolvable within their bodies.
We could try to fix this, but it may be wiser to just deprecate immediate
templates and macros now that we have working untyped parameters.
Disabling the new features is admittedly not the greatest way to handle
this situations as it introduces inconsistency in the language, but at least
it makes the code backwards-compatible with the previous version of the
compiler instead of triggering more serious problems.
Previously introduced node comparison `==` was working somehow wrong on nodes
returned from getType(a), comparing just ids of the symbols.
Recently introduced `==` change 47dce26886
started comparing symbol nodes pointer-wise, thus strictly. Since getType(a)
always creates new symbol pointing to the type, comparing two such nodes using
`==` always returns false, even they point to the same type.
That is why we need a new sameType macro to be able to tell if these nodes
point to the same type.
Implementation notes:
Just after overload resolution, the resolved generic params will be added to the
call expression to be later processed in evalTemplate and evalMacroCall. These
procs have been modified to handle the increased number of parameters, but one
remaining issue is that immediate templates and macros don't go through the same
process. The next commit will outlaw the use of generic parameters with such macros.
