Skip to content
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

Closed
metagn opened this issue Sep 10, 2024 · 1 comment · Fixed by #24273
Closed

default(M) where M is uninstantiated generic has nil type #24091

metagn opened this issue Sep 10, 2024 · 1 comment · Fixed by #24273
Labels
Error Messages Generics Invalid Code Acceptance Everything related to compiler not complaining about invalid code

Comments

@metagn
Copy link
Collaborator

metagn commented Sep 10, 2024

Description

type M[V] = object
echo default(M)

Nim Version

2177176, 2.0

Current Output

(2, 1) Error: type mismatch
Expression: echo default(M)
  [1] default(M): void

Expected one of (first mismatch at [position]):
[1] proc echo(x: varargs[typed, `$`])

Expected Output

'M' is not a concrete type or something

Known Workarounds

No response

Additional Information

Another side effect:

type M[V] = object
type Foo = object # notice not generic
  x: typeof(default(M))
echo Foo() # ()

The x field is just deleted because the type is nil, treating it like a void type.

I think M by itself should match typedesc parameters and typedesc[M], but it shouldn't be available as the type of anything else. In this case the result of default.

@metagn 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.
@metagn
Copy link
Collaborator Author

metagn commented Sep 10, 2024

Fixing this for default is easy since it's a magic but this is a general problem:

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 var s: seq[Generic], this is handled in typeAllowed, maybe we should do the same for skParam/skResult after instantiation

metagn added a commit to metagn/Nim that referenced this issue Oct 10, 2024
@Araq Araq closed this as completed in 2f90453 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
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant