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

document common enum fields #3338

Closed
jesse99 opened this issue Sep 1, 2012 · 3 comments
Closed

document common enum fields #3338

jesse99 opened this issue Sep 1, 2012 · 3 comments
Milestone

Comments

@jesse99
Copy link
Contributor

jesse99 commented Sep 1, 2012

Commit 5c9c9a6 talks about something called common enum fields and includes the following wacky rust example:

enum Foo {
    struct {
        x: int;
        y: int;
    }

    Bar(int),
    Baz(int)
}

Don't see this documented anywhere.

@jesse99
Copy link
Contributor Author

jesse99 commented Nov 18, 2012

Wanted to document this but I have no idea what it's for or how you'd go about initializing x and y. Fwiw I searched all of src using:
enum \s+ [a-zA-Z0-9]+ \s* { \s* struct \s* {
and the only place that syntax seems to be used is the one trivial example from the original commit.

@nikomatsakis
Copy link
Contributor

I think we've decided not to support these.

@catamorphism
Copy link
Contributor

Closing since we're not supporting them.

oli-obk pushed a commit to oli-obk/rust that referenced this issue May 2, 2020
The lint was changed to be more lenient than the documentation implies in PR rust-lang#3338.
Related issue rust-lang#3313
oli-obk pushed a commit to oli-obk/rust that referenced this issue May 2, 2020
…, r=phansch

Update documentation for new_ret_no_self

changelog: Update documentation for lint new_ret_no_self to reflect that the return type must only contain `Self`, not be `Self`

The lint was changed to be more lenient than the documentation implies in PR rust-lang#3338 (Related issue rust-lang#3313)
RalfJung pushed a commit to RalfJung/rust that referenced this issue Mar 3, 2024
…RalfJung

print thread name in miri error backtraces; add option to track read/write accesses

This came up while debugging rust-lang#121626. It didn't end up being useful there but still seems like good tools to have around.
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

No branches or pull requests

3 participants