this discard any implicit conversion on iterator return value.
the previous behaviour was to return a reference to a converted copy and
thus not modifying the original value.
* restrict casting for closure.
This commit forbid casting a closure to anything other than another
closure. use rawEnv/rawProc to access underlaying pointers.
* better error message for closure cast
* fixes#5742
A more efficient implementation is possible by restoring the old
lifting ot tyGenericInvocation to tyGenericInst in liftTypeParam,
but this fix will suffice for now.
fixes#5087fixes#5602fixes#5641fixes#5570
This implements a number of new safety checks and error messages
when object constructors are used:
In case objects:
* the compiler will prevent you from initializing fields in
conflicting branches
* When a field from a particular branch is initialized, the
compiler will demand that the discriminator field is also
supplied with a maching compile-time value
In all objects:
* When the "requiresInit" pragma is applied to a type, all fields
of the type must be initialized when object construction is used.
The code will be simplified in a follow up commit.
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.
