gcc error when constructing an object that has the same name in the same file name in 2 different directories

[hamidb80]

Example

module1/defs.nim:

type MyObj* = object
  field1*: int

module2/defs.nim:

type MyObj* = object
  field2*: int

main.nim:

import module1/defs as md1
import module2/defs as md2

echo md1.MyObj(field1: 1)
echo md2.MyObj(field2: 1)

Current Output

gcc error, undeclared field of struct:

error: 'tyObject_MyObj__vPIR9aeSj2i9aDvEgKt9azXzg' {aka 'struct tyObject_MyObj__vPIR9aeSj2i9aDvEgKt9azXzg'} has no member named 'field2'; did you mean 'field1'?
  addQuoted__main_48((&result), x.field2);

Expected Output

compiles successfully

Possible Solution

maybe name mangeling doesn't happen correctly in this situation

Additional Information

$ nim -v
Nim Compiler Version 1.7.1 [Windows: amd64]
Compiled at 2022-07-17
Copyright (c) 2006-2022 by Andreas Rumpf

active boot switches: -d:release

[ringabout]

It works with 1.6.6

[ringabout]

I have run a git bisect and found the culprit commit.

[ringabout]

I found the offending diff. But I'm too tired today. I will think of a solution tomorrow.

[hamidb80]

I found the offending diff. But I'm too tired today. I will think of a solution tomorrow.

I'm really amazed by your passion honestly, do you have any suggestion on how to start contributing to compiler?

[ringabout]

I don't have much experience. For an issue, first check whether they are regressions by switching Nim versions. If so, do a bisect to find the wrong commit. Issues regarding generics, sigmatch tend to be hard to tough. You can start from error messages https://github.com/nim-lang/Nim/issues?q=is%3Aissue+is%3Aopen+label%3A%22Error+messages%22 or choose doable rfcs from https://github.com/nim-lang/RFCs

[hamidb80]

unfortunately this happened into nim 1.6.8

[ringabout]

Yeah, it is a regression caused by https://github.com/nim-lang/Nim/commit/fd76c004794e1cd163450465fa6e493735e6dee4

[bung87]

compiler\ccgtypes.nim line 887 commented into this # m.typeCache[sig] = result # always call for sideeffects:
I see it produce duplicated types , including module1 and module2, they have same sig, so their type name also same.

[arnetheduck]

This issue can spill over to runtime when the types are sufficiently similar - the result is memory corruption and random crashes as functions for one type overwrite the fields of the other type and other ill effects such as the GC getting confused.