Skip to content

Make pointer_structural_match normal and warn#110166

Closed
est31 wants to merge 2 commits intorust-lang:masterfrom
est31:pointer_structural_match
Closed

Make pointer_structural_match normal and warn#110166
est31 wants to merge 2 commits intorust-lang:masterfrom
est31:pointer_structural_match

Conversation

@est31
Copy link
Copy Markdown
Member

@est31 est31 commented Apr 11, 2023

This PR does two things:

  • Changes the default level of pointer_structural_match from allow to warn
  • Turns pointer_structural_match into a normal lint instead of being a forward compatibility lint

The pointer_structural_match lint was added in #70743 to look for code that matches on a function pointer. As pointed out in #70861, and #54685, LLVM's behaviour makes function pointers behave in unexpected ways: function pointers might not be equal to "themselves" if function pointers for the same function were created in two different crates, and on the other hand, two different functions might end up with the same address if LLVM detects that they have the same body. See the linked issues for examples.

Thus, in #70743 an allow-by-default forward compatibility lint was added to address matching on pointers.

In #70861 (comment) preferences were expressed that there should be a lint for matching on function pointers, but it should not be disallowed completely. I'd interpret that as wanting a warn-by-default non forward compatibility lint. Therefore, there are two possible ways forward:

  • turn pointer_structural_match into a normal lint that's not a forward compatibility lint, and make it warn by default, OR
  • keep it as a forward compatibility lint, to eventually forbid it via a compiler error, but first make it warn by default, then deny by default.

I think one should at least do one of the two things, even if it is only going to be a warning lint in the end.

The lang team has given the green light for the first approach. There is still the possibility that it will be forbidden in the future, but this will require concrete deprecation plans which don't exist right now.

cc @eddyb @pnkfelix @oli-obk

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-lang Relevant to the language team

Projects

None yet

Development

Successfully merging this pull request may close these issues.