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

Self::EnumVariant not considered const fn #64247

Closed
marmistrz opened this issue Sep 7, 2019 · 5 comments · Fixed by #65188
Closed

Self::EnumVariant not considered const fn #64247

marmistrz opened this issue Sep 7, 2019 · 5 comments · Fixed by #65188
Labels
A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) A-diagnostics Area: Messages for errors, warnings, and lints C-feature-request Category: A feature request, i.e: not implemented / a PR. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@marmistrz
Copy link
Contributor

marmistrz commented Sep 7, 2019 •
edited
Loading

When using Self to create an enum variant in Rust 1.37+, we get an error:

const VAL: Self = Self::X(42);

results in:

error: `Foo::X` is not yet stable as a const fn

but if the enum is constructed explicitly, the compilation succeeds:

const VAL: Self = Foo::X(42)

Looking at #53555, it looks like Self::EnumVariant should be considered a const fn with min_const_fn.

Playground links for both variants: error, no-error
@Centril
Copy link
Contributor

Centril commented Sep 7, 2019

Duplicate of #61456 (will close in a bit).

@oli-obk It seems like folks open this issue because on stable, the error message does not point to the tracking issue, e.g. you don't see:

  = note: for more information, see https://github.com/rust-lang/rust/issues/61456

can we fix this?

@Centril Centril added A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) A-const-fn A-diagnostics Area: Messages for errors, warnings, and lints C-feature-request Category: A feature request, i.e: not implemented / a PR. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-lang Relevant to the language team, which will review and decide on the PR/issue. labels Sep 7, 2019
@oli-obk
Copy link
Contributor

oli-obk commented Sep 7, 2019

I think we should just stabilize it

@Centril
Copy link
Contributor

Centril commented Sep 7, 2019

@oli-obk Is this diagnostics problem specific to this feature gate? I meant a more general fix to const-fn related gates.

@Centril Centril closed this as completed Sep 7, 2019
@oli-obk
Copy link
Contributor

oli-obk commented Sep 7, 2019

Not sure. I thought we're using the normal feature gate infra

@matthewjasper matthewjasper mentioned this issue Sep 15, 2019
Closed
@Centril
Copy link
Contributor

Centril commented Sep 15, 2019

Reopening this to make sure we add a test per #61456 (comment).

@Centril Centril reopened this Sep 15, 2019
@marmistrz marmistrz mentioned this issue Oct 3, 2019
Closed
@matthewjasper matthewjasper mentioned this issue Oct 7, 2019
Merged
bors added a commit that referenced this issue Oct 27, 2019
@bors
Auto merge of #65188 - matthewjasper:stabilize-const-constructor, r=C…
077619e 
…entril

Stabilize `const_constructor`

# Stabilization proposal

I propose that we stabilize `#![feature(const_constructor)]`.

Tracking issue: #61456
Version target: 1.40 (2019-11-05 => beta, 2019-12-19 => stable).

## What is stabilized

### User guide

Tuple struct and tuple variant constructors are now considered to be constant functions. As such a call expression where the callee has a tuple struct or variant constructor "function item" type can be called:

```rust
const fn make_options() {
    // These already work because they are special cased:
    Some(0);
    (Option::Some)(1);
    // These also work now:
    let f = Option::Some;
    f(2);
    {Option::Some}(3);
    <Option<_>>::Some(5);
}
```

### Motivation

Consistency with other `const fn`. Consistency between syntactic path forms.

This should also ensure that constructors implement `const Fn` traits and can be coerced to `const fn` function pointers, if they are introduced.

## Tests

* [ui/consts/const_constructor/const-construct-call.rs](https://github.com/rust-lang/rust/blob/0d75ab2293a106eb674ac01860910cfc1580837e/src/test/ui/consts/const_constructor/const-construct-call.rs) - Tests various syntactic forms, use in both `const fn` and `const` items, and constructors in both the current and extern crates.
* [ui/consts/const_constructor/const_constructor_qpath.rs](https://github.com/rust-lang/rust/blob/1850dfcdabf8258a1f023f26c2c59e96b869dd95/src/test/ui/consts/const_constructor/const_constructor_qpath.rs) - Tests that type qualified paths to enum variants are also considered to be `const fn`.(#64247)

r? @oli-obk

Closes #61456
Closes  #64247
@bors bors closed this as completed in 03a50ae Oct 28, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) A-diagnostics Area: Messages for errors, warnings, and lints C-feature-request Category: A feature request, i.e: not implemented / a PR. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Stabilize const_constructor matthewjasper/rust
3 participants
@oli-obk @Centril @marmistrz