fix #25508; disallow 'void' as a tuple field type for non generic void

[ringabout]

fix #25508

[Copilot]

Pull request overview

This pull request fixes issue #25508 where using void as a tuple field type causes an internal compiler error internal error: getTypeDescAux(tyVoid). The fix adds validation in the semantic analysis phase to reject void types as tuple field types before they reach code generation.

Changes:

• Added void field type validation in semAnonTuple and semTuple functions
• Created test case to verify proper error messages for both named and anonymous tuples with void fields

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
tests/errmsgs/t25508.nim	Test case verifying void fields in tuples are rejected with clear error messages
compiler/semtypes.nim	Added void type checks in tuple semantic analysis to prevent internal errors during code generation

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[arnetheduck]

why disallow? why not treat it the same as if it appeared in a generic instantiation?

[ringabout]

It's buggy #19335

[Araq]

Yeah, I don't get it either... The other PR I merged allows void and removes these fields from the tuple.

[ringabout]

The other PR allows generic voids for tuple fields. It may require codegen changes for a plain void field in a tuple field

[ringabout]

I will see whether I can fix it following #10144

[Araq]

The problem with void are all coming from the fact that we don't have a value for void and so createThread[void]() must work. We should revisit this idea and then void is simply a type that the backend eliminates: Have a parameter of type void? Ok, don't emit. A variable? A field in an object? All the same, just don't emit it. Zero cost at runtime, all the power for the compile-time. All it takes is to make the value () be of type void and tuple[] be an alias for void, the call then becomes createThread(()) but that's acceptable and even shorter than the explicit [void].

Requires a switch --voidFixed for backwards compat but it's a clean way forward in fixing void-related bugs.