Before this patch, we had visitRecordInitializer() and
visitArrayInitializer(), which were different from the regular visit()
in that they expected a pointer on the top of the stack, which they
initialized. For example, visitArrayInitializer handled InitListExprs by
looping over the members and initializing the elements of that pointer.
However, this had a few corner cases and problems. For example, in
visitLambdaExpr() (a lambda is always of record type), it was not clear
whether we should always create a new local variable to save the lambda
to, or not. This is why https://reviews.llvm.org/D153616 changed
things around.
This patch changes the visiting functions to:
- visit(): Always leaves a new value on the stack. If the expression
can be mapped to a primitive type, it's just visited and the value is
put on the stack. If it's of composite type, this function will
create a local variable for the expression value and call
visitInitializer(). The pointer to the local variable will stay on
the stack.
- visitInitializer(): Visits the given expression, assuming there is a
pointer on top of the stack that will be initialized by it.
- discard(): Visit the expression for side-effects, but don't leave a
value on the stack.
It also adds an additional Initializing flag to differentiate between the initializing and non-initializing case.
Differential Revision: https://reviews.llvm.org/D156027
We only did this for primitive temporaries.
Unfortunately, the existing Pointer::toAPValue() won't do here, since
we're expected to set an rvalue on the LifetimeExtendedTemporaryDecl.
Differential Revision: https://reviews.llvm.org/D144457
We pass these as pointers, so we need to be careful not to emit pointers
to pointers when we emit visit DeclRefExprs pointing to parameters.
Differential Revision: https://reviews.llvm.org/D153695
For some builtins, we need to do quite a bit of type checking ourselves,
so pass the call expression along. This way we can inspect arguments,
expected return value, etc.
Differential Revision: https://reviews.llvm.org/D155545
We didn't call the function explicitly in a static_assert() statement
and the checkPotentialConstantExpression() invocation quietly aborted
early because of the missing initializer for A::a.
Fix this by calling ignoredExprs() explicitly.
Differential Revision: https://reviews.llvm.org/D149965
Ignore the expressions and re-do the tests without all the "result
ignored" expected warnings. Those are expected, given the nature of the
tests.
Differential Revision: https://reviews.llvm.org/D149831
We will use this opcode for conditionally executed statements that are
invalid in a constant expression.
Differential Revision: https://reviews.llvm.org/D150364
First, we need to handle void types in visitExpr, so we don't run into
an assertion there when we try to pop a return value from the stack
that isn't there.
Secondly, we need to handle it when visiting comma expressions so we
don't do the same thing there.
Differential Revision: https://reviews.llvm.org/D148925
Our comparison opcodes always produce a Boolean value and push it on the
stack. However, the result of such a comparison in C is int, so the
later code expects an integer value on the stack.
Work around this problem by casting the boolean value to int in those
cases. This is not ideal for C however. The comparison is usually
wrapped in a IntegerToBool cast anyway.
Differential Revision: https://reviews.llvm.org/D149645
Our comparison opcodes always produce a Boolean value and push it on the
stack. However, the result of such a comparison in C is int, so the
later code expects an integer value on the stack.
Work around this problem by casting the boolean value to int in those
cases. This is not ideal for C however. The comparison is usually
wrapped in a IntegerToBool cast anyway.
Differential Revision: https://reviews.llvm.org/D149645
We might classify different clang types to the same interp types, so
skip the cast in that case.
No test attached since this is already exercised a few times in the
existing tests.
Our Zero opcode only exists for integer types. Use
visitZeroInitializer() here as well so it works for floats and pointers.
Differential Revision: https://reviews.llvm.org/D149059
The given expression is not necessarily usable to obtain a type for,
so we can't use it to get the floating point semantics. Pass a QualType
instead, which we can use--and classify() that here.
