-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
for loop invoked from generic procedure defined in another module cant find items
iterator
#11167
Comments
items
iteratoritems
iterator
It also works if |
I looks like |
looks like
? reduced case: replace a.nim with: iterator items(a: int): int = discard
proc p*(a: int | uint) =
for _ in a:
discard |
workarounduse (works both with or without potential solutionmaybe semcheck of generic should early expand the for loop with items / pairs transformations, but needs to work with https://nim-lang.org/docs/manual.html#generics-symbol-lookup-in-generics in mind EDITrelated (perhaps even duplicate) of #4773; see for example: #4773 (comment) |
items
iteratoritems
iterator
Another simple case where the problem occurs in nim 1.0.4 and #head: First module ee.nim: import sets
proc initH*[V]: HashSet[V] =
result = initHashSet[V]()
proc foo*[V](h: var HashSet[V], c: seq[V]) =
h = h + c.toHashSet() Second module ff.nim import hashes
import ee
type
Choice = object
i: int
proc hash(c: Choice): Hash =
result = Hash(c.i)
var h = initH[Choice]()
let c = @[Choice(i: 1)]
foo(h, c) Compilation of $ nim c ff
Hint: used config file '/home/pierre/.choosenim/toolchains/nim-#devel/config/nim.cfg' [Conf]
Hint: used config file '/home/pierre/.choosenim/toolchains/nim-#devel/config/config.nims' [Conf]
Hint: system [Processing]
Hint: widestrs [Processing]
Hint: io [Processing]
Hint: ff [Processing]
Hint: hashes [Processing]
Hint: ee [Processing]
Hint: sets [Processing]
Hint: math [Processing]
Hint: bitops [Processing]
Hint: macros [Processing]
/home/pierre/alternaCloud/Temp/sdk/ff.nim(17, 4) template/generic instantiation of `foo` from here
/home/pierre/alternaCloud/Temp/sdk/ee.nim(9, 9) template/generic instantiation of `+` from here
/home/pierre/.choosenim/toolchains/nim-#devel/lib/pure/collections/sets.nim(487, 17) template/generic instantiation of `union` from here
/home/pierre/.choosenim/toolchains/nim-#devel/lib/pure/collections/sets.nim(411, 7) template/generic instantiation of `incl` from here
/home/pierre/.choosenim/toolchains/nim-#devel/lib/pure/collections/sets.nim(211, 15) Error: type mismatch: got <HashSet[ff.Choice]>
but expected one of:
iterator items[T](a: seq[T]): T
first type mismatch at position: 1
required type for a: seq[T]
but expression 'other' is of type: HashSet[ff.Choice]
iterator items[T](s: HSlice[T, T]): T
first type mismatch at position: 1
required type for s: HSlice[items.T, items.T]
but expression 'other' is of type: HashSet[ff.Choice]
iterator items(a: string): char
first type mismatch at position: 1
required type for a: string
but expression 'other' is of type: HashSet[ff.Choice]
iterator items[IX, T](a: array[IX, T]): T
first type mismatch at position: 1
required type for a: array[IX, T]
but expression 'other' is of type: HashSet[ff.Choice]
iterator items[T](a: set[T]): T
first type mismatch at position: 1
required type for a: set[T]
but expression 'other' is of type: HashSet[ff.Choice]
iterator items(a: cstring): char
first type mismatch at position: 1
required type for a: cstring
but expression 'other' is of type: HashSet[ff.Choice]
iterator items[T](a: openArray[T]): T
first type mismatch at position: 1
required type for a: openArray[T]
but expression 'other' is of type: HashSet[ff.Choice]
iterator items(E: typedesc[enum]): E:type
first type mismatch at position: 1
required type for E: type enum
but expression 'other' is of type: HashSet[ff.Choice]
expression: items(other) If both files are merged, the error disappear. Or if |
Simply adding |
bumping priority; keeps happening, see #16060 |
I noticed that with the latest devel, import sets, sequtils
proc dedupe*[T](arr: openArray[T]): seq[T] =
arr.toHashSet.toSeq
export sets.items ...and import foo
echo dedupe([1, 2, 3]) Running
Exporting
|
@oakes you can send a PR to fix it similar to https://github.com/nim-lang/Nim/pull/16060/files |
candidate places to look at for a fix:
|
Yeah... But it changes the AST and isn't correct for when |
closes nim-lang/RFCs#380, fixes #4773, fixes #14729, fixes #16755, fixes #18150, fixes #22984, refs #11167 (only some comments fixed), refs #12620 (needs tiny workaround) The compiler gains a concept of root "nominal" types (i.e. objects, enums, distincts, direct `Foo = ref object`s, generic versions of all of these). Exported top-level routines in the same module as the nominal types that their parameter types derive from (i.e. with `var`/`sink`/`typedesc`/generic constraints) are considered attached to the respective type, as the RFC states. This happens for every argument regardless of placement. When a call is overloaded and overload matching starts, for all arguments in the call that already have a type, we add any operation with the same name in the scope of the root nominal type of each argument (if it exists) to the overload match. This also happens as arguments gradually get typed after every overload match. This restricts the considered overloads to ones attached to the given arguments, as well as preventing `untyped` arguments from being forcefully typed due to unrelated overloads. There are some caveats: * If no overloads with a name are in scope, type bound ops are not triggered, i.e. if `foo` is not declared, `foo(x)` will not consider a type bound op for `x`. * If overloads in scope do not have enough parameters up to the argument which needs its type bound op considered, then type bound ops are also not added. For example, if only `foo()` is in scope, `foo(x)` will not consider a type bound op for `x`. In the cases of "generic interfaces" like `hash`, `$`, `items` etc. this is not really a problem since any code using it will have at least one typed overload imported. For arbitrary versions of these though, as in the test case for #12620, a workaround is to declare a temporary "template" overload that never matches: ```nim # neither have to be exported, just needed for any use of `foo`: type Placeholder = object proc foo(_: Placeholder) = discard ``` I don't know what a "proper" version of this could be, maybe something to do with the new concepts. Possible directions: A limitation with the proposal is that parameters like `a: ref Foo` are not attached to any type, even if `Foo` is nominal. Fixing this for just `ptr`/`ref` would be a special case, parameters like `seq[Foo]` would still not be attached to `Foo`. We could also skip any *structural* type but this could produce more than one nominal type, i.e. `(Foo, Bar)` (not that this is hard to implement, it just might be unexpected). Converters do not use type bound ops, they still need to be in scope to implicitly convert. But maybe they could also participate in the nominal type consideration: if `Generic[T] = distinct T` has a converter to `T`, both `Generic` and `T` can be considered as nominal roots. The other restriction in the proposal, being in the same scope as the nominal type, could maybe be worked around by explicitly attaching to the type, i.e.: `proc foo(x: T) {.attach: T.}`, similar to class extensions in newer OOP languages. The given type `T` needs to be obtainable from the type of the given argument `x` however, i.e. something like `proc foo(x: ref T) {.attach: T.}` doesn't work to fix the `ref` issue since the compiler never obtains `T` from a given `ref T` argument. Edit: Since the module is queried now, this is likely not possible. --------- Co-authored-by: Andreas Rumpf <[email protected]>
Template with for loop invoked from generic procedure defined in another cant find
items
iteratorExample
a.nim
test.nim
Current Output
Expected Output
Should compile and run without errors.
Additional Information
Removing generic component from
p
or running p from the same module removes the error.links
in
inside a template not lowered tocontains
if called from another module #18150The text was updated successfully, but these errors were encountered: