That's two days that I'm stuck in my code with the error
Error: type mismatch: got <type Float32Sort>
but expected one of:
template mkSort(s: typedesc[Float32Sort]): Z3_sort
first type mismatch at position: 1
required type for s: type Float32Sort
but expression 'Float32Sort_3735007' is of type: type Float32Sort
...
expression: mkSort(Float32Sort_3735007)
From what I understand of the error message, the expected type is the same as the provided one.
This is from a macro calling another macro with varargs[untyped] arguments calling a template with typedesc and generic arguments and then calling the final mkSort(s: typedesc[Float32Sort]) template. I learned from previous thread that templates don't play well with static and typedesc.
Because the identifier Float32Sort_3735007 has been generated by the compiler (gensymed), I thought there was a bug in templates gensyming typedesc instead of injecting them as is. I've tried to extract that part of the code and reproduce it in a smaller case but this sample compiles. I've tried multiple versions of the compiler with the same error: presently using 1.2.0.
As Nim compiler error messages are very sensible to code paths and as I'm learning macros, based on your experience, what should I try to refine the cause of the error message or work around it?
Thanks Araq! That was the case. Not because of an include file but because of a visibility bug (missing *) on the global types and I thought I needed to inject local scope predefined types in my macro...
I'm updating the Tips and Tricks page of Nim wiki from my learning experience and from the content of the forum. I'll put this one soon...
Would it be possible to make the error instead:
required type for s: type Float32Sort (defined at file1.nim:17:3) > but expression 'Float32Sort_3735007' is of type: type Float32Sort (defined at file2.nim:917:1)
Or something like that? That would make it less confusing. Perhaps having it always is information overload and it should only be provided if the string representing the type name is the same?
That's not a complete solution, because I except that this problem would happen mostly with template/macro instantiations from the same template/macro (and thus the exact same point of definition...). A complete solution, perhaps, would need a stack of the source locations of all template/macro expansions that lead to the type definition, and then eliminating the common prefixes and suffixes between the mismatched types to point to where the problem exactly is.
(Have no idea if the compiler even keeps all this info, and if it does - whether the implementation complexity is worth it for this)