This resulted in a codegen error in C++ mode, because the generic
types were not defined in modules where calls requiring downcasts
were used (generating a downcast forces the inclusion of the full
definition of the involved types).
* fix the usage of unresolved static[T] parameters in proc signatures
* fix tsametype and tmacrogenerics
* Allow creating composite type classes with concepts and using them in type signatures
* Allow integers to be used in ident concatenations
* Support using imported C++ generic types in proc signatures
* fixes#7230
* closes#7379
* re-enable some metatype tests
Fixed the dot operator when used within return types (see tgenericdotrettype)
Fixed the matching of generic concepts aliases used with the implicit generics style
* Why is tyInferred needed?
The bindings in TCandidate are capable of inferring types within a single
call expression. In concepts, we need to infer types in the same way, but
across the whole body of the concept.
Previously, once a concept type param was inferred, it was destructively
mutated using t.assignType, but this proved to be problematic in the presence
of overloads, because the bindings established while a non-matching overload
is tested must be reverted/forgotten. tyInferred offers a non-destructive way to
keep track of the inference progress.
While introducing new types usually requires a lot of code paths in the compiler
to updated, currently tyInferred is only a short-lived type within the concept body
pass and it's unlikely to introduce breakage elsewhere in the compiler.
This commit returns to a bit less strict checking of the number
of macro arguments, because some old immediate macros rely on a
behavior where even the arity of the macro is not being checked.
It may be better if such macros are just declared to use varargs[expr],
but this remains for another day.
