ping @rsmith

ping @rsmith

@rsmith ping

ping @rsmith

fixed the comment for good, sorry for that.

fixed comment typo.

Change:

• Add support for LValue, MemberPointer and AddrDiffExpr.
• Add tests for importing.

ping @rsmith

made the requested changes.

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 ?