Warning: 'Lock levels' are deprecated, now a noop [Deprecated]

[PhilippMDoerner]

Apparently with nim 2.0 lock levels were done away with. Where previously we had {.locks: 0.} to signify that this code would never acquire a lock, we now don't.

According to Rika on the discord it should be fine to just remove those as they shouldn't be needed anymore, but I'm not insanely sure on that. There appears to be no new way at least to express "This code should never acquire a lock" (At least I think that:s what locks:0 expressed).

I opened a forum thread to ask about this topic: https://forum.nim-lang.org/t/10487#69953

The "development" for this ticket is a pretty simple Find-replace of locks: 0 with either nothing or whatever the solution is.

[PhilippMDoerner]

After a chat with @beef331 on discord (https://discord.com/channels/371759389889003530/371759389889003532/1152524809356460052) I'm getting more the impression that there is no equivalent and basically removing it for nim 2.0 is the only thing that works.

Note that this will lead to the code still compiling on nim 1.6., but with a boatload of compilerwarnings:

/home/philipp/dev/owlkettle/owlkettle/widgetdef.nim(516, 12) Warning: method has lock level 0, but another method has <unknown> [LockLevel]

Which may have been the original reason you added locklevel pragmas.

[can-lehmann]

Lock levels always have been quite buggy in 1.x.x releases of Nim, so the locks: 0 pragmas were indeed added in order to silence the compiler warnings. Removing them should however also not be an issue.

[PhilippMDoerner]

I've implemented a "We support both depending on nim version" solution for now because I similarly want to make sure one doesn't get spammed with meaningless warnings regardless of which nim version we use. Therefore going with the approach of a custom locker pragma that is locks: 0 for nim 1.6. and nothing for nim 2.0 seems valid.

[can-lehmann]

I am not sure how long we can keep supporting both versions, but I think it will be possible for 3.0.0.