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.

Sign up for GitHub

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

Jump to bottom

explicit generic instantiation accepts value when type is expected #12664

Open
timotheecour opened this issue Nov 15, 2019 · 1 comment
Open

explicit generic instantiation accepts value when type is expected #12664

timotheecour opened this issue Nov 15, 2019 · 1 comment
Labels
Generics Semantic Analysis

Comments

@timotheecour
Copy link
Member

explicit template instantiation accepts value when type is expected

Example

type A[T] = object # ditto with A[T: string]
let a1 = A[string]() # ok
let a2 = A["abc"]() # should not compile
static: doAssert type(a1) is type(a2)

type B[T: static string] = object
let b2 = B["abc"]() # ok

Current Output

compiles

Expected Output

CT error: expected type, got value

Additional Information

latest devel f22d3c7
@timotheecour timotheecour changed the title explicit template instantiation accepts value when type is expected explicit generic instantiation accepts value when type is expected Feb 18, 2020
@konsumlamm konsumlamm mentioned this issue Apr 7, 2020
Open
@metagn
Copy link
Collaborator

metagn commented Aug 21, 2023 

type A[T] = object
let a2 = A["abc"]()

No reason this shouldn't compile.

# ditto with A[T: string]

This is a bug. Keywords for search: generic parameter type constraint

Also, generics are mistakenly referred to as templates again.

@metagn metagn added Generics and removed Templates labels Aug 21, 2023
@metagn metagn mentioned this issue Jan 18, 2024
Open
@metagn metagn mentioned this issue Oct 4, 2024
Merged
Araq pushed a commit that referenced this issue Oct 7, 2024
@metagn
give int literals matched type on generic match (#24234)
c73eedf 
fixes #24233

Integer literals with type `int` can match `int64` with a generic match.
Normally this would generate an conversion via `isFromIntLit`, but when
it matches with a generic match (`isGeneric`) the node is left alone and
continues to have type `int` (related to #4858, but separate; since
`isFromIntLit > isGeneric` it doesn't propagate). This did not cause
problems on the C backend up to this point because either the compiler
generated a cast when generating the C code or it was implicitly casted
in the C code itself. On the JS backend however, we need to generate
`int64` and `int` values differently, so we copy the integer literal and
give it the matched type now instead.

This is somewhat risky even if CI passes but it's required to make the
times module work without [this
workaround](https://github.com/nim-lang/Nim/blob/7dfadb8b4e95d09981fbeb01d85b12f23946c3e7/lib/pure/times.nim#L219-L238)
on `--jsbigint64:on` (the default).

CI exposed an issue: When matching an int literal to a generic parameter
in a generic instantiation, the literal is only treated like a value if
it has `int literal` type, but if it has the type `int`, it gets
transformed into literally the type `int` (#12664, #13906), which breaks
the tests t14193 and t12938. To deal with this, we don't give it the
type `int` if we are in a generic instantiation and preserve the `int
literal` type.
This was referenced Oct 10, 2024
Open
Merged
Araq pushed a commit that referenced this issue Oct 18, 2024
@metagn
better errors for standalone explicit generic instantiations (#24276)
0a058a6 
refs #8064, refs #24010

Error messages for standalone explicit generic instantiations are
revamped. Failing standalone explicit generic instantiations now only
error after overloading has finished and resolved to the default `[]`
magic (this means `[]` can now be overloaded for procs but this isn't
necessarily intentional, in #24010 it was documented that it isn't
possible). The error messages for failed instantiations are also no
longer a simple `cannot instantiate: foo` message, instead they now give
the same type mismatch error message as overloads with mismatching
explicit generic parameters.

This is now possible due to the changes in #24010 that delegate all
explicit generic proc instantiations to overload resolution. Old code
that worked around this is now removed. `maybeInstantiateGeneric` could
maybe also be removed in favor of just `explicitGenericSym`, the `result
== n` case is due to `explicitGenericInstError` which is only for niche
cases.

Also, to cause "ambiguous identifier" error messages when the explicit
instantiation is a symchoice and the expression context doesn't allow
symchoices, we semcheck the sym/symchoice created by
`explicitGenericSym` with the given expression flags.

#8064 isn't entirely fixed because the error message is still misleading
for the original case which does `values[1]`, as a consequence of
#12664.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Generics Semantic Analysis
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@timotheecour @metagn @mratsim