move tests under the compiler directory to testament

[ringabout]

tbtrees.nim:

• BTree.entries is not exported, so I choose len instead.
• Change some echo statements.

tnimblecmd.nim:

• I use inlcude because some procs are not exported.
• Original tests can't pass CI, so I change @["irc-#head", "another-0.1", "ab-0.1.3", "justone-1.0"] to @["irc-#head", "ab-0.1.3", "justone-1.0", "another-0.1"]

tprefixmatches.nim:

• Change echo to doAssert

[ringabout]

I think some when isMainModule cases are not tested by CI which is very bad.

[Araq]

I'm not sure the changes to parser.nim preserve the old semantics. We do nim c -r compiler/parser.nim to update the gammar that we extract from the parser.

[ringabout]

I don't move the codes generate grammar files(and add a flag not to test it). I only move the codes check grammar.

The change:

[Araq]

I don't move the codes generate grammar files(and add a flag not to test it). I only move the codes check grammar.

Yeah but the old way was better, change the grammar and get a basic check for free.

[ringabout]

parser changes are removed.

[Araq]

Merging it for now but I'm not convinced it's that a good idea. These tests now run on every commit but should only run when we change the related logic.

[ringabout]

Yea, I agree.
only run when we change the related logic >(better than) These tests now run on every commit > not tested at all.

Before if using when isMainModule, only two places will be tested. Compiler/ is omitted.

  of "lib":
    testStdlib(r, "lib/pure/", options, cat)
    testStdlib(r, "lib/packages/docutils/", options, cat)

[timotheecour]

this PR is a net improvement; those tests were never run before PR because of current testament logic, and even if testament would've been modified to run those, it's better to run them as separate module rather than isMainModule block for reasons already discussed.

only run when we change the related logic

this is always going to be brittle because of dependencies, a seemingly unrelated change in some dependency can break code. Unless there's a benchmark showing CI runtime is significantly impacted (which i doubt), it's best to just run those on each commit. In fact moving tests to separate files instead of isMainModule reduces test time because they can be joined via megatest.

[timotheecour]

@xflywind instead of include how about, in a followup PR:

import compiler/[nimblecmd,options,lineinfos]
import std/[strtabs,sequtils]

# in nimblecmd.nim:
when defined(testing):
  export chosen, addPackage

(seems to work when i checked)

note that {.privateImport.} (#11865) would be much better (no global effect on other modules) but until it's merged the above snippet is still the better option, compared to include, which has many issues (as explained in #11865, in particular when a module will end up being duplicated)

[ringabout]

I will check it.

[Araq]

The only reason why .privateImport doesn't have "many issues" is because almost nobody used it.

[timotheecour]

The only reason why .privateImport doesn't have "many issues" is because almost nobody used it.

@Araq the reason nobody used it except myself is because the PR still hasn't been merged.
I've rebased it recently to address bitrot conflicts with devel so it should still be good to go / ready to address any further review comments.

besides having extensive tests in the PR, the safeguards are in place:
not only you can do --experimental:allowPrivateImport, but it can also be pushed/popped for more targetted use:

# in tnimblecmd
{.push experimental: "allowPrivateImport".}
from nimblecmd {.privateImport.} import chosen, addPackage
...
{.pop.}

=> other modules importing nimblecmd won't see chosen, addPackage, and nimblecmd won't be
duplicated, breaking modularity and other common issues with include