Remove res.namedArgLoc attribute and store the location information directly into the label.

[cristianoc]

Instead of the attribute res.namedArgLoc, there's now Asttypes.arg_label_loc to store labels with location.

[github-actions]

⚠️ Performance Alert ⚠️

Possible performance regression was detected for benchmark 'Syntax Benchmarks'.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 1.05.

Benchmark suite	Current: 0e03792	Previous: e1b7fb7	Ratio
Parse RedBlackTree.res - time/run	1.357723 ms	1.2123143266666667 ms	1.12
Parse Napkinscript.res - time/run	42.30374833333333 ms	39.28006235333333 ms	1.08
Parse HeroGraphic.res - time/run	5.706828313333333 ms	5.13472718 ms	1.11

This comment was automatically generated by workflow using github-action-benchmark.

[nojaf]

So, for my understanding, this moves the location from @res.namedArgLoc to named argument node?

[cristianoc]

So, for my understanding, this moves the location from @res.namedArgLoc to named argument node?

Yes. It's been used in different ast nodes. The current state of the PR covers a subset of them.

[nojaf]

Sorry to nitpick, but is there any rational for these shorter names?
As a novice to all this, I'd say it make it all a bit more obscure.
But perhaps this has a reason.

[cristianoc]

No special plan for naming at the moment.
The situation is there's an existing variant type, without locations on labels.
Here I have introduced a new variant type, with locations.
The old type still exists, as labels are used e.g. in Tarrow in types.mli, and those are generated by the compiler without reference to any source location (e.g. via unification or other reasons).

So for now I have different variant names for the new type definition, as there are quite a few places where the type is inferred by the name.
One could have 2 types with identical variants names, though that might actually add more confusion (and need to explicitly add more type annotations to indicate which type is intended).
One could try to make the payload of labelled case a type variable, to be instantiated with either string or a string plus location depending on context. I haven't tried this, not sure how that would look.

[cristianoc]

One could also use a single type and stuff a lot of Location.none when that type is not supposed to have a location. Not particularly keen on that as it becomes unclear where to expect a location and where not.

[cristianoc]

Here is how things look when using identical variant names for the two types: with and without locations: #7254

[cknitt]

One could have 2 types with identical variants names, though that might actually add more confusion (and need to explicitly add more type annotations to indicate which type is intended).

I also think this probably causes more confusion.

Another idea might be to use some prefix for disambiguation, similar to Pexp_xxx vs. Texp_xxx etc. Like Lloc_label / Lloc_nolabel vs. the existing Label / Nolabel.