Encountered in realistic scenario. Didn't really look at this one. AI one shot it lol When a module defines method-bearing types and a when isMainModule block imports additional modules that also define methods on the same type hierarchy, sortVTableDispatchers crashes with: Error: unhandled exception: key not found: (module: N, item: M) [KeyError] Root cause: the itemTable built during vtable sorting is populated from g.objectTree[baseType], which only contains types from the current compilation pass. When when isMainModule triggers re-import of method-bearing modules, the method bucket contains types from both passes. Types from the first pass have ItemIds not present in the second pass's object tree, so itemTable[obj.itemId] raises KeyError at line 155. Fix: if obj.itemId is missing from itemTable, create an empty slot array of the correct length. The entry is a local temporary — the second loop in sortVTableDispatchers only calls setMethodsPerType for types in the current object tree, so types from the prior pass retain their already-established dispatch. The entry exists solely to prevent the KeyError during the assignment loop. The methodIndexLen used for the new entry is the bucket's slot count, which is correct for any type in the hierarchy. Added test tests/method/tvtable_reentry.nim that defines methods across three types in two compilation passes and verifies dispatch correctness for all three.
This directory contains the test cases.
Each test must have a filename of the form: t*.nim
Note: Testament is only aware of tests under a directory (eg tests/foo/) and will ignore
top-level tests like tests/tbar.nim.
Specs
Each test can contain a spec in a discard """ ... """ block.
Check out the parseSpec procedure in the specs module for a full and reliable reference
action
Specifies what action this test should take.
Default: run
Options:
compile- compiles the module and fails the test if compilations fails.run- compiles and runs the module, fails the test if compilation or execution of test code fails.reject- compiles the module and fails the test if compilation succeeds.
There are certain spec keys that imply run, including output and
outputsub.
Categories
Each folder under this directory represents a test category, which can be
tested by running koch tests pcat <category> (or cat to avoid parallel
testing, which is slower).
The folder dll contains simple DLL tests.
The folder realtimeGC contains a test for validating that the realtime GC
can run properly without linking against the nimrtl.dll/so.