Tracking issue for `illegal_floating_point_constant_pattern` compatibility lint

[petrochenkov]

This is the summary issue for the illegal_floating_point_constant_pattern
future-compatibility warning and other related errors. The goal of
this page is describe why this change was made and how you can fix
code that is affected by it. It also provides a place to ask questions
or register a complaint if you feel the change should not be made. For
more information on the policy around future-compatibility warnings,
see our breaking change policy guidelines.

What is the warning for?

Rust 1.0 accepted a number of patterns -- and in particular accepted constant in patterns --
in a broader range of situations that was originally intended. RFC 1445 spelled out
some restrictions on what kinds of constants can be used in patterns, at least until the
final semantics are affirmatively decided. Among the changes was the ruling that floating
point values should not be usable in patterns.

This means that a match like this:

match foo() {
    3.0 => ...,
    _ => ...
}

should be written to:

match foo() {
    x if x == 3.0 => ...,
    _ => ...
}

Among other things, this clarifies that the semantics are the same as == normally uses. So e.g. 0 and -0 compare equal, and NaN compares unequal to everything (including itself).

When will this warning become a hard error?

At the beginning of each 6-week release cycle, the Rust compiler team
will review the set of outstanding future compatibility warnings and
nominate some of them for Final Comment Period. Toward the end of
the cycle, we will review any comments and make a final determination
whether to convert the warning into a hard error or remove it
entirely.

Current status

• Restrict constants in patterns #32199 introduces the illegal_floating_point_constant_pattern lint as warn-by-default
• Make sufficiently old or low-impact compatibility lints deny-by-default #36894 makes the illegal_floating_point_constant_pattern lint deny-by-default
• Turn sufficiently old compatibility lints into hard errors #42136 makes the illegal_floating_point_constant_pattern lint a hard error # # #

[petrochenkov]

@nikomatsakis, could you write a description for this?

[nikomatsakis]

@petrochenkov done

[carols10cents]

I'm confused... I'm working on documenting patterns in the book. This issue's description seems to indicate that this code:

match foo() {
    3.0 => ...,
    _ => ...
}

should currently cause an error (since the lints have now become hard errors).

However, this code using floating point literals currently works just fine without any errors or warnings and with the expected behavior. It's only if I put the floating point value in a constant that I get the error mentioned in this tracking issue.

So what was the intent here? Only to disallow matching on floating point constants, in which case rustc is correct and this issue's description is incorrect, or to disallow matching on floating point literals, in which case this issue's description is correct and rustc's current implementation is incorrect...?

[nikomatsakis]

@carols10cents argh, that...seems like a rather glaring oversight! I think the intention was not to accept those examples!

[carols10cents]

Yay, I found a bug!!! Uhhh... i mean... boo, a bug! ;)

Should I file a new issue or is this issue sufficient...?

[nikomatsakis]

@carols10cents sigh. I suppose a new issue would be helpful.

[carols10cents]

Done! #41255

[SimonSapin]

RFC 1445 spelled out some restrictions on what kinds of constants can be used in patterns, at least until the final semantics are affirmatively decided.

All the language changes that I can find mandated in https://github.com/rust-lang/rfcs/blob/master/text/1445-restrict-constants-in-patterns.md are about using in patterns const constants of struct or enum types.

Among the changes was the ruling that floating point values should not be usable in patterns.

This breaking change is not part of an accepted RFC, as far as I can tell. The only part of RFC 1445 that mentions struct literals is one example in the motivation section. Am I missing something?

#32199 introduces the illegal_floating_point_constant_pattern lint as warn-by-default
#36894 makes the illegal_floating_point_constant_pattern lint deny-by-default

Is that accurate? These PRs merged in 2016 but Servo’s code that using float literals in pattern started breaking today, presumably with #41293.