Commit Graph

8 Commits

Author SHA1 Message Date
Corentin Jabot 131b4620ee Implement P1937 consteval in unevaluated contexts
In an unevaluated contexts, consteval functions should not be
immediately evaluated.
2021-08-06 10:29:28 -04:00
Richard Smith 24cdcadcc5 C++ DR712 and others: handle non-odr-use resulting from an lvalue-to-rvalue conversion applied to a member access or similar not-quite-trivial lvalue expression.
Summary:
When a variable is named in a context where we can't directly emit a
reference to it (because we don't know for sure that it's going to be
defined, or it's from an enclosing function and not captured, or the
reference might not "work" for some reason), we emit a copy of the
variable as a global and use that for the known-to-be-read-only access.

This reinstates r363295, reverted in r363352, with a fix for PR42276:
we now produce a proper name for a non-odr-use reference to a static
constexpr data member. The name <mangled-name>.const is used in that
case; such names are reserved to the implementation for cases such as
this and should demangle nicely.

Reviewers: rjmccall

Subscribers: jdoerfert, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D63157

llvm-svn: 363428
2019-06-14 17:46:37 +00:00
Nico Weber 3d02b895ed Revert 363295, it caused PR42276. Also revert follow-ups 363337, 363340.
Revert 363340 "Remove unused SK_LValueToRValue initialization step."
Revert 363337 "PR23833, DR2140: an lvalue-to-rvalue conversion on a glvalue of type"
Revert 363295 "C++ DR712 and others: handle non-odr-use resulting from an lvalue-to-rvalue conversion applied to a member access or similar not-quite-trivial lvalue expression."

llvm-svn: 363352
2019-06-14 04:05:17 +00:00
Richard Smith 17965d42f4 C++ DR712 and others: handle non-odr-use resulting from an lvalue-to-rvalue conversion applied to a member access or similar not-quite-trivial lvalue expression.
Summary:
When a variable is named in a context where we can't directly emit a
reference to it (because we don't know for sure that it's going to be
defined, or it's from an enclosing function and not captured, or the
reference might not "work" for some reason), we emit a copy of the
variable as a global and use that for the known-to-be-read-only access.

Reviewers: rjmccall

Subscribers: jdoerfert, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D63157

llvm-svn: 363295
2019-06-13 19:00:16 +00:00
Sebastian Redl f184291fec Check for redefinitions in MergeVarDecl. This finds redefinitions of globals without an initializer in C++ and thus fixes PR5451.
llvm-svn: 95098
2010-02-02 18:35:11 +00:00
Daniel Dunbar 8fbe78f6fc Update tests to use %clang_cc1 instead of 'clang-cc' or 'clang -cc1'.
- This is designed to make it obvious that %clang_cc1 is a "test variable"
   which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it
   can be useful to redefine what gets run as 'clang -cc1' (for example, to set
   a default target).

llvm-svn: 91446
2009-12-15 20:14:24 +00:00
Douglas Gregor dda7ced32e When recursively instantiating function templates, keep track of the
instantiation stack so that we provide a full instantiation
backtrace. Previously, we performed all of the instantiations implied
by the recursion, but each looked like a "top-level" instantiation.

The included test case tests the previous fix for the instantiation of
DeclRefExprs. Note that the "instantiated from" diagnostics still
don't tell us which template arguments we're instantiating with.

llvm-svn: 74540
2009-06-30 17:20:14 +00:00
Douglas Gregor 7ee2be46a6 New test for when the subexpressions within a typeid are potentially evaluated. We seem to be the only ones to get this right.
llvm-svn: 73955
2009-06-23 15:32:13 +00:00