diff options
author | Richard Smith <richard-llvm@metafoo.co.uk> | 2017-01-07 00:48:55 +0000 |
---|---|---|
committer | Richard Smith <richard-llvm@metafoo.co.uk> | 2017-01-07 00:48:55 +0000 |
commit | d6a150829b04a63bdcc9bafe4fb7faa0e96a9df5 (patch) | |
tree | 005efe470ff275402614d3bbda5bb9036f67c11f /lldb/packages/Python/lldbsuite/test/python_api | |
parent | 598861f661d90a87a4c6bec230b00386fa962da5 (diff) | |
download | bcm5719-llvm-d6a150829b04a63bdcc9bafe4fb7faa0e96a9df5.tar.gz bcm5719-llvm-d6a150829b04a63bdcc9bafe4fb7faa0e96a9df5.zip |
PR23135: Don't instantiate constexpr functions referenced in unevaluated operands where possible.
This implements something like the current direction of DR1581: we use a narrow
syntactic check to determine the set of places where a constant expression
could be evaluated, and only instantiate a constexpr function or variable if
it's referenced in one of those contexts, or is odr-used.
It's not yet clear whether this is the right set of syntactic locations; we
currently consider all contexts within templates that would result in odr-uses
after instantiation, and contexts within list-initialization (narrowing
conversions take another victim...), as requiring instantiation. We could in
principle restrict the former cases more (only const integral / reference
variable initializers, and contexts in which a constant expression is required,
perhaps). However, this is sufficient to allow us to accept libstdc++ code,
which relies on GCC's behavior (which appears to be somewhat similar to this
approach).
llvm-svn: 291318
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test/python_api')
0 files changed, 0 insertions, 0 deletions