-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Rename cstrs to constraints to distinguish from cstrs = constructors #14141
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
base: trunk
Are you sure you want to change the base?
Conversation
See also: #13856 (comment) |
This is clearly an improvement to my eyes.
My understanding is that nowadays |
Nice, I've modified the parsetree as well. I will try to find any other instances and then mark the PR as ready for review |
And here I thought that @nojb had transcended to a higher plane of existence where variable naming does not matter anymore... I agree this is a clear improvement. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
(The CI failure seems unrelated to the changes here.) |
Should we merge this one? |
Yes, as soon as the CI passes. |
Currently, the compiler codebase uses
cstr
for constructor andcstrs
for both constraints and constructors.This is both confusing and makes it difficult to search the code (see below for an example of confusion).
This PR renames any instances of
cstrs
that refer to constraints toconstraints
, and leaves any references to constructors alone. The parsetree is not modified, since I gather that this is more complicated.In
typing/typdecl.ml
, we have some example wherecstrs
is used for both constructors and constraints. For example, in the functiontransl_declaration
, we alternate between usingcstrs
to refer to constraints and constructors.