[libcxx-commits] [PATCH] D99290: [libc++] Update contributor documentation.

[Mark de Wever via Phabricator via libcxx-commits]

Mordante added inline comments.


================
Comment at: libcxx/docs/Contributing.rst:49
+headers           An array with the headers that should provide the
+                  feature-test macro.
+depends           An optional string field. When this field is provided
----------------
Quuxplusone wrote:
> Mordante wrote:
> > Quuxplusone wrote:
> > > Note that `values` and `headers` are both coarser-grained than we really need, these days. Because the macros really correspond to //papers//, not //versions of the standard//; and the `values` can have multiple appropriate settings depending on which paper(s) are implemented. This is a long-standing problem with the script, and totally not your doing. But if we're updating the README to explain about the script, I think it should at least gesture in the direction of "these variables do not directly correspond to anything in WG21's system of feature macros and some fudging may be necessary."
> > I'm aware of this issue, just tried to ignore it in the documentation. I don't think we have a good solution for it at the moment. And I'm not sure what the best solution will be, but I think it would be best to tackle it when it becomes an issue. Or do we already have this issue?
> This past month (i.e. since I started paying attention) I've seen D96385:
> ```
>     "name": "__cpp_lib_constexpr_string",
>     "values": { "c++20": 201811 },  # because P1032R1 is implemented; but should become 201907 after P0980R1
>     "headers": ["string"],
> ```
> and also D97394:
> ```
>     "name": "__cpp_lib_variant",
>     "values": { "c++17": 202102 },
>     "headers": ["variant"],
> ```
Thanks for the examples Arthur!
In that case maybe we should look at how to add support for this. I assume it can happen that:
P1234 adds `__cpp_lib_foo` `202103L` and isn't implemented.
P1235 adds `__cpp_lib_foo` `202106L` and is implemented.
Which will be interesting.

Since the issue seems more realistic than I expected I think we should think of a solution. IMO this means we need to modify the script. However I think that should be a separate commit and we should have a discussion about the requirements before creating a solution.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D99290/new/

https://reviews.llvm.org/D99290