aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Sema/SemaInit.cpp
AgeCommit message (Collapse)AuthorFilesLines
2020-01-09CWG2352: Allow qualification conversions during reference binding.Richard Smith1-1/+7
The language wording change forgot to update overload resolution to rank implicit conversion sequences based on qualification conversions in reference bindings. The anticipated resolution for that oversight is implemented here -- we order candidates based on qualification conversion, not only on top-level cv-qualifiers, including ranking reference bindings against non-reference bindings if they differ in non-top-level qualification conversions. For OpenCL/C++, this allows reference binding between pointers with differing (nested) address spaces. This makes the behavior of reference binding consistent with that of implicit pointer conversions, as is the purpose of this change, but that pre-existing behavior for pointer conversions is itself probably not correct. In any case, it's now consistently the same behavior and implemented in only one place. This reinstates commit de21704ba96fa80d3e9402f12c6505917a3885f4, reverted in commit d8018233d1ea4234de68d5b4593abd773db79484, with workarounds for some overload resolution ordering problems introduced by CWG2352.
2020-01-09When diagnosing the lack of a viable conversion function, also listRichard Smith1-32/+23
explicit functions that are not candidates. It's not always obvious that the reason a conversion was not possible is because the function you wanted to call is 'explicit', so explicitly say if that's the case. It would be nice to rank the explicit candidates higher in the diagnostic if an implicit conversion sequence exists for their arguments, but unfortunately we can't determine that without potentially triggering non-immediate-context errors that we're not permitted to produce.
2019-12-27Revert "CWG2352: Allow qualification conversions during reference binding."David Blaikie1-7/+1
This reverts commit de21704ba96fa80d3e9402f12c6505917a3885f4. Regressed/causes this to error due to ambiguity: void f(const int * const &); void f(int *); int main() { int * x; f(x); } (in case it's important - the original case where this turned up was a member function overload in a class template with, essentially: f(const T1&) f(T2*) (where T1 == X const *, T2 == X)) It's not super clear to me if this ^ is expected behavior, in which case I'm sorry about the revert & happy to look into ways to fix the original code.
2019-12-19CWG2352: Allow qualification conversions during reference binding.Richard Smith1-1/+7
The language wording change forgot to update overload resolution to rank implicit conversion sequences based on qualification conversions in reference bindings. The anticipated resolution for that oversight is implemented here -- we order candidates based on qualification conversion, not only on top-level cv-qualifiers. For OpenCL/C++, this allows reference binding between pointers with differing (nested) address spaces. This makes the behavior of reference binding consistent with that of implicit pointer conversions, as is the purpose of this change, but that pre-existing behavior for pointer conversions is itself probably not correct. In any case, it's now consistently the same behavior and implemented in only one place.
2019-12-18Refactor CompareReferenceRelationship and its callers in preparation forRichard Smith1-46/+42
implementing the resolution of CWG2352. No functionality change, except that we now convert the referent of a reference binding to the underlying type of the reference in more cases; we used to happen to preserve the type sugar from the referent if the only type change was in the cv-qualifiers. This exposed a bug in how we generate code for trivial assignment operators: if the type sugar (particularly the may_alias attribute) got lost during reference binding, we'd use the "wrong" TBAA information for the load during the assignment.
2019-12-06Add `QualType::hasAddressSpace`. NFC.Michael Liao1-3/+2
- Add that as a shorthand of <T>.getQualifiers().hasAddressSpace(). - Simplify related code.
2019-11-27[LifetimeAnalysis] Fix PR44150Gabor Horvath1-7/+26
References need somewhat special treatment. While copying a gsl::Pointer will propagate the points-to set, creating an object from a reference often behaves more like a dereference operation. Differential Revision: https://reviews.llvm.org/D70755
2019-11-19[NFC] Refactor representation of materialized temporariesTyker1-5/+4
Summary: this patch refactor representation of materialized temporaries to prevent an issue raised by rsmith in https://reviews.llvm.org/D63640#inline-612718 Reviewers: rsmith, martong, shafik Reviewed By: rsmith Subscribers: thakis, sammccall, ilya-biryukov, rnkovacs, arphaman, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69360
2019-11-17Revert "[NFC] Refactor representation of materialized temporaries"Nico Weber1-4/+5
This reverts commit 08ea1ee2db5f9d6460fef1d79d0d1d1a5eb78982. It broke ./ClangdTests/FindExplicitReferencesTest.All on the bots, see comments on https://reviews.llvm.org/D69360
2019-11-16[NFC] Refactor representation of materialized temporariesTyker1-5/+4
Summary: this patch refactor representation of materialized temporaries to prevent an issue raised by rsmith in https://reviews.llvm.org/D63640#inline-612718 Reviewers: rsmith, martong, shafik Reviewed By: rsmith Subscribers: rnkovacs, arphaman, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69360
2019-10-24When diagnosing an ambiguity, only note the candidates that contributeRichard Smith1-5/+5
to the ambiguity, rather than noting all viable candidates.
2019-10-19Sema: Create a no-op implicit cast for lvalue function conversions.Peter Collingbourne1-12/+20
This fixes an assertion failure in the case where an implicit conversion for a function call involves an lvalue function conversion, and makes the AST for initializations involving implicit lvalue function conversions more accurate. Differential Revision: https://reviews.llvm.org/D66437 llvm-svn: 375313
2019-10-04Properly handle instantiation-dependent array bounds.Richard Smith1-7/+9
We previously failed to treat an array with an instantiation-dependent but not value-dependent bound as being an instantiation-dependent type. We now track the array bound expression as part of a constant array type if it's an instantiation-dependent expression. llvm-svn: 373685
2019-10-02SemaInit - silence static analyzer getAs<> null dereference warnings. NFCI.Simon Pilgrim1-16/+16
The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us. llvm-svn: 373474
2019-10-02Revert r368237 - Update fix-it hints for std::move warnings.Richard Trieu1-27/+24
r368237 attempted to improve fix-its for move warnings, but introduced some regressions to -Wpessimizing-move. Revert that change and add the missing test cases to the pessimizing move test to prevent future regressions. llvm-svn: 373421
2019-09-06Reland [LifetimeAnalysis] Support more STL idioms (template forward ↵Matthias Gehre1-2/+2
declaration and DependentNameType) Reland after https://reviews.llvm.org/D66806 fixed the false-positive diagnostics. Summary: This fixes inference of gsl::Pointer on std::set::iterator with libstdc++ (the typedef for iterator on the template is a DependentNameType - we can only put the gsl::Pointer attribute on the underlaying record after instantiation) inference of gsl::Pointer on std::vector::iterator with libc++ (the class was forward-declared, we added the gsl::Pointer on the canonical decl (the forward decl), and later when the template was instantiated, there was no attribute on the definition so it was not instantiated). and a duplicate gsl::Pointer on some class with libstdc++ (we first added an attribute to a incomplete instantiation, and then another was copied from the template definition when the instantiation was completed). We now add the attributes to all redeclarations to fix thos issues and make their usage easier. Reviewers: gribozavr Subscribers: Szelethus, xazax.hun, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66179 llvm-svn: 371182
2019-09-03[LifetimeAnalysis] Fix some false positivesGabor Horvath1-0/+6
Differential Revision: https://reviews.llvm.org/D66806 llvm-svn: 370773
2019-09-01Fix variable HasArrayDesignator set but not used warning. NFCI.Simon Pilgrim1-3/+0
llvm-svn: 370609
2019-08-31[c++20] Add support for designated direct-list-initialization syntax.Richard Smith1-3/+27
This completes the implementation of P0329R4. llvm-svn: 370558
2019-08-30[c++20] Implement semantic restrictions for C++20 designatedRichard Smith1-92/+176
initializers. This has some interesting interactions with our existing extensions to support C99 designated initializers as an extension in C++. Those are resolved as follows: * We continue to permit the full breadth of C99 designated initializers in C++, with the exception that we disallow a partial overwrite of an initializer with a non-trivially-destructible type. (Full overwrite is OK, because we won't run the first initializer at all.) * The C99 extensions are disallowed in SFINAE contexts and during overload resolution, where they could change the meaning of valid programs. * C++20 disallows reordering of initializers. We only check for that for the simple cases that the C++20 rules permit (designators of the form '.field_name =' and continue to allow reordering in other cases). It would be nice to improve this behavior in future. * All C99 designated initializer extensions produce a warning by default in C++20 mode. People are going to learn the C++ rules based on what Clang diagnoses, so it's important we diagnose these properly by default. * In C++ <= 17, we apply the C++20 rules rather than the C99 rules, and so still diagnose C99 extensions as described above. We continue to accept designated C++20-compatible initializers in C++ <= 17 silently by default (but naturally still reject under -pedantic-errors). This is not a complete implementation of P0329R4. In particular, that paper introduces new non-C99-compatible syntax { .field { init } }, and we do not support that yet. This is based on a previous patch by Don Hinton, though I've made substantial changes when addressing the above interactions. Differential Revision: https://reviews.llvm.org/D59754 llvm-svn: 370544
2019-08-29Fix silent wrong-code bugs and crashes with designated initialization.Richard Smith1-176/+239
We failed to correctly handle the 'holes' left behind by designated initializers in VerifyOnly mode. This would result in us thinking that a designated initialization would be valid, only to find that it is not actually valid when we come to build it. In a +Asserts build, that would assert, and in a -Asserts build, that would silently lose some part of the initialization or crash. With this change, when an InitListExpr contains any designators, we now always build a structured list so that we can track the locations of the 'holes' that we need to go back and fill in. We could in principle do better: we only need the structured form if there is a designator that jumps backwards (and can otherwise check for the holes as we progress through the initializer list), but dealing with that turns out to be rather complicated, so it's not done as part of this patch. llvm-svn: 370419
2019-08-29Refactor InitListChecker to check only a single (explicit) initializerRichard Smith1-45/+12
list, rather than recursively checking multiple lists in C. This simplification is in preparation for making InitListChecker maintain more state that's specific to the explicit initializer list, particularly when handling designated initialization. llvm-svn: 370418
2019-08-29Refactor InitListChecker to make it a bit clearer that hasError is onlyRichard Smith1-44/+36
set to true in VerifyOnly mode in cases where it's also set to true when actually building the initializer list. Add FIXMEs for the two cases where that's not true. No functionality change intended. llvm-svn: 370417
2019-08-26Improve behavior in the case of stack exhaustion.Richard Smith1-2/+5
Summary: Clang performs various recursive operations (such as template instantiation), and may use non-trivial amounts of stack space in each recursive step (for instance, due to recursive AST walks). While we try to keep the stack space used by such steps to a minimum and we have explicit limits on the number of such steps we perform, it's impractical to guarantee that we won't blow out the stack on deeply recursive template instantiations on complex ASTs, even with only a moderately high instantiation depth limit. The user experience in these cases is generally terrible: we crash with no hint of what went wrong. Under this patch, we attempt to do better: * Detect when the stack is nearly exhausted, and produce a warning with a nice template instantiation backtrace, telling the user that we might run slowly or crash. * For cases where we're forced to trigger recursive template instantiation in arbitrarily-deeply-nested contexts, check whether we're nearly out of stack space and allocate a new stack (by spawning a new thread) after producing the warning. Reviewers: rnk, aaron.ballman Subscribers: mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66361 llvm-svn: 369940
2019-08-26[NFC] Add comments to some bool arguments for better readabilityGabor Horvath1-4/+8
llvm-svn: 369928
2019-08-23[LifetimeAnalysis] Make it possible to disable the new warningsGabor Horvath1-38/+70
llvm-svn: 369817
2019-08-22Revert "[LifetimeAnalysis] Support more STL idioms (template forward ↵Richard Smith1-2/+2
declaration and DependentNameType)" This reverts commit r369591, because it causes the formerly-reliable -Wreturn-stack-address warning to start issuing false positives. Testcase provided on the commit thread. llvm-svn: 369677
2019-08-21[LifetimeAnalysis] Support more STL idioms (template forward declaration and ↵Matthias Gehre1-2/+2
DependentNameType) Summary: This fixes inference of gsl::Pointer on std::set::iterator with libstdc++ (the typedef for iterator on the template is a DependentNameType - we can only put the gsl::Pointer attribute on the underlaying record after instantiation) inference of gsl::Pointer on std::vector::iterator with libc++ (the class was forward-declared, we added the gsl::Pointer on the canonical decl (the forward decl), and later when the template was instantiated, there was no attribute on the definition so it was not instantiated). and a duplicate gsl::Pointer on some class with libstdc++ (we first added an attribute to a incomplete instantiation, and then another was copied from the template definition when the instantiation was completed). We now add the attributes to all redeclarations to fix thos issues and make their usage easier. Reviewers: gribozavr Subscribers: Szelethus, xazax.hun, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66179 llvm-svn: 369591
2019-08-20[LifetimeAnalysis] Add support for free functionsGabor Horvath1-0/+29
Differential Revision: https://reviews.llvm.org/D66303 llvm-svn: 369408
2019-08-14[Clang] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere1-1/+1
Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. Differential revision: https://reviews.llvm.org/D66259 llvm-svn: 368942
2019-08-14[LifetimeAnalysis] Support std::stack::top() and std::optional::value()Matthias Gehre1-1/+1
Summary: Diagnose dangling pointers that come from std::stack::top() and std::optional::value(). Reviewers: gribozavr Subscribers: cfe-commits, xazax.hun Tags: #clang Differential Revision: https://reviews.llvm.org/D66164 llvm-svn: 368929
2019-08-14[LifetimeAnalysis] Fix false negatives of statement local lifetime analysis ↵Gabor Horvath1-19/+42
for some STL implementation Differential Revision: https://reviews.llvm.org/D66152 llvm-svn: 368871
2019-08-12Fix multiple lifetime warning messages for range based for loopGabor Horvath1-2/+5
llvm-svn: 368588
2019-08-12[OpenCL] Ignore parentheses for sampler initializationSven van Haastregt1-1/+1
The sampler handling logic in SemaInit.cpp would inadvertently treat parentheses around sampler arguments as an implicit cast, leading to an unreachable "can't implicitly cast lvalue to rvalue with this cast kind". Fix by ignoring parentheses once we are in the sampler initializer case. Differential Revision: https://reviews.llvm.org/D66080 llvm-svn: 368561
2019-08-11Properly detect temporary gsl::Owners through reference initialization chains.Gabor Horvath1-1/+2
llvm-svn: 368534
2019-08-11Properly handle reference initialization when detecting gsl::Pointer ↵Gabor Horvath1-5/+9
initialization chains llvm-svn: 368528
2019-08-10Fix a false positive warning when initializing members with gsl::Owners.Gabor Horvath1-0/+5
llvm-svn: 368501
2019-08-09Attempt to reapply "Even more warnings utilizing gsl::Owner/gsl::Pointer ↵Gabor Horvath1-9/+29
annotations" llvm-svn: 368499
2019-08-09Revert Even more warnings utilizing gsl::Owner/gsl::Pointer annotationsGabor Horvath1-29/+9
This reverts r368454 (git commit 7c3c8ba8daf40534e09f6fe8701b723e25e4e2dc) llvm-svn: 368463
2019-08-09Revert Fix a build bot failure and multiple warnings instances for range ↵Gabor Horvath1-6/+3
base for loops This reverts r368459 (git commit 2bf522aea62e4fb653cacb68072167d25149099e) llvm-svn: 368462
2019-08-09Fix a build bot failure and multiple warnings instances for range base for loopsGabor Horvath1-3/+6
llvm-svn: 368459
2019-08-09Even more warnings utilizing gsl::Owner/gsl::Pointer annotationsGabor Horvath1-9/+29
Differential Revision: https://reviews.llvm.org/D65127 llvm-svn: 368454
2019-08-09More warnings regarding gsl::Pointer and gsl::Owner attributesGabor Horvath1-4/+22
Differential Revision: https://reviews.llvm.org/D65120 llvm-svn: 368446
2019-08-08Update fix-it hints for std::move warnings.Richard Trieu1-24/+27
Fix -Wpessimizing-move and -Wredundant-move when warning on initializer lists. The new fix-it hints for removing the std::move call will now also suggest removing the braces for the initializer list so that the resulting code will still be compilable. This fixes PR42832 llvm-svn: 368237
2019-08-06Teach some warnings to respect gsl::Pointer and gsl::Owner attributesGabor Horvath1-9/+90
This patch extends some existing warnings to utilize the knowledge about the gsl::Pointer and gsl::Owner attributes. Differential Revision: https://reviews.llvm.org/D64256 llvm-svn: 368072
2019-08-02[OpenCL] Allow OpenCL C style vector initialization in C++Anastasia Stulova1-3/+11
Allow creating vector literals from other vectors. float4 a = (float4)(1.0f, 2.0f, 3.0f, 4.0f); float4 v = (float4)(a.s23, a.s01); Differential revision: https://reviews.llvm.org/D65286 llvm-svn: 367675
2019-07-16[OpenCL] Fixing sampler initialisations for C++ mode.Neil Hickey1-3/+3
Allow conversions between integer and sampler type. Differential Revision: https://reviews.llvm.org/D64791 llvm-svn: 366212
2019-07-16Fix parameter name comments using clang-tidy. NFC.Rui Ueyama1-3/+3
This patch applies clang-tidy's bugprone-argument-comment tool to LLVM, clang and lld source trees. Here is how I created this patch: $ git clone https://github.com/llvm/llvm-project.git $ cd llvm-project $ mkdir build $ cd build $ cmake -GNinja -DCMAKE_BUILD_TYPE=Debug \ -DLLVM_ENABLE_PROJECTS='clang;lld;clang-tools-extra' \ -DCMAKE_EXPORT_COMPILE_COMMANDS=On -DLLVM_ENABLE_LLD=On \ -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ ../llvm $ ninja $ parallel clang-tidy -checks='-*,bugprone-argument-comment' \ -config='{CheckOptions: [{key: StrictMode, value: 1}]}' -fix \ ::: ../llvm/lib/**/*.{cpp,h} ../clang/lib/**/*.{cpp,h} ../lld/**/*.{cpp,h} llvm-svn: 366177
2019-06-21[Sema] Fix diagnostic for addr spaces in reference bindingAnastasia Stulova1-8/+18
Extend reference binding behavior to account for address spaces. Differential Revision: https://reviews.llvm.org/D62914 llvm-svn: 364032
2019-06-21[Sema] Improved diagnostic for qualifiers in reference bindingAnastasia Stulova1-1/+2
Improved wording and also simplified by using printing method from qualifiers. Differential Revision: https://reviews.llvm.org/D62914 llvm-svn: 364023
generated by cgit v1.1 at 2025-10-13 14:33:32 +0000