Set construction syntax no longer works for generic parameter

[autumngray]

Description

The following two cases work up to 2.0.12 but fail since 2.2.0:

type E = enum A
proc foo[T](t: set[T] = {T.A}) =
  discard
foo[E]()

proc bar[T](t: set[T] = {T(0)}) =
  discard
bar[uint8]()

Nim Version

Tested with choosenim versions 2.0.12, 2.2.0, and devel git hash: 5340005

Current Output

Error: ordinal type expected; given: typeof(T.A)
Error: type mismatch: got 'typeof(T.A)' for 'T.A' but expected 'range 0..65535(int)'
Error: ordinal type expected; given: typeof(T(0))
Error: type mismatch: got 'typeof(T(0))' for 'T(0)' but expected 'range 0..65535(int)'

Expected Output

No response

Known Workarounds

A workaround:

template Tset(T: typedesc): untyped =
  {T(0)}

proc bar2[T](t: set[T] = Tset(T)) =
  discard
bar2[E]()

Additional Information

No response

[ringabout]

!nim c

type E = enum A
proc foo[T](t: set[T] = {T.A}) =
  discard
foo[E]()

proc bar[T](t: set[T] = {T(0)}) =
  discard
bar[uint8]()

[github-actions]

🐧 Linux bisect by @ringabout (member)

devel 👎 FAIL

Output

Filesize 0 (0 bytes)
Duration

stable 👎 FAIL

Output

Filesize 0 (0 bytes)
Duration

2.0.10 👍 OK

Output

Filesize 93.00 Kb (95,232 bytes)
Duration

2.0.0 👍 OK

Output

Filesize 90.84 Kb (93,016 bytes)
Duration

1.6.20 👍 OK

Output

Filesize 95.67 Kb (97,968 bytes)
Duration

1.4.8 👍 OK

Output

Filesize 91.36 Kb (93,552 bytes)
Duration

1.2.18 👍 OK

Output

Filesize 87.09 Kb (89,176 bytes)
Duration

1.0.10 👍 OK

Output

Filesize 86.19 Kb (88,256 bytes)
Duration

#a93c5d79b ➡️ 🐛

Diagnostics

metagn introduced a bug at 2024-09-06 12:44:38 +0300 on commit #a93c5d79b with message:

dInDefault`.

Other minor bugfixes:

* To make the error message in t20883 make sense, we now give a "cannot
instantiate" error when trying to instantiate a proc generic param with
`tyFromExpr`.
* Object constructors as default param values generated default values
of private fields going through `evalConstExpr` more than once, but the
VM doesn't mark the object fields as `nfSkipFieldChecking` which gives a
"cannot access field" error. So the VM now marks object fields it
generates as `nfSkipFieldChecking`. Not sure if this affects VM
performance, don't see why it would.
* The nkRecWhen changes in #24042 didn't cover the case where all
conditions are constantly false correctly, this is fixed with a minor
change. This isn't needed for this PR now but I encountered it after
forgetting to `dec c.inGenericContext`.

The bug is in the files:

The bug can be in the commits:

• #ca28c256f
• #ebcfd96ae
• #cd22560af
• #7cd177721
• #a93c5d79b
• #c10f84b9d
• #4a548deb0
• #d77ea0783
• #bf865fa75

(Diagnostics sometimes off-by-one).

Stats

• GCC 11.4.0
• Clang 14.0.0
• NodeJS 20.5
• Created 2024-11-28T15:40:05Z
• Comments 1
• Commands nim c --run -d:nimDebug -d:nimDebugDlOpen -d:ssl -d:nimDisableCertificateValidation --forceBuild:on --colors:off --verbosity:0 --hints:off --lineTrace:off --nimcache:/home/runner/work/Nim/Nim --out:/home/runner/work/Nim/Nim/temp /home/runner/work/Nim/Nim/temp.nim

🤖 Bug found in 26 mins bisecting 1083 commits at 41 commits per second

[juancarlospaco]

@metagn See #24484 (comment)