On Thu, Jan 23, 2025 at 04:47:32PM -0500, Jason Merrill wrote:
> On 1/6/25 7:24 AM, Nathaniel Shead wrote:
> > Happy to defer this till GCC16 if preferred.
> >
> > -- >8 --
> >
> > This fills in a hole left in r15-6378-g9016c5ac94c557 with regards to
> > detection of TU-local lambdas. Now that LAMBDA_EXPR_EXTRA_SCOPE is
> > properly set for most lambdas we can use it to detect lambdas that are
> > TU-local.
> >
> > Lambdas in concept definitions I believe should not be considered
> > TU-local, since they are always unevaluated and should never be emitted.
>
> It seems to me that they are also TU-local under
> https://eel.is/c++draft/basic#link-15.2 . It might be feasible to change
> that, but that is the status quo.
>
> Jason
>
Right, sorry I wasn't clear; I agree that this is the status quo, I just
think that we should accept them; otherwise, currently we would reject
exporting any concept with a lambda contained within it, which seems
needless hostile (and causes a number of tests to fail).
In particular, lambdas within concepts are actually made use of within
the standard library, e.g. optional:1683, so we would either need to
continue to allow this to work somehow (either via mangling scope or a
new flag on the lambda, because there's no other way I was able to find
of determining this), or rewrite the concept to not use a lambda.
// _GLIBCXX_RESOLVE_LIB_DEFECTS
// 3746. optional's spaceship with U with a type derived from optional
// causes infinite constraint meta-recursion
template<typename _Tp>
concept __is_derived_from_optional = requires (const _Tp& __t) {
[]<typename _Up>(const optional<_Up>&){ }(__t);
};
Nathaniel
