fixes #25312 Tuple expressions `(a, b, c)` can be either types or values depending on if their elements are typedescs or values, this is checked by checking if the type of the element is `tyTypeDesc`. However when an `skGenericParam` symbol is semchecked by `semSym` it is given its own `tyGenericParam` type rather than a `tyTypeDesc` type, this seems to be necessary for signatures to allow wildcard generic params passed to static constrained generic params (tested in #25315). The reason `semSym` is called is that `semGeneric` for generic invocations calls `matches` which sems its arguments like normal expressions. To deal with this, an expression of type `tyGenericParam` and with a `skGenericParam` sym is allowed as a type in the tuple expression. A problem is that this might consider a value with a wildcard generic param type as a type. But this is a very niche problem, and I'm not sure how to check for this. `skGenericParam` symbols stay as idents when semchecked so it can't be checked that the node is an `skGenericParam` symbol. It could be checked that it's an ident but I don't know how robust this is. And maybe there is another way to refer to a wildcard generic param type instead of just its symbol, i.e. another kind of node. This also makes #5647 finally work but a test case for that can be added after.
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.