* 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.
expressions such as Type.field are now recognised by the compiler.
This also fixes a bug, preventing the user-defined to check for the presence of
regular fields in addition to procs
This introduces tyStatic and successfully bootstraps and handles
few simple test cases. Static params within macros are no longer
treated as PNimrodNodes - they are now equivalent to constants
of the designated type.
Lines from the original source are outputted as comments next to line directives.
Hopefully, this will make debugging codegen problems easier.
Other changes:
The frame setup code now uses a single-line C macro. My motivation was to reduce
the noise in the generated output and make it easier to step over the boiler-plate
code, but counter-intuitively this also improved the overall compilation speed a
little bit so I applied the same treatment to line tracking too (this reduces the size of
the generated files and the explanation is that probably the I/O overhead dominates
the macro expansion costs).
