Currently, devel docs (https://nim-lang.github.io/Nim/lib.html)
source links point to master branch,
leading to outdated source code and showing the wrong line.
This allows spaces in imports, by using the following syntax:
* `import "directory with spaces" / subdir / file`, or
* `import "directory with spaces/subdir/file"`
* kochdocs.nim: code cleanup
* docgen: nicer indentation
* parser.nim: code cleanup
* fixes#10458
* make tests green again
* make =destroy mixins
* gc:destructors: produced C code is almost working
* --gc:destructors simple program compiles (but leaks memory)
* gc:destructors make examples compile in C++ mode
* destructors: string implementation bugfixes
* strs.nim: minor code cleanup
* destructors: builtin seqs are beginning to work
* remove debugging helpers
The old logic wasn't very useful because
`relPath` is almost always shorter than `absPath`,
e.g. `../../../../../` is shorter than `C:\Program Files`.
This way allows the usage of a relative path for
at most two levels deep, e.g. `../../relPath`,
otherwise the absolute path is used.
* 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
* fix#10339 by checking for nkObjConstr
* revert check for nkObjConstr, return type from nkEmpty node
The correct type needed in `semObjConstr` to fix#10339 is indeed
available, but attached to an `nkEmpty` node. These were previously
discarded in `semTypeNode`, which is used to extract the type for the
object.
* simplify return of PType from `nkEmpty`
* also fixes#9866, add test case
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]()
^
Hopefully the type-check phase already rejected all the invalid
conversions by the time we execute the VM bytecode.
Problem reported by chrisheller on the Nim Forum
