google / google/xls

DSLX: Confusing situation on aliased imports

Open
#728 1 comment 0 reactions 0 assignees View on GitHub
dslx
Dominant language
C++
Stars
1.9k
Forks
283
Avg merge
2d 10h
Merged PRs (30d)
135

Description

Internally, when we import a DSLX file, we allow an optional prefix on our import paths; IOW, `import foo.bar` is mostly the same as `import baz.foo.bar`. I'm not sure why we do this (maybe we probably shouldn't?), but if one mixes these formats, we get a very confusing error where it appears that a type is not equal to itself:
```
0017: let ctr_enc = aes::encrypt(
0018: key, aes_common::KeyWidth::KEY_256,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^-------^ XlsTypeError: KeyWidth vs KeyWidth: Mismatch between parameter and argument t
ypes.
```

This can happen if you have something like below:
File A:
```
import baz.foo.bar

fn something(x: bar::MyEnum) ...
```

File B:
```
import foo.bar
import A

fn something_else() {
A::something(bar::MyEnum);
}
```

The root cause is that the different import paths cause ImportData to treat them as separate entities and to typecheck, etc. them separately. When it's time to deduce the invocation of `something`, it fails because in EnumType::operator==(), the addresses of the underlying EnumDefs differ.

Not sure what the immediate fix is - symlinks are something that are allowed to exist, and we might want identical types to be assignable anyway, i.e., maybe for the following to be valid:
```
struct MyStruct {
a: u32,
b: u32
}

struct MyOtherStruct {
a: u32,
b: u32
}

const MY_CONST_STRUCT: MyStruct = MyOtherStruct { a: u32:0, b: u32:0 };
```

Thinking is needed.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.