-
Notifications
You must be signed in to change notification settings - Fork 406
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
Auto-generated instance names do not inherit macro scopes #2044
Comments
Vtec234
added a commit
to Vtec234/lean4
that referenced
this issue
Nov 26, 2023
Vtec234
added a commit
that referenced
this issue
Dec 13, 2023
Vtec234
added a commit
to Vtec234/lean4
that referenced
this issue
Dec 14, 2023
Vtec234
added a commit
to Vtec234/lean4
that referenced
this issue
Dec 15, 2023
Vtec234
added a commit
to Vtec234/lean4
that referenced
this issue
Dec 20, 2023
kmill
added a commit
to kmill/lean4
that referenced
this issue
Sep 30, 2024
…be hygienic Macros sometimes create auxiliary types and instances about them, and they rely on the instance name generate to create unique names in that case. This modifies the automatic name generator to add a fresh macro scope to the generated name if any of the constants in the type of the instance themselves have macro scopes. Closes leanprover#2044
github-merge-queue bot
pushed a commit
that referenced
this issue
Sep 30, 2024
…be hygienic (#5530) Macros sometimes create auxiliary types and instances about them, and they rely on the instance name generate to create unique names in that case. This modifies the automatic name generator to add a fresh macro scope to the generated name if any of the constants in the type of the instance themselves have macro scopes. Closes #2044
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
Suppose that the following metaprogram is executed in two different modules
A.lean
andB.lean
, and thatC.lean
then imports both modules.The duplication of the name
Foo
is fine and does not cause a clash thanks to macro hygiene which turns it into something like`[email protected]._hyg.7
and`[email protected]._hyg.7
in the respective module (by the way, there doesn't seem to be app
option to show this - is there? I had to resort to usingRepr Syntax
) so the struct names are not really duplicate. But the automatic instance name ends up beinginstToJsonFoo
, without macro scopes, in both cases. This causes an error on importing both intoC.lean
.According to @Kha, this is not the desired behaviour and macro scopes should be preserved in the autogenerated name somehow. See also Zulip.
In practice, this issue arises in the
deriving
handler forServer.RpcEncodable
.Steps to Reproduce
Expected behavior: Hygiene ensures that no names clash.
Actual behavior: We get a duplicate name error.
Reproduces how often: 100%
Versions
nightly-2023-01-14
The text was updated successfully, but these errors were encountered: