You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The root cause is that we treat the lambda expressions in __is_derived_from_optional as different expressions in module m:a and m:b. This may be related to #57222
The text was updated successfully, but these errors were encountered:
…tionally
Closellvm/llvm-project#63544.
Background: We landed std modules in libcxx recently but we haven't
landed the corresponding in-tree tests. According to @mordante, there
are only 1% libcxx tests failing with std modules. And the major
blocking issue is the lambda expression in the require clauses.
The root cause of the issue is that previously we never consider any
lambda expression as the same. Per [temp.over.link]p5:
> Two lambda-expressions are never considered equivalent.
I thought this is an oversight at first but @rsmith explains that in the
wording, the program is as if there is only a single definition, and a
single lambda-expression. So we don't need worry about this in the spec.
The explanation makes sense. But it didn't reflect to the implementation
directly.
Here is a cycle in the implementation. If we want to merge two
definitions, we need to make sure its implementation are the same. But
according to the explanation above, we need to judge if two
lambda-expression are the same by looking at its parent definitions. So
here is the problem.
To solve the problem, I think we have to profile the lambda expressions
actually to get the accurate information. But we can't do this
universally. So in this patch I tried to modify the interface of
`Stmt::Profile` and only profile the lambda expression during the
process of merging the constraint expressions.
Differential Revision: https://reviews.llvm.org/D153957
This comes from #63530. I file this to track the issue in the compiler side.
Reproducer:
The root cause is that we treat the lambda expressions in
__is_derived_from_optional
as different expressions in modulem:a
andm:b
. This may be related to #57222The text was updated successfully, but these errors were encountered: