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

Match compilers dummy loc #540

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

patricoferris
Copy link
Collaborator

A fix as per #532.

I tested reverse dependencies (I think most of them, for their latest version) and they mostly installed --with-test. Any that didn't seemed unrelated.

Copy link
Collaborator

@NathanReb NathanReb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me!

This probably needs a changelog entry!

@NathanReb
Copy link
Collaborator

Seems some tests need to be updated as well!

@NathanReb
Copy link
Collaborator

Also, rebasing it will reduce the diff as the quoter tests don't print out the whole AST anymore!

@patricoferris patricoferris force-pushed the match-compilers-dummy-loc branch 2 times, most recently from a4e858c to 4aad4e6 Compare November 26, 2024 14:43
@patricoferris
Copy link
Collaborator Author

Turns out this actually changed in OCaml compiler versions, so this is not the proper fix.

The fix might be fairly easy (using Cinaps) but the problem becomes all of the expect tests. And whilst we could in theory do the [%%expect_in] stuff I think our tests become less and less useful the longer they get and they're filled with none locations. It would be great to run Toploop.execute_phrase and then parse values and use Pp_ast on them... Any ideas @NathanReb ?

@NathanReb
Copy link
Collaborator

I guess we could use [%%ignore] here, similar to what I did for the Quoter tests:

let x = [%expr ...]
[%%ignore]

let () = Pp_ast.Default.expression x
[%%expect {|
...
|}]

Would that work for you?

@patricoferris patricoferris force-pushed the match-compilers-dummy-loc branch 3 times, most recently from 5936109 to 0549bd1 Compare November 28, 2024 00:22
@patricoferris
Copy link
Collaborator Author

It actually turns out I don't need that @NathanReb -- the files are only enabled for new enough compilers that it doesn't matter. But it is good to have that trick up my sleeve should we need it. Happy to make that change here to help future proof these tests (but I don't think it is likely for those bits to change too much).

Copy link
Collaborator

@NathanReb NathanReb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I understood the issue correctly, the important part is to agree with the compiler on what is Location.none right?

If so then we could probably simply stick to using the compiler's functions to build none locs.

This won't work when reading AST emitted by a different compiler (which we in theory support) but even that could be fixed by versioning the none loc.

As I'm writing this I wonder if the right fix isn't the following:

  1. Stick to having our stable Location.none and choose a convention for it
  2. Have a function that detects whether a location is a valid none loc from any version we support
  3. Use the function from 2 instead of poly = in our codebase

What do you think?

astlib/location.mli Outdated Show resolved Hide resolved
src/location.ml Outdated Show resolved Hide resolved
@patricoferris patricoferris force-pushed the match-compilers-dummy-loc branch 3 times, most recently from 139d7e1 to dfd2058 Compare December 11, 2024 09:57
Location.none has been changed to match the compiler's Location.none as
of OCaml 4.08. This has been stable for some time. We also provide a
Location.is_none which checks if a location is equal to Location.none
for all versions of the compiler we currently support (i.e. >= 4.04).

The decision to change Location.none has been made to enable the code to
be simplified if we decide to change the lower bound of ppxlib to 4.08
in the future.

Location.is_none has been used to fix loc_of_attribute which would
sometimes miss attributes with none locations (like compiler inserted
ocaml.doc attributes).

Signed-off-by: Patrick Ferris <[email protected]>
@patricoferris patricoferris force-pushed the match-compilers-dummy-loc branch from dfd2058 to 2a158e9 Compare December 11, 2024 09:57
@patricoferris
Copy link
Collaborator Author

After some discussion with @NathanReb this PR now does the following:

Location.none has been changed to match the compiler's Location.none as
of OCaml 4.08. This has been stable for some time. We also provide a
Location.is_none which checks if a location is equal to Location.none
for all versions of the compiler we currently support (i.e. >= 4.04).

The decision to change Location.none has been made to enable the code to
be simplified if we decide to change the lower bound of ppxlib to 4.08
in the future.

Location.is_none has been used to fix loc_of_attribute which would
sometimes miss attributes with none locations (like compiler inserted
ocaml.doc attributes). There is a test for this fix.

Signed-off-by: Patrick Ferris <[email protected]>
@patricoferris
Copy link
Collaborator Author

The current errors we're seeing on 4.04 and 4.05 are due to newer compiler versions checking of a line number is "valid" or not (i.e. > 0) and replacing it with 1 if not... https://github.com/ocaml/ocaml/blob/7a9d83047450e337ff31f3d73e5c2d9af66bd363/parsing/location.ml#L214

On the older compilers, the location is used directly, hence we are getting 0 with this new change. Possible solutions are to:

  • manually change the line number location
  • revert back to making Location.none match the compiler's Location.none

any thoughts @NathanReb ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants