-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
default(M)
where M
is uninstantiated generic has nil type
#24091
Labels
Error Messages
Generics
Invalid Code Acceptance
Everything related to compiler not complaining about invalid code
Comments
metagn
added
Error Messages
Invalid Code Acceptance
Everything related to compiler not complaining about invalid code
labels
Sep 10, 2024
Araq
pushed a commit
that referenced
this issue
Sep 10, 2024
…24092) fixes #24090 Generic body types are normally a sign of an uninstantiated type, and so give errors when trying to instantiate them. However when instantiating free user expressions like the nodes of `tyFromExpr`, generic default params, static values etc, they can be used as arguments to macros or templates etc (as in the issue). So, we don't try to instantiate generic body type symbols at all in free expressions such as these (but not in for example type nodes), and avoid the error. In the future there should be a "concrete type" check for generic body types different from the check in type instantiation to deal with things like #24091, if we do want to allow this use of them.
Fixing this for type Generic[U] = object
proc foo[T](x: typedesc[T]): T =
echo T # Generic
echo declared(result) # true
echo typeof(result) # Generic
echo typeof(foo(Generic)) # void
foo(Generic) For things like |
metagn
added a commit
to metagn/Nim
that referenced
this issue
Oct 10, 2024
narimiran
pushed a commit
that referenced
this issue
Jan 14, 2025
fixes #24091, refs #24092 Any instantiations resolving to a generic body type now gives an error. Due to #24092, this does not error in cases like matching against `type M` in generics because generic body type symbols are just not instantiated. But this prevents parameters with type `type M` from being used, although there doesn't seem to be any code which does this. Just in case such code exists, we still allow `typedesc` types resolving to generic body types. (cherry picked from commit 2f90453)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Error Messages
Generics
Invalid Code Acceptance
Everything related to compiler not complaining about invalid code
Description
Nim Version
2177176, 2.0
Current Output
Expected Output
Known Workarounds
No response
Additional Information
Another side effect:
The
x
field is just deleted because the type isnil
, treating it like a void type.I think
M
by itself should matchtypedesc
parameters andtypedesc[M]
, but it shouldn't be available as the type of anything else. In this case the result ofdefault
.The text was updated successfully, but these errors were encountered: