| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
If we construct an object in some arbitrary non-default addr space
it should fail unless either:
- There is an implicit conversion from the address space to default
/generic address space.
- There is a matching ctor qualified with an address space that is
either exactly matching or convertible to the address space of an
object.
Differential Revision: https://reviews.llvm.org/D62156
llvm-svn: 363944
|
|
In addition to being unused and duplicating code, this was also wrong
(it didn't properly mark the operand as being potentially not odr-used).
This reinstates r363340, reverted in r363352.
llvm-svn: 363430
|
|
nullptr_t does not access memory.
We now reuse CK_NullToPointer to represent a conversion from a glvalue
of type nullptr_t to a prvalue of nullptr_t where necessary.
This reinstates r363337, reverted in r363352.
llvm-svn: 363429
|
|
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
|
|
In addition to being unused and duplicating code, this was also wrong
(it didn't properly mark the operand as being potentially not odr-used).
llvm-svn: 363340
|
|
nullptr_t does not access memory.
We now reuse CK_NullToPointer to represent a conversion from a glvalue
of type nullptr_t to a prvalue of nullptr_t where necessary.
This reinstates r345562, reverted in r346065, now that CodeGen's
handling of non-odr-used variables has been fixed.
llvm-svn: 363337
|
|
classes when checking an InitListExpr for lifetime extension.
llvm-svn: 363188
|
|
References to arbitrary address spaces can't always be bound to
temporaries. This change extends the reference binding logic to
check that the address space of a temporary can be implicitly
converted to the address space in a reference when temporary
materialization is performed.
Differential Revision: https://reviews.llvm.org/D61318
llvm-svn: 362604
|
|
This fixes a crash where we would neglect to mark a destructor referenced for an
__attribute__((no_destory)) array. The destructor is needed though, since if an
exception is thrown we need to cleanup the elements.
rdar://48462498
Differential revision: https://reviews.llvm.org/D61165
llvm-svn: 360446
|
|
Patch by Tyker!
Differential Revision: https://reviews.llvm.org/D60934
llvm-svn: 360311
|
|
This caused Clang to start erroring on the following:
struct S {
template <typename = int> explicit S();
};
struct T : S {};
struct U : T {
U();
};
U::U() {}
$ clang -c /tmp/x.cc
/tmp/x.cc:10:4: error: call to implicitly-deleted default constructor of 'T'
U::U() {}
^
/tmp/x.cc:5:12: note: default constructor of 'T' is implicitly deleted
because base class 'S' has no default constructor
struct T : S {};
^
1 error generated.
See discussion on the cfe-commits email thread.
This also reverts the follow-ups r359966 and r359968.
> this patch adds support for the explicit bool specifier.
>
> Changes:
> - The parsing for the explicit(bool) specifier was added in ParseDecl.cpp.
> - The storage of the explicit specifier was changed. the explicit specifier was stored as a boolean value in the FunctionDeclBitfields and in the DeclSpec class. now it is stored as a PointerIntPair<Expr*, 2> with a flag and a potential expression in CXXConstructorDecl, CXXDeductionGuideDecl, CXXConversionDecl and in the DeclSpec class.
> - Following the AST change, Serialization, ASTMatchers, ASTComparator and ASTPrinter were adapted.
> - Template instantiation was adapted to instantiate the potential expressions of the explicit(bool) specifier When instantiating their associated declaration.
> - The Add*Candidate functions were adapted, they now take a Boolean indicating if the context allowing explicit constructor or conversion function and this boolean is used to remove invalid overloads that required template instantiation to be detected.
> - Test for Semantic and Serialization were added.
>
> This patch is not yet complete. I still need to check that interaction with CTAD and deduction guides is correct. and add more tests for AST operations. But I wanted first feedback.
> Perhaps this patch should be spited in smaller patches, but making each patch testable as a standalone may be tricky.
>
> Patch by Tyker
>
> Differential Revision: https://reviews.llvm.org/D60934
llvm-svn: 360024
|
|
this patch adds support for the explicit bool specifier.
Changes:
- The parsing for the explicit(bool) specifier was added in ParseDecl.cpp.
- The storage of the explicit specifier was changed. the explicit specifier was stored as a boolean value in the FunctionDeclBitfields and in the DeclSpec class. now it is stored as a PointerIntPair<Expr*, 2> with a flag and a potential expression in CXXConstructorDecl, CXXDeductionGuideDecl, CXXConversionDecl and in the DeclSpec class.
- Following the AST change, Serialization, ASTMatchers, ASTComparator and ASTPrinter were adapted.
- Template instantiation was adapted to instantiate the potential expressions of the explicit(bool) specifier When instantiating their associated declaration.
- The Add*Candidate functions were adapted, they now take a Boolean indicating if the context allowing explicit constructor or conversion function and this boolean is used to remove invalid overloads that required template instantiation to be detected.
- Test for Semantic and Serialization were added.
This patch is not yet complete. I still need to check that interaction with CTAD and deduction guides is correct. and add more tests for AST operations. But I wanted first feedback.
Perhaps this patch should be spited in smaller patches, but making each patch testable as a standalone may be tricky.
Patch by Tyker
Differential Revision: https://reviews.llvm.org/D60934
llvm-svn: 359949
|
|
diagnostics emitted (or suppressed) during completion don't interfere with the overload notes
Because diagnostics and their notes are not connected at the API level,
if the error message for an overload is emitted, then the overload
candidates are completed - if a diagnostic is emitted during that work,
the notes related to overload candidates would be attached to the latter
diagnostic, not the original error. Sort of worse, if the latter
diagnostic was disabled, the notes are disabled.
Reviewers: rsmith
Differential Revision: https://reviews.llvm.org/D61357
llvm-svn: 359854
|
|
Improved classification of address space cast when qualification
conversion is performed - prevent adding addr space cast for
non-pointer and non-reference types. Take address space correctly
from the pointee.
Also pass correct address space from 'this' object using
AggValueSlot when generating addrspacecast in the constructor
call.
Differential Revision: https://reviews.llvm.org/D59988
llvm-svn: 357682
|
|
CorrectionCandidateCallback unless we are going to do some typo correction
The various CorrectionCandidateCallbacks are currently heap-allocated
unconditionally. This was needed because of delayed typo correction.
However these allocations represent currently 15.4% of all allocations
(number of allocations) when parsing all of Boost (!), mostly because
of ParseCastExpression, ParseStatementOrDeclarationAfterAttrtibutes
and isCXXDeclarationSpecifier. Note that all of these callback objects
are small. Let's not do this.
Instead initially allocate the callback on the stack, and only do a
heap allocation if we are going to do some typo correction. Do this by:
1. Adding a clone function to each callback, which will do a polymorphic
clone of the callback. This clone function is required to be implemented
by every callback (of which there is a fair amount). Make sure this is
the case by making it pure virtual.
2. Use this clone function when we are going to try to correct a typo.
This additionally cut the time of -fsyntax-only on all of Boost by 0.5%
(not that much, but still something). No functional changes intended.
Differential Revision: https://reviews.llvm.org/D58827
Reviewed By: rnk
llvm-svn: 356925
|
|
Before this commit, we emit unavailable errors for calls to functions during
overload resolution, and for references to all other declarations in
DiagnoseUseOfDecl. The early checks during overload resolution aren't as good as
the DiagnoseAvailabilityOfDecl based checks, as they error on the code from
PR40991. This commit fixes this by removing the early checking.
llvm.org/PR40991
rdar://48564179
Differential revision: https://reviews.llvm.org/D59394
llvm-svn: 356599
|
|
This change fixes temporary materialization to happen in the right
(default) address space when binding to it a reference of different type.
It adds address space conversion afterwards to match the addr space
of a reference.
Differential Revision: https://reviews.llvm.org/D58634
llvm-svn: 355499
|
|
Basically the same issue as string init, except it didn't really have
any visible consequences before I removed the implicit lvalue-to-rvalue
conversion from CodeGen.
While I'm here, a couple minor drive-by cleanups: IgnoreParens never
returns a ConstantExpr, and there was a potential crash with string init
involving a ChooseExpr.
The analyzer test change maybe indicates we could simplify the analyzer
code a little with this fix? Apparently a hack was added to support
lvalues in initializers in r315750, but I'm not really familiar with the
relevant code.
Fixes regression reported in the kernel build at
https://bugs.llvm.org/show_bug.cgi?id=40430#c6 .
Differential Revision: https://reviews.llvm.org/D58069
llvm-svn: 353762
|
|
This allows substantially simplifying the expression evaluation code,
because we don't have to special-case lvalues which are actually string
literal initialization.
This currently throws away an optimization where we would avoid creating
an array APValue for string literal initialization. If we really want
to optimize this case, we should fix APValue so it can store simple
arrays more efficiently, like llvm::ConstantDataArray. This shouldn't
affect the memory usage for other string literals. (Not sure if this is
a blocker; I don't think string literal init is common enough for this
to be a serious issue, but I could be wrong.)
The change to test/CodeGenObjC/encode-test.m is a weird side-effect of
these changes: we currently don't constant-evaluate arrays in C, so the
strlen call shouldn't be folded, but lvalue string init managed to get
around that check. I this this is fine.
Fixes https://bugs.llvm.org/show_bug.cgi?id=40430 .
llvm-svn: 353569
|
|
When we attempt to add an addr space qual to a type already
qualified by an addr space ICE is triggered. Before creating
a type with new address space, remove the old addr space.
Fixing PR38614!
Differential Revision: https://reviews.llvm.org/D57524
llvm-svn: 353160
|
|
I recently ran into this code:
```
\#include <iostream>
void foo(const std::string &s, const std::string& = "");
\#include <string>
void test() { foo(""); }
```
The diagnostic produced said it can't bind char[1] to std::string
const&. It didn't mention std::string is incomplete. The user had to
infer that.
This patch causes the diagnostic to now say "incomplete type".
llvm-svn: 352927
|
|
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
|
|
deduction guides.
Summary:
Some style guides want to allow using CTAD only on types that "opt-in"; i.e. on types that are designed to support it and not just types that *happen* to work with it.
This patch implements the `-Wctad-maybe-unsupported` warning, which is off by default, which warns when CTAD is used on a type that does not define any deduction guides.
The following pattern can be used to suppress the warning in cases where the type intentionally doesn't define any deduction guides:
```
struct allow_ctad_t;
template <class T>
struct TestSuppression {
TestSuppression(T) {}
};
TestSuppression(allow_ctad_t)->TestSuppression<void>; // guides with incomplete parameter types are never considered.
```
Reviewers: rsmith, james.dennett, gromer
Reviewed By: rsmith
Subscribers: jdennett, Quuxplusone, lebedev.ri, cfe-commits
Differential Revision: https://reviews.llvm.org/D56731
llvm-svn: 351484
|
|
Set address spaces of 'this' param correctly for implicit special
class members.
This also changes initialization conversion sequence to separate
address space conversion from other qualifiers in case of binding
reference to a temporary. In this case address space conversion
should happen after the binding (unlike for other quals). This is
needed to materialize it correctly in the alloca address space.
Initial patch by Mikael Nilssoni!
Differential Revision: https://reviews.llvm.org/D56066
llvm-svn: 351053
|
|
Store the arguments of CXXConstructExpr in a trailing array. This is very
similar to the CallExpr case in D55771, with the exception that there is
only one derived class (CXXTemporaryObjectExpr) and that we compute the
offset to the trailing array instead of storing it.
This saves one pointer per CXXConstructExpr and CXXTemporaryObjectExpr.
Reviewed By: rjmccall
Differential Revision: https://reviews.llvm.org/D56022
llvm-svn: 350003
|
|
This reverts commit 46efdf2ccc2a80aefebf8433dbf9c7c959f6e629.
Richard Smith commented just after I submitted this that this is the
wrong solution. Reverting so that I can fix differently.
llvm-svn: 349206
|
|
Core issue 1013 suggests that having an uninitialied std::nullptr_t be
UB is a bit foolish, since there is only a single valid value. This DR
reports that DR616 fixes it, which does so by making lvalue-to-rvalue
conversions from nullptr_t be equal to nullptr.
However, just implementing that results in warnings/etc in many places.
In order to fix all situations where nullptr_t would seem uninitialized,
this patch instead (as an otherwise transparent extension) default
initializes uninitialized VarDecls of nullptr_t.
Differential Revision: https://reviews.llvm.org/D53713
Change-Id: I84d72a9290054fa55341e8cbdac43c8e7f25b885
llvm-svn: 349201
|
|
Summary: Found via `codespell -q 3 -I ../clang-whitelist.txt -L uint,importd,crasher,gonna,cant,ue,ons,orign,ned`
Reviewers: teemperor
Reviewed By: teemperor
Subscribers: teemperor, jholewinski, jvesely, nhaehnle, whisperity, jfb, cfe-commits
Differential Revision: https://reviews.llvm.org/D55475
llvm-svn: 348755
|
|
This patch adds the noderef attribute in clang and checks for dereferences of
types that have this attribute. This attribute is currently used by sparse and
would like to be ported to clang.
Differential Revision: https://reviews.llvm.org/D49511
llvm-svn: 348442
|
|
It seems the two failing tests can be simply fixed after r348037
Fix 3 cases in Analysis/builtin-functions.cpp
Delete the bad CodeGen/builtin-constant-p.c for now
llvm-svn: 348053
|
|
Kept the "indirect_builtin_constant_p" test case in test/SemaCXX/constant-expression-cxx1y.cpp
while we are investigating why the following snippet fails:
extern char extern_var;
struct { int a; } a = {__builtin_constant_p(extern_var)};
llvm-svn: 348039
|
|
This was reverted in r347656 due to me thinking it caused a miscompile of
Chromium. Turns out it was the Chromium code that was broken.
llvm-svn: 347756
|
|
This caused a miscompile in Chrome (see crbug.com/908372) that's
illustrated by this small reduction:
static bool f(int *a, int *b) {
return !__builtin_constant_p(b - a) || (!(b - a));
}
int arr[] = {1,2,3};
bool g() {
return f(arr, arr + 3);
}
$ clang -O2 -S -emit-llvm a.cc -o -
g() should return true, but after r347417 it became false for some reason.
This also reverts the follow-up commits.
r347417:
> Re-Reinstate 347294 with a fix for the failures.
>
> Don't try to emit a scalar expression for a non-scalar argument to
> __builtin_constant_p().
>
> Third time's a charm!
r347446:
> The result of is.constant() is unsigned.
r347480:
> A __builtin_constant_p() returns 0 with a function type.
r347512:
> isEvaluatable() implies a constant context.
>
> Assume that we're in a constant context if we're asking if the expression can
> be compiled into a constant initializer. This fixes the issue where a
> __builtin_constant_p() in a compound literal was diagnosed as not being
> constant, even though it's always possible to convert the builtin into a
> constant.
r347531:
> A "constexpr" is evaluated in a constant context. Make sure this is reflected
> if a __builtin_constant_p() is a part of a constexpr.
llvm-svn: 347656
|
|
Don't try to emit a scalar expression for a non-scalar argument to
__builtin_constant_p().
Third time's a charm!
llvm-svn: 347417
|
|
llvm-svn: 347389
|
|
EvaluateAsInt() is sometimes called in a constant context. When that's the
case, we need to specify it as so.
llvm-svn: 347364
|
|
If PerformConstructorInitialization of a direct initializer list constructor is
called while instantiating a template, it has brace locations in its BraceLoc
arguments but not in the Kind argument.
This reverts the hunk https://reviews.llvm.org/D41921#inline-468844.
Patch by Orivej Desh!
Differential Revision: https://reviews.llvm.org/D53231
llvm-svn: 347261
|
|
Added references to the addr spaces deduction and enabled
CL2.0 features (program scope variables and storage class
qualifiers) to work in C++ mode too.
Fixed several address space conversion issues in CodeGen
for references.
Differential Revision: https://reviews.llvm.org/D53764
llvm-svn: 347059
|
|
This unfortunately results in a substantial breaking change when
switching to C++20, but it's not yet clear what / how much we should
do about that. We may want to add a compatibility conversion from
u8 string literals to const char*, similar to how C++98 provided a
compatibility conversion from string literals to non-const char*,
but that's not handled by this patch.
The feature can be disabled in C++20 mode with -fno-char8_t.
llvm-svn: 346892
|
|
Summary:
Compound literals, enums, file-scoped arrays, etc. require their
initializers and size specifiers to be constant. Wrap the initializer
expressions in a ConstantExpr so that we can easily check for this later
on.
Reviewers: rsmith, shafik
Reviewed By: rsmith
Subscribers: cfe-commits, jyknight, nickdesaulniers
Differential Revision: https://reviews.llvm.org/D53921
llvm-svn: 346455
|
|
Summary:
Documentation can be found at https://www.khronos.org/registry/OpenCL/extensions/intel/cl_intel_device_side_avc_motion_estimation.txt
Patch by Kristina Bessonova
Reviewers: Anastasia, yaxunl, shafik
Reviewed By: Anastasia
Subscribers: arphaman, sidorovd, AlexeySotkin, krisb, bader, asavonic, cfe-commits
Differential Revision: https://reviews.llvm.org/D51484
llvm-svn: 346392
|
|
cl_intel_device_side_avc_motion_estimation
This patch breaks Index/opencl-types.cl LIT test:
Script:
--
: 'RUN: at line 1'; stage1/bin/c-index-test -test-print-type llvm/tools/clang/test/Index/opencl-types.cl -cl-std=CL2.0 | stage1/bin/FileCheck llvm/tools/clang/test/Index/opencl-types.cl
--
Command Output (stderr):
--
llvm/tools/clang/test/Index/opencl-types.cl:3:26: warning: unsupported OpenCL extension 'cl_khr_fp16' - ignoring [-Wignored-pragmas]
llvm/tools/clang/test/Index/opencl-types.cl:4:26: warning: unsupported OpenCL extension 'cl_khr_fp64' - ignoring [-Wignored-pragmas]
llvm/tools/clang/test/Index/opencl-types.cl:8:9: error: use of type 'double' requires cl_khr_fp64 extension to be enabled
llvm/tools/clang/test/Index/opencl-types.cl:11:8: error: declaring variable of type 'half' is not allowed
llvm/tools/clang/test/Index/opencl-types.cl:15:3: error: use of type 'double' requires cl_khr_fp64 extension to be enabled
llvm/tools/clang/test/Index/opencl-types.cl:16:3: error: use of type 'double4' (vector of 4 'double' values) requires cl_khr_fp64 extension to be enabled
llvm/tools/clang/test/Index/opencl-types.cl:26:26: warning: unsupported OpenCL extension 'cl_khr_gl_msaa_sharing' - ignoring [-Wignored-pragmas]
llvm/tools/clang/test/Index/opencl-types.cl:35:44: error: use of type '__read_only image2d_msaa_t' requires cl_khr_gl_msaa_sharing extension to be enabled
llvm/tools/clang/test/Index/opencl-types.cl:36:49: error: use of type '__read_only image2d_array_msaa_t' requires cl_khr_gl_msaa_sharing extension to be enabled
llvm/tools/clang/test/Index/opencl-types.cl:37:49: error: use of type '__read_only image2d_msaa_depth_t' requires cl_khr_gl_msaa_sharing extension to be enabled
llvm/tools/clang/test/Index/opencl-types.cl:38:54: error: use of type '__read_only image2d_array_msaa_depth_t' requires cl_khr_gl_msaa_sharing extension to be enabled
llvm-svn: 346338
|
|
Summary:
Documentation can be found at https://www.khronos.org/registry/OpenCL/extensions/intel/cl_intel_device_side_avc_motion_estimation.txt
Patch by Kristina Bessonova
Reviewers: Anastasia, yaxunl, shafik
Reviewed By: Anastasia
Subscribers: arphaman, sidorovd, AlexeySotkin, krisb, bader, asavonic, cfe-commits
Differential Revision: https://reviews.llvm.org/D51484
llvm-svn: 346326
|
|
glvalue of type"
This exposes a (known) CodeGen bug: it can't cope with emitting lvalue
expressions that denote non-odr-used but usable-in-constant-expression
variables. See PR39528 for a testcase.
Reverted for now until that issue can be fixed.
llvm-svn: 346065
|
|
A ConstantExpr class represents a full expression that's in a context where a
constant expression is required. This class reflects the path the evaluator
took to reach the expression rather than the syntactic context in which the
expression occurs.
In the future, the class will be expanded to cache the result of the evaluated
expression so that it's not needlessly re-evaluated
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D53475
llvm-svn: 345692
|
|
We haven't supported compiling ObjC1 for a long time (and never will again), so
there isn't any reason to keep these separate. This patch replaces
LangOpts::ObjC1 and LangOpts::ObjC2 with LangOpts::ObjC.
Differential revision: https://reviews.llvm.org/D53547
llvm-svn: 345637
|
|
nullptr_t does not access memory.
We now reuse CK_NullToPointer to represent a conversion from a glvalue
of type nullptr_t to a prvalue of nullptr_t where necessary.
llvm-svn: 345562
|
|
Reviewers: Anastasia, yaxunl
Reviewed By: Anastasia
Subscribers: asavonic, cfe-commits
Differential Revision: https://reviews.llvm.org/D52654
llvm-svn: 345038
|
|
llvm-svn: 344859
|
|
Rather, they are subexpressions of the enclosing lambda-expression, and
any temporaries in them are destroyed at the end of that
full-expression, or when the corresponding lambda-expression is
destroyed if they are lifetime-extended.
llvm-svn: 344801
|
