Skip to content

libsyntax: no inheritance with tuple/unit structs #15117

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

Closed
wants to merge 1 commit into from

Conversation

ben0x539
Copy link
Contributor

Stops parsing inheritance with tuple structs and unit-like structs to fix #15096.

Struct inheritance, unstable as it is, only really makes sense for
"record-like" structs and previously produced bad code when used with
unit-like structs or tuple structs. So this commit stops parsing
super-structs for unit-like structs and tuple structs, and rejects
virtual unit-like structs and tuple structs.

[breaking-change]
@alexcrichton
Copy link
Member

cc @nick29581

@ghost
Copy link

ghost commented Jun 23, 2014

I think this should be enforced in typeck, not in the parser. typeck::collect::convert_struct() should be the right place to look.

@ben0x539
Copy link
Contributor Author

I initially started adding it there but ended up fairly uncertain whether that was the right place. I was eyeing typeck::check::check_struct() too, but it seemed pretty strange to accept the fairly abstruse syntax for tuple structs with super-structs in the parser and only complain about it later.

I'll move the checks over if that's where they ought to be.

@alexcrichton
Copy link
Member

Closing due to inactivity, but feel free to reopen with a rebase!

bors added a commit to rust-lang-ci/rust that referenced this pull request Feb 18, 2024
…r=Veykril

feat: ignored and disabled macro expansion

Supersedes rust-lang#15117, I was having some conflicts after a rebase and since I didn't remember much of it I started clean instead.

The end result is pretty much the same as the linked PR, but instead of proc macro lookups, I marked the expanders that explicitly cannot be expanded and we shouldn't even attempt to do so.

## Unresolved questions

- [ ] I introduced a `DISABLED_ID` next to `DUMMY_ID` in `hir-expand`'s `ProcMacroExpander`, that is effectively exactly the same thing with slightly different semantics, dummy macros are not (yet) expanded probably due to errors, while not expanding disabled macros is part of the usual flow. I'm not sure if it's the right way to handle this, I also thought of just adding a flag instead of replacing the macro ID, so that the disabled macro can still be expanded for any reason if needed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Struct inheritance goes wrong for unit-like and tuple structs
2 participants