* compiler/sem*: better lineinfo for templates
Lineinfo for templates is inconsistant across the compiler, for example:
doAssert true
^ ^
a[int](10)
^^ ^
The `^` marks where the compiler thinks the template starts.
For qualified call, we got the same situation with `proc`s before #10427:
system.once
^
Generics lineinfo within template declaration is also incorrect, for
example, this is where the compiler believes the `T` in `[T]` is:
template a[T](b: T)
^
This PR addresses all of these problems.
* nimsuggest: add tests for template highlighting
Previously the compiler will believe these are where `newSeq` symbol
starts:
newSeq[int]()
^
system.newSeq[int]()
^
This commit moves them back to:
newSeq[int]()
^
system.newSeq[int]()
^
* Fix result not being able to use in quote do
This fixes the annoying issue of not be able to use result inside a
quote do block. It works by a simple trick. The quote do mechanic is
based on dynamically creating a template and immediately calling it with
the arguments found within the quote do block. Since this is called in
the scope of the macro the result variable is shadowed. This trick works
by changing all occurences of result (which shouldn't cause any issues
as result isn't used for anything else for the same reason) to another
name and then passing in an IdentNode with result as a named parameter
with that name.
Note that currently this just replaces it with a fixed named variable
"res" which should be changed to a non-colliding, dynamically created
name.
* Fix hard coded parameter "res" to anonymous symbol
This fixes the hard coded parameter "res" to be an anonymous symbol
instead so it won't collide with other parts of the argument list.
* Add test case for result in quote do block
A simple test case based on GitHub issue #7323 on how you can't put
result in a quote do block. This test verifies that it actually works
correctly now.
* Add test for explicit capturing of result
* Rebased against devel
* Early evaluation of mIs
The `evalIs` implementation was just a broken copy of `isOpImpl` so
let's just avoid it alltogether: `mIs` nodes are either resolved during
the semantic phase or bust.
* Remove dead code and tidy it up
* Don't consider tyAnd/tyNot/tyOr/tyAnything as generic
`containsGenericType` was too shallow and didn't check all the branches.
The resulting half-processed nodes are often simplified by the constant
folding pass but when that's not possible we get a nasty error during
codegen.
Fixes#8693
* Move the blame onto the semFold pass
Slightly better evaluation of `is` forms.
