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

Tracking issue for RFC 2345, "Allow panicking in constants" (const_panic) #51999

Closed
1 of 5 tasks
Centril opened this issue Jul 2, 2018 · 143 comments · Fixed by #89508
Closed
1 of 5 tasks

Tracking issue for RFC 2345, "Allow panicking in constants" (const_panic) #51999

Centril opened this issue Jul 2, 2018 · 143 comments · Fixed by #89508
Labels
A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. B-RFC-implemented Blocker: Approved by a merged RFC and implemented. B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@Centril
Copy link
Contributor

Centril commented Jul 2, 2018

This is a tracking issue for the RFC "Allow panicking in constants" (rust-lang/rfcs#2345).

Steps:

Unresolved questions:

  • Should there be some additional message in the error about this being a panic turned error?
    Or do we just produce the exact message the panic would produce?

  • This change becomes really useful if Result::unwrap and Option::unwrap become const fn, doing both in one go might be a good idea.

Blockers:

@Centril Centril added B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. T-lang Relevant to the language team, which will review and decide on the PR/issue. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC labels Jul 2, 2018
@clarfonthey
Copy link
Contributor

Don't forget expect and all the other unwrap-like methods. :P

@oli-obk oli-obk added the A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) label Jul 2, 2018
@vi
Copy link
Contributor

vi commented Jul 4, 2018

I suppose unimplemented!() and unreachable!() should also be included?

@SimonSapin
Copy link
Contributor

I think they would be "automatically", since macros don’t have a separation similar to fn v.s. const fn.

@oli-obk
Copy link
Contributor

oli-obk commented Jul 4, 2018

I'll add some tests to #52011, but yes, it just works.

bors added a commit that referenced this issue Aug 22, 2018
…anics_constantly, r=eddyb

Allow panicking with string literal messages inside constants

r? @eddyb

cc #51999

we can't implement things like `panic!("foo: {}", x)` right now because we can't call trait methods (most notably `Display::fmt`) inside constants. Also most of these impls probably have loops and conditions, so it's messy anyway.

But hey `panic!("foo")` works at least.

cc @japaric got any test ideas for `#![no_std]`?
@Centril
Copy link
Contributor Author

Centril commented Sep 15, 2018

Triage: @oli-obk so this is implemented now, right?

@oli-obk
Copy link
Contributor

oli-obk commented Sep 16, 2018

Yes

@Centril Centril added B-unstable Blocker: Implemented in the nightly compiler and unstable. B-RFC-implemented Blocker: Approved by a merged RFC and implemented. labels Sep 18, 2018
@IsaacWoods
Copy link
Contributor

Now this is implemented, is there anything stopping Option::unwrap and friends from becoming const fns (I'm assuming with a rustc_const_unstable(feature = "??"))?

@Centril
Copy link
Contributor Author

Centril commented Oct 19, 2018

@IsaacWoods to my knowledge there shouldn't be anything in the way of that.

@IsaacWoods
Copy link
Contributor

@Centril great! I'll start work on a PR in that case

@clarfonthey
Copy link
Contributor

clarfonthey commented Oct 19, 2018

The thing in the way of that is running fmt::Debug::fmt in const context.

…oh, right, I was thinking in terms of Result::unwrap and Result::expect. Option should be fine.

@IsaacWoods
Copy link
Contributor

On second thoughts, even Option is still blocked I think - I don't think we can use match in const contexts yet either

@oli-obk
Copy link
Contributor

oli-obk commented Oct 19, 2018

Yea, we need conditions in constants first

@Centril
Copy link
Contributor Author

Centril commented Oct 19, 2018

Right; bummer.

@oli-obk Any thoughts about the first unresolved question?

@oli-obk
Copy link
Contributor

oli-obk commented Oct 19, 2018

I'm for basically reporting it verbatim, but having the same prefix (error[0080]:) as all other errors.

@Centril
Copy link
Contributor Author

Centril commented Oct 19, 2018

@oli-obk I like that; (and it's a diagnostics issue anyways, not part of the spec, so it is up to T-compiler to decide this...).

@jhpratt
Copy link
Member

jhpratt commented Jul 30, 2021

Now that #86998 is merged, this should be good to stabilize, correct?

@oli-obk
Copy link
Contributor

oli-obk commented Jul 30, 2021

I'm still unhappy that in 2018 we can do panic!(some_computed_str) but in 2021 we can't do the equivalent, but it seems better to only allow literal strings for now than to not allow any custom panicking. Imo this is purely a T-libs issue, but I'll let @rust-lang/wg-const-eval weigh in on that before escalating to T-libs for stabilization.

@RalfJung
Copy link
Member

it seems better to only allow literal strings for now than to not allow any custom panicking

👍 as long as this is enforced properly(i.e. everything accepted in 2018 on stable also works in 2021).

@oli-obk
Copy link
Contributor

oli-obk commented Jul 30, 2021

it is not yet. Not sure how doable that is, it may be easier to just figure out how to do panic!("{}", some_computed_str) on all editions.

@abonander
Copy link
Contributor

For our planned usage of this feature in SQLx we would really prefer either support for formatting or being able to compute panic strings. We can sorta work around it if the panic strings need to be literals but it won't be the greatest.

@clarfonthey
Copy link
Contributor

One thing that I noticed which kind of sucks: this being unstable means that you can't use todo!() in consts. Although I understand not wanting to stabilise that so that people don't use it instead of panic.

GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue Sep 17, 2021
Allow `panic!("{}", computed_str)` in const fn.

Special-case `panic!("{}", arg)` and translate it to `panic_display(&arg)`. `panic_display` will behave like `panic_any` in cosnt eval and behave like `panic!(format_args!("{}", arg))` in runtime.

This should bring Rust 2015 and 2021 to feature parity in terms of `const_panic`; and hopefully would unblock the stabilisation of rust-lang#51999.

`@rustbot` modify labels: +T-compiler +T-libs +A-const-eval +A-const-fn

r? `@oli-obk`
Manishearth added a commit to Manishearth/rust that referenced this issue Oct 4, 2021
…shtriplett

Stabilize `const_panic`

Closes rust-lang#51999

FCP completed in rust-lang#89006

`@rustbot` label +A-const-eval +A-const-fn +T-lang

cc `@oli-obk` for review (not `r?`'ing as not on lang team)
Manishearth added a commit to Manishearth/rust that referenced this issue Oct 4, 2021
…shtriplett

Stabilize `const_panic`

Closes rust-lang#51999

FCP completed in rust-lang#89006

``@rustbot`` label +A-const-eval +A-const-fn +T-lang

cc ``@oli-obk`` for review (not `r?`'ing as not on lang team)
@bors bors closed this as completed in 9866b09 Oct 4, 2021
@rodrimati1992
Copy link
Contributor

rodrimati1992 commented Oct 16, 2021

I've noticed that you can use a non-static foo: &str as an argument to panic!("{}", foo), is it intentional that it doesn't require a 'static one?
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=8bd048da90965a526dbc98d187f56c56

const _: () = {
    let arr = [b'b', b'y', b'e'];
    let msg: &str = unsafe{ std::str::from_utf8_unchecked(&arr) };

    panic!("{}", msg)
};

if it is intentional, I have an idea for how to implement const panics with bounded-length formatted arguments in a library.

@oli-obk
Copy link
Contributor

oli-obk commented Oct 16, 2021

Yes this is intentional. Getting that to work was actually a blocker for stabilization.

XrXr added a commit to XrXr/reference that referenced this issue Dec 24, 2021
Since const panics are now [stabilized], I figure it would be good to
document some of its gotchas. I couldn't really find documents for
the specifics I ran into. I am no const eval expert, and what I
wrote is basically a paraphrase of Ralf's comments[^1][^2],
but I hope to get the ball rolling for adding some docs.

I deliberately chose to not mention the guarantee about syntactically
referenced constants in functions that require code generation as it
seems hard to explain completely without some ambiguity. It also seems
to me that the rules are not completely stable[^3][^4] yet.

[stabilized]: rust-lang/rust#89006
[^1]: rust-lang/rust#91877 (comment)
[^2]: rust-lang/rust#91877 (comment)
[^3]: rust-lang/rust#71800
[^4]: rust-lang/rust#51999 (comment)
XrXr added a commit to XrXr/reference that referenced this issue Dec 24, 2021
Since const panics are now [stabilized], I figure it would be good to
document some of its gotchas. I couldn't really find documents for
the specifics I ran into. I am no const eval expert, and what I
wrote is basically a paraphrase of Ralf's comments[^1][^2],
but I hope to get the ball rolling for adding some docs.

I deliberately chose to not mention the guarantee about syntactically
referenced constants in functions that require code generation as it
seems hard to explain completely without some ambiguity. It also seems
to me that the rules are not completely stable[^3][^4] yet.

[stabilized]: rust-lang/rust#89006
[^1]: rust-lang/rust#91877 (comment)
[^2]: rust-lang/rust#91877 (comment)
[^3]: rust-lang/rust#71800
[^4]: rust-lang/rust#51999 (comment)
@tmandry
Copy link
Member

tmandry commented Mar 4, 2022

Is there an issue tracking support for non-&str panic arguments in consts?

Right now the compiler just gives an error (implemented in #80734) "argument to panic!() in a const context must have type &str", but there's no error code or other explanation text.

The RFC doesn't mention this limitation.

@oli-obk
Copy link
Contributor

oli-obk commented Mar 4, 2022

There's no special tracking for it. It's essentially just blocked on the fact that you can't implement Display or Debug in a way that is callable in a const context.

@rodrigocfd
Copy link

Damn, I just stumbled upon a situation where a I need a fallible enum construction, like this one:

const fn parse_bool(s: &str) -> bool {
    match s {
        "true" => true,
        "false" => false,
        other => panic!("`{}` is not a valid bool", other), // CAN'T DO THAT!
    }
}

Time to refactor a huge workaround 😞

I really hope this issue can be fixed, I have so many other situations where it would make my design correct.

@golddranks
Copy link
Contributor

@rodrigocfd You can already panic in const fns, you just can't use string formatting machinery yet. Remove the {} and , other and the panic part compiles. However, &str matching doesn't seem to work in const fns yet, as that requires const-agnostic traits.

Also a side note, panicing is a bit suspect strategy if you are expecting the matching to fail with some inputs.

This is a closed tracking issue for panics in const and not meant for general discussion, if you need help within the current capabilities of the compiler, try https://users.rust-lang.org or https://www.reddit.com/r/rust/

@rodrigocfd
Copy link

@golddranks thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. B-RFC-implemented Blocker: Approved by a merged RFC and implemented. B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.