Closed pietroppeter closed 1 year ago
This cannot be fixed reliably from this library side. Nim templates/generics is not instantiated where it is declared. Often the hint produced by the caller but it still report the hint came from where the generic proc/template declared. This is obviously misleading hint from Nim compiler.
But maybe you have idea how to fix it.
Ok, I understand.
I recently discovered that adding a warning pragma to turn off a specific warning at the end of a source file, turns it off only for that specific file, maybe this applies for turning off a hint, too.
I might experiment with that by trying to add such a line either to where I use this in nimib or directly in this library. In case I do I will update the thread.
https://github.com/status-im/nim-stew/pull/131 provides a model for how to fix this
https://github.com/status-im/nim-stew/pull/131 provides a model for how to fix this
...for cases where you have {.push raises: [Defect].}
at the top of a file.
But here (and in several other libraries similarly), you have:
proc readValue*[T](r: var TomlReader, value: var T)
{.raises: [SerializationError, IOError, ValueError, Defect].} =
I haven't find a way to make this both Nim 1.2 and 1.4+ compatible yet.
A quite reliable solution is to specialize the generic proc readValue
. but it defeat the purpose of generics in the first place.
On the other hand, in Nim metaprogramming context, pragma looks like below secondary class citizen. If pragma can be first class citizen for metaprogramming, well, that is still a sweet dream.
I am using this library in this project: https://github.com/pietroppeter/nimib
I have seen that when it is used it raises multiple times the following hints [XCannotRaiseY]
It is not a big issue for a user (we could always silence this specific hint, but I thought you might want to know (maybe you already do).
(fyi the above log is taken from CI of nimib project, latest commit)