[go: up one dir, main page]

Proto/Compiler: fix attributes reported as unused in OCaml5

What

Mark builtin attributes as used during the first parsing phase.

Why

Citing myself from the code:

          (* Starting OCaml 5.2, attributes are accumulated during parsing and
             marked as used during typechecking. As parsing only is not
             supported by the OCaml compiler (and especially calling the
             compiler in different mode during the same execution), there is no
             rule to cleanup the table of unused builtin attributes if
             typechecking is never reached. This shouldn't be an issue to parse
             a file twice as the attributes are registered by their location,
             thus the first occurence would be replaced. However in the case of
             the protocol compiler the files are repacked into a single functor,
             which effectively changes their location. As a result, the previous
             locations are never cleaned up and the attributes will eventually be
             declared as unused. As such they need to be marked as used. *)

How

During the first parsing phase, call Builtin_attribute.select_attribute on each attribute to force it being marking used. Since the change is only necessary starting 5.2 (and the API doesn't exist before 5.2), the MR introduces another compatibility file (although not necessary, if we assume that we will skip OCaml 5.(0|1), then it can be safely removed).

Manually testing the MR

  1. First, run the CI on this MR, and check the protocol compiler still works: dune build @runtest_compile_protocol.
  2. On the branch OCaml5, try to compile it and check the patch work. Then remove the patch from the branch and look at the errors when compiling protocols higher than proto_011.

Checklist

  • Document the interface of any function added or modified (see the coding guidelines)
  • Document any change to the user interface, including configuration parameters (see node configuration)
  • Provide automatic testing (see the testing guide).
  • For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
  • Select suitable reviewers using the Reviewers field below.
  • Select as Assignee the next person who should take action on that MR

Merge request reports

Loading