-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Closed
Labels
A-const-evalArea: Constant evaluation, covers all const contexts (static, const fn, ...)Area: Constant evaluation, covers all const contexts (static, const fn, ...)A-diagnosticsArea: Messages for errors, warnings, and lintsArea: Messages for errors, warnings, and lintsD-confusingDiagnostics: Confusing error or lint that should be reworked.Diagnostics: Confusing error or lint that should be reworked.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Description
Given the following code: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=bc51fb79544b1be00dd8a4285103ff07
const fn foo(input: &'static str) {
match input {
"a" => (),
_ => (),
}
}
The current output is:
error[E0015]: calls in constant functions are limited to constant functions, tuple structs and tuple variants
--> src/lib.rs:3:9
|
3 | "a" => (),
| ^^^
I feel like it's pretty self-explanatory, but this is obviously a very confusing error. A match arm for a string literal is not a "call" by any usual meaning of the word. In fact, I have no idea what actual objection rustc
has to this code, if any.
As far as I can tell, this error is the same on all current versions of the compiler (stable, beta, nightly) per the submission of this issue.
marmeladema, hkmatsumoto, pluiedev, ACenTe25, gruvw and 4 more
Metadata
Metadata
Assignees
Labels
A-const-evalArea: Constant evaluation, covers all const contexts (static, const fn, ...)Area: Constant evaluation, covers all const contexts (static, const fn, ...)A-diagnosticsArea: Messages for errors, warnings, and lintsArea: Messages for errors, warnings, and lintsD-confusingDiagnostics: Confusing error or lint that should be reworked.Diagnostics: Confusing error or lint that should be reworked.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
PatchMixolydic commentedon Oct 25, 2021
I'm not familiar with how matching on
&str
is implemented, so this is pure conjecture, but the "call" might be an implicit call toinput.eq("a")
. The==
operator issues the same confusing diagnostic (playground):@rustbot modify labels: +A-const-eval +D-confusing
detly commentedon Sep 29, 2022
Note also that a byte string literal is fine:
☝️ compiles on 1.64, but
...fails with:
jnnnnn commentedon May 17, 2023
I ran into this as well. It's definitely calling
<str as PartialEq>::eq
as part of the match. The way to prove so is to look at the MIR (and removeconst
so the code compiles).The const_str crate gets around this by converting to bytes for the comparison.
Here's a working example: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=286b897bb518dec6617d3da197cd318b
Note, this seems related to #103040 .
<str as PartialEq>::eq
probably can't beconst
until #67792 lands.PartialEq
call generated bymatch
#112232Rollup merge of rust-lang#112232 - fee1-dead-contrib:match-eq-const-m…
Rollup merge of rust-lang#112232 - fee1-dead-contrib:match-eq-const-m…
Rollup merge of rust-lang#112232 - fee1-dead-contrib:match-eq-const-m…
Rollup merge of rust-lang#112232 - fee1-dead-contrib:match-eq-const-m…