Skip to content
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

Chained import with import ... from ... generates invalid C++ names #1227

Closed
bbannier opened this issue Jun 28, 2022 · 0 comments · Fixed by #1228
Closed

Chained import with import ... from ... generates invalid C++ names #1227

bbannier opened this issue Jun 28, 2022 · 0 comments · Fixed by #1228
Assignees
Labels
Bug Something isn't working Regression

Comments

@bbannier
Copy link
Member

The following reproducer with chained imports produces names which cannot be found. Looking at the generated name it looks like this is due to us generating namespace names for hooks by concatenating the module names in the import chain, but use types in simple namespaces.

# @TEST-EXEC: spicyc -d -j z.spicy -o z.hlto

module z;
import y;

@TEST-START-FILE y.spicy
module y;
import x from bla;
@TEST-END-FILE

@TEST-START-FILE bla/x.spicy
module x;

type X = unit {
	on %done {}
};
@TEST-END-FILE

Bisecting with this reproducer points to #1195 as the change introducing this regression.

@bbannier bbannier added Bug Something isn't working Regression labels Jun 28, 2022
@rsmmr rsmmr self-assigned this Jun 28, 2022
rsmmr added a commit that referenced this issue Jun 29, 2022
different means.

This can happen when mixing normal import with  `import ... from`. A
previous change to support multiple units of the same name, missed
that we could run into namespacing trouble at code generation time in
this case. The problem was that we included the `from ...` scope into
the namespace, which doesn't work when we import the same module both
w/ and wo/ scope. Now we generate unique module IDs differently
through global state independent of file system paths.

Close #1227.
rsmmr added a commit that referenced this issue Jul 6, 2022
different means.

This can happen when mixing normal import with  `import ... from`. A
previous change to support multiple units of the same name, missed
that we could run into namespacing trouble at code generation time in
this case. The problem was that we included the `from ...` scope into
the namespace, which doesn't work when we import the same module both
w/ and wo/ scope. Now we generate unique module IDs differently
through global state independent of file system paths.

Close #1227.
bbannier pushed a commit that referenced this issue Jul 8, 2022
…fferent means.

This can happen when mixing normal import with  `import ... from`. A
previous change to support multiple units of the same name, missed
that we could run into namespacing trouble at code generation time in
this case. The problem was that we included the `from ...` scope into
the namespace, which doesn't work when we import the same module both
w/ and wo/ scope. Now we generate unique module IDs differently
through global state independent of file system paths.

Close #1227.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Something isn't working Regression
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants