Gabriel Scherer

A status report: - I did implement the alternative `[%atomic.field f]` approach in #13707. - I realized that it does not currently work with inline records, and proposed a relaxation...

No strong enthusiasm from other potential reviewers. My new plan is to wait for @OlivierNicole to return from holidays and conclude his review, and kindly ask @Octachron if this can...

Regarding your review: I believe that the only feature part that you have not reviewed previously is the last commit, "Forbid atomic fields in patterns.", which came after your review...

@clef-men, @OlivierNicole: I have - fixed a test (compiler-libs/test_untypeast.ml) that needed some extra love after the rebase, so maybe the CI passes now (otherwise I'll fix it) - changed the...

(Any non-trivial change goes into a new commit so that it's easy for @OlivierNicole to figure out what to look at.)

I pushed a final change to `stdlib/atomic.mli`: the Loc module is moved to the end of the file, and I added minimal documentation comments. (I tried to include a small...

I propose some documentation of atomic record fields in the reference manual in a separate PR, #13991.

My current thinking on this PR: - Now that @OlivierNicole approved the PR, I believe that it is mergeable and within the pre-approved time frame for backporting into the 5.4...

I'm confused by this PR. - Some commits are called "removed unexposed and unused `foo_retcode` typedef", but in fact the type *is* used in the codebase, apparently to track (as...

Notes on the other commits (skimmed quickly): - I'm happy with changes to use C99 booleans (I think we for now are trying not to use them in the user-facing...