i was confuse because the log seemed like an error and it was happening in python2.7 and python3.7
but the actual error that was preventing generating the documentation only occurs in 3.7.

fixed requested changes.

fixed the issue.

fixed requested changes.
also adapted lldb to AST change.
I will commit this when i have access.

fixed requested changes.
i will commit it when i have access.

@rsmith ping.

fixed requested changes except some i commented upon.

changed as requested.

I closed it originally because it was inactive and i was working on other reviews. but i learned this is not how it is supposed to be done.

@rsmith ping

ping @rsmith

@rsmith friendly ping.

previous revision was spitted in multiple part as requested
consteval specific semantic and code-gen have been removed from the patch.
other parts:

• fixing semantic checking in constant context : https://reviews.llvm.org/D62009
• adding storage for APValue in ConstantExpr : https://reviews.llvm.org/D62399

most comments were fixed. but there is a few point on which the direction isn't clear.

I changed the approach in the last revision. the information is now propagated using the expression evaluation context and then via booleans. I should have added a comment to make it clear.

I checked how we can propagate the information about constant context through semantic checking.
there are issues with using ConstantExpr to mark expressions as constant for semantic checking:

• #1 multpile Expr::Ignore* operation remove ConstantExpr from the expression.
• #2 Semantic checking Traverses the AST so all methods that only mark the top-level Node not will fail.
• #3 at short term: adding ConstantExpr modifies the AST structure, so adding it everywhere it is needed for semantic checking will require changing a lot of code that depend closely on the AST structure.

Note: the limitation #2 also applies to the bit in ExprBitfield solution in its current form.

i added this bit because when we eventually store the result of evaluation in ConstantExpr we will probably want to trail-allocate the APValue's possible representations separately to limit memory consumption. but if we do this the ConstantExpr node will need to be created after evaluation of the value, so we cannot use it to mark that the expression should be evaluated in constant context.
if we won't store APValue's possible representations separately in trail-allocate space, wrapping the expression in a ConstantExpr is the right solution.

code-gen was adapted to consteval.

commited by https://reviews.llvm.org/rGba24f352f4fa47d6caabac3764b8d896d40fb934

could you commit this for me ?

fixed

i am sorry for this issue.
the patch at https://reviews.llvm.org/D60934 have been updated to fix this.

Changes:

• merged with with the adaptation of lldb at https://reviews.llvm.org/rL359966.
• fixed the issue reported at http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20190506/270340.html.
• added the failing code to the test in explicit.cpp

sorry for the inconvenience.

yes i am on it.

could you commit it for me please ?

@rsmith i made the last requested few changes. but i can't push the change.

fixed feedback from @rsmith @Rakete1111.

fixed feedback from @rsmith @Rakete1111 @xbolva00

@rsmith fixed feedbacks

merged similar code for AST serialization of ExplicitSpecifier in a static function

Fixed based on Feedback from @rsmith @martong @Rakete1111.

the llvm-cxxfilt from source wasn't available (i don't know why) so llvm-lit silently fallback on the system one that appear not to support PowerPC.
with llvm-cxxfilt built from source it works correctly.

this test is currently failing on master on my PC. here is the dump of the test failure.

@jkooker
i don't think it is possible for ASTContext::getDependentNameType to deal with NSS = nullptr except by reporting the error. we probably don't want to just report the error because the error could have been handled before invoking ASTContext::getDependentNameType.
and i agree that it should be reflected in the interface of those functions because pointer are often used a optional references. but wouldn't an assert + doxygen comment suffice ? instead of changing the interface, implementation and all callsites. Pointers as argument that are required not to be null are used in a lot of places in LLVM. for example DependentNameType::DependentNameType takes NNS as a pointer even thought it requires it to be non-null(calls a method on it). mixing pointers and references adds a lot of & and * which makes the code harder to read.

Fixed issues form feedback by @martong

@Quuxplusone @riccibruno fixed / answered feedback