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.

Sign up for GitHub

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

Jump to bottom

Nullary variants should be considered rvalues, not static identifiers. #10800

Closed
nikomatsakis opened this issue Dec 4, 2013 · 7 comments
Closed

Nullary variants should be considered rvalues, not static identifiers. #10800

nikomatsakis opened this issue Dec 4, 2013 · 7 comments
Labels
A-lifetimes Area: Lifetimes / regions A-type-system Area: Type system E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added.
Milestone
1.0

Comments

@nikomatsakis
Copy link
Contributor

I think there's an existing issue, but I can't find it. Currently borrowck treats nullary variants (like None) as static identifies. This doesn't make sense for generic enums and I don't think it matches up with trans. The reason it doesn't make sense for generic enums is that None::<Foo> and None::<Bar> have totally different sizes etc., so there couldn't possible be a single static constant to refer to. This is a relatively simple fix to the mem_categorization code, but it's worth investigating how trans handles enum variants and make sure that everything will be compatible.

Nominating since it is a backwards compatibility thing.
@nikomatsakis
Copy link
Contributor Author

I just checked trans and indeed it is always generated as an rvalue.

@glaebhoerl glaebhoerl mentioned this issue Jan 2, 2014
Closed
@pnkfelix
Copy link
Member

pnkfelix commented Jan 9, 2014

(is this somehow related to #8229 ? Just curious...)

@pnkfelix
Copy link
Member

pnkfelix commented Jan 9, 2014

Accepted for 1.0, P-backcompat-lang

@huonw huonw mentioned this issue Jan 20, 2014
Closed
@dmski
Copy link
Contributor

dmski commented Mar 12, 2014

Should this be just closed? It looks like a duplicate of #11681 (which is closed).

@flaper87
Copy link
Contributor

@dmski looks like you're right. Tagging as needs test.

@dmski
Copy link
Contributor

dmski commented Mar 12, 2014

There is https://github.com/mozilla/rust/blob/master/src/test/compile-fail/regions-lifetime-of-struct-or-enum-variant.rs which looks like it tests exactly this. Do you think that another test for this can be added?

@flaper87
Copy link
Contributor

@dmski looks sufficient. I had forgotten about that test :D

flip1995 pushed a commit to flip1995/rust that referenced this issue Jun 2, 2023
@bors
Auto merge of rust-lang#10807 - y21:issue10800, r=Jarcho
05740ad 
[`unused_async`]: do not consider `await` in nested `async` blocks as used

Fixes rust-lang#10800.
This PR makes sure that `await` expressions inside of inner `async` blocks don't prevent the lint from triggering.
For example
```rs
async fn foo() {
  async {
    std::future::ready(()).await;
  }
}
```
Even though there *is* a `.await` expression in this function, it's contained in an async block, which means that the enclosing function doesn't need to be `async` too.

changelog: [`unused_async`]: do not consider `await` in nested `async` blocks as used
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-lifetimes Area: Lifetimes / regions A-type-system Area: Type system E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added.
Projects
None yet
Milestone
1.0
Development

No branches or pull requests
4 participants
@flaper87 @nikomatsakis @pnkfelix @dmski