`nimHasFix1234`

[timotheecour]

we can use this convention when you need to branch in your code preemptively on a bugfix in compiler / stdlib that doesn't exist yet:

in issue 1234:

# test case in bug 1234
static: doAssert defined(nimHasFix1234) # or some descriptive name, eg `nimHasFixFooBroken`; but starts with `nimHasFix`
doAssert thisShouldWorkButFails()

and then a fix for issue 1234 shall add that test case in t1234.nim (or somewhere else) and define nimHasFix1234.

this allows you to preemptively branch on code that isn't fixed yet in the compiler/stdlib but expect it may in the near future, with similar benefits as since.

stdlib vs compiler

• one subtlety is that the bugfix may occur either in the compiler or in stdlib:
  • if bug if fixed in compiler, defineSymbol("nimHasFix1234") must be in condsyms.nim
  • if bug if fixed in stdlib (as was the case here), {.define(nimHasFix1234).} must be in system.nim or maybe compilesettings.nim

The distinction matters, see why here: nim-lang#14648 (short answer: because of nim --lib:lib)

why not when hasFix(12231)

nim already has a mechanism using nimHasFoo (see condsyms.nim), and it's strictly more flexible than an issue number, because it gives you freedom to specify what was fixed; eg if:
bug 1234 contains 2 sub issues foo and bar, you can have a nim commit with: nimHasFix1234Foo(ornimHasFixFoo`)

somewhat related

• testament: failureAllowed:true to allow issue reporters to add test cases, and get notified upon "accidental" fix nim-lang/RFCs#129