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

Value is accepted as type parameter #13906

Open
konsumlamm opened this issue Apr 7, 2020 · 0 comments
Open

Value is accepted as type parameter #13906

konsumlamm opened this issue Apr 7, 2020 · 0 comments
Labels
Generic Procs Invalid Code Acceptance Everything related to compiler not complaining about invalid code Medium Priority Semantic Analysis

Comments

@konsumlamm
Copy link
Contributor

The compiler accepts passing a value as type parameter, using the type of the value as the actual type parameter (see the example below), instead of reporting an error. I'm not sure if this is a bug or intended behaviour, but i couldn't find any documentation on it.

Example

proc test[T](x: T) = discard

test[12](42)  # works, T is int
test["12"]("42")  # works, T is string
test["12"](42)  # doesn't work

Additional Information

Possibly related to #12664.

$ nim -v
Nim Compiler Version 1.2.0
@Araq Araq added Invalid Code Acceptance Everything related to compiler not complaining about invalid code Medium Priority labels Apr 7, 2020
@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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Generic Procs Invalid Code Acceptance Everything related to compiler not complaining about invalid code Medium Priority Semantic Analysis
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@Araq @metagn @mratsim @konsumlamm