summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaStmt.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Refactoring code around move/copy initialization. NFC.Richard Trieu2018-03-151-56/+82
| | | | | | | | | | | | Use an enum parameter instead of a bool for more control on how the copy elision functions work. Extract the move initialization code from the move or copy initialization block. Patch by: Arthur O'Dwyer Differential Revision: https://reviews.llvm.org/D43898 llvm-svn: 327598
* Re-land "[Sema] Make getCurFunction() return null outside function parsing"Reid Kleckner2018-03-121-8/+8
| | | | | | | | | | | | | | This relands r326965. There was a null dereference in typo correction that was triggered in Sema/diagnose_if.c. We are not always in a function scope when doing typo correction. The fix is to add a null check. LLVM's optimizer made it hard to find this bug. I wrote it up in a not-very-well-editted blog post here: http://qinsb.blogspot.com/2018/03/ub-will-delete-your-null-checks.html llvm-svn: 327334
* Revert "[Sema] Make getCurFunction() return null outside function parsing"Reid Kleckner2018-03-081-8/+8
| | | | | | | | | | This reverts r326965. It seems to have caused repeating test failures in clang/test/Sema/diagnose_if.c on some buildbots. I cannot reproduce the problem, and it's not immediately obvious what the problem is, so let's revert to green. llvm-svn: 326974
* [Sema] Make getCurFunction() return null outside function parsingReid Kleckner2018-03-081-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Before this patch, Sema pre-allocated a FunctionScopeInfo and kept it in the first, always present element of the FunctionScopes stack. This meant that Sema::getCurFunction would return a pointer to this pre-allocated object when parsing code outside a function body. This is pretty much always a bug, so this patch moves the pre-allocated object into a separate unique_ptr. This should make bugs like PR36536 a lot more obvious. As you can see from this patch, there were a number of places that unconditionally assumed they were always called inside a function. However, there are also many places that null checked the result of getCurFunction(), so I think this is a reasonable direction. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D44039 llvm-svn: 326965
* Avoid including ScopeInfo.h from Sema.hReid Kleckner2018-03-071-17/+14
| | | | | | | | | | | | | | | | | Summary: This provides no measurable build speedup, but it reinstates an optimization from r112038 that was lost in r179618. It requires moving CapturedScopeInfo::Capture out to clang::sema, which might be too general since we have plenty of other Capture records in BlockDecl and other AST nodes. Reviewers: rjmccall Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D44221 llvm-svn: 326957
* [Debug] Annotate compiler generated range-for loop variables.Matt Davis2018-02-141-4/+8
| | | | | | | | | | | | | | | | | | Summary: This change aims to simplify debugging by annotating the range-for loop artificial variables (range, begin, end) with the scope depth. Reviewers: rsmith, dblaikie Reviewed By: dblaikie Subscribers: dblaikie, cfe-commits Tags: #debug-info Differential Revision: https://reviews.llvm.org/D42813 llvm-svn: 325175
* Fix crash when trying to pack-expand a GNU statement expression.Richard Smith2018-02-031-2/+2
| | | | | | | | We could in principle support such pack expansion, using techniques similar to what we do for pack expansion of lambdas, but it's not clear it's worthwhile. For now at least, cleanly reject these cases rather than crashing. llvm-svn: 324160
* Fix and simplify handling of return type for (generic) lambda conversion ↵Richard Smith2018-01-021-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | function to function pointer. Previously, we would: * compute the type of the conversion function and static invoker as a side-effect of template argument deduction for a conversion * re-compute the type as part of deduced return type deduction when building the conversion function itself Neither of these turns out to be quite correct. There are other ways to reach a declaration of the conversion function than in a conversion (such as an explicit call or friend declaration), and performing auto deduction causes the function type to be rebuilt in the context of the lambda closure type (which is different from the context in which it originally appeared, resulting in spurious substitution failures for constructs that are valid in one context but not the other, such as the use of an enclosing class's "this" pointer). This patch switches us to use a different strategy: as before, we use the declared type of the operator() to form the type of the conversion function and invoker, but we now populate that type as part of return type deduction for the conversion function. And the invoker is now treated as simply being an implementation detail of building the conversion function, and isn't given special treatment by template argument deduction for the conversion function any more. llvm-svn: 321683
* [AST] Inline CompoundStmt contents into the parent allocation.Benjamin Kramer2017-12-241-1/+1
| | | | | | Saves a pointer on every CompoundStmt. llvm-svn: 321429
* [c++20] P0515R3: Parsing support and basic AST construction for operator <=>.Richard Smith2017-12-141-12/+25
| | | | | | | | | | | | | | | Adding the new enumerator forced a bunch more changes into this patch than I would have liked. The -Wtautological-compare warning was extended to properly check the new comparison operator, clang-format needed updating because it uses precedence levels as weights for determining where to break lines (and several operators increased their precedence levels with this change), thread-safety analysis needed changes to build its own IL properly for the new operator. All "real" semantic checking for this operator has been deferred to a future patch. For now, we use the relational comparison rules and arbitrarily give the builtin form of the operator a return type of 'void'. llvm-svn: 320707
* Now that C++17 is official (https://www.iso.org/standard/68564.html), start ↵Aaron Ballman2017-12-041-1/+1
| | | | | | changing the C++1z terminology over to C++17. NFC intended, these are all mechanical changes. llvm-svn: 319688
* Revert r318456 "Issue -Wempty-body warnings for else blocks"Hans Wennborg2017-11-201-3/+1
| | | | | | | | | | | | | | This caused warnings also when the if or else comes from macros. There was an attempt to fix this in r318556, but that introduced new problems and was reverted. Reverting this too until the whole issue is sorted. > This looks like it was just an oversight. > > Fixes http://llvm.org/pr35319 > > git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318456 91177308-0d34-0410-b5e6-96231b3b80d8 llvm-svn: 318667
* Revert r318556 "Loosen -Wempty-body warning"Hans Wennborg2017-11-201-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It seems this somehow made -Wempty-body fire in some macro cases where it didn't before, e.g. ../../third_party/ffmpeg/libavcodec/bitstream.c(169,5): error: if statement has empty body [-Werror,-Wempty-body] ff_dlog(NULL, "new table index=%d size=%d\n", table_index, table_size); ^ ../../third_party/ffmpeg\libavutil/internal.h(276,80): note: expanded from macro 'ff_dlog' # define ff_dlog(ctx, ...) do { if (0) av_log(ctx, AV_LOG_DEBUG, __VA_ARGS__); } while (0) ^ ../../third_party/ffmpeg/libavcodec/bitstream.c(169,5): note: put the semicolon on a separate line to silence this warning Reverting until this can be figured out. > Do not show it when `if` or `else` come from macros. > E.g., > > #define USED(A) if (A); else > #define SOME_IF(A) if (A) > > void test() { > // No warnings are shown in those cases now. > USED(0); > SOME_IF(0); > } > > Patch by Ilya Biryukov! > > Differential Revision: https://reviews.llvm.org/D40185 llvm-svn: 318665
* Loosen -Wempty-body warningReid Kleckner2017-11-171-2/+1
| | | | | | | | | | | | | | | | | | | | Do not show it when `if` or `else` come from macros. E.g., #define USED(A) if (A); else #define SOME_IF(A) if (A) void test() { // No warnings are shown in those cases now. USED(0); SOME_IF(0); } Patch by Ilya Biryukov! Differential Revision: https://reviews.llvm.org/D40185 llvm-svn: 318556
* Issue -Wempty-body warnings for else blocksReid Kleckner2017-11-161-1/+3
| | | | | | | | This looks like it was just an oversight. Fixes http://llvm.org/pr35319 llvm-svn: 318456
* Catch more cases with -Wenum-compareRichard Trieu2017-09-091-2/+4
| | | | | | | Treat typedef enum as named enums instead of anonymous enums. Anonymous enums are ignored by the warning, so previously, typedef enums were ignored as well. llvm-svn: 312842
* [Sema] Assign new flag -Wenum-compare-switch to switch-related parts of ↵Gabor Horvath2017-08-091-1/+1
| | | | | | | | | | -Wenum-compare Patch by: Reka Nikolett Kovacs Differential Revision: https://reviews.llvm.org/D36526 llvm-svn: 310521
* [Sema] -Wenum-compare no longer warn on anonymous enums in switch statementsGabor Horvath2017-08-091-0/+6
| | | | | | Patch by: Reka Nikolett Kovacs llvm-svn: 310468
* [Sema] Extend -Wenum-compare to handle mixed enum comparisons in switch ↵Gabor Horvath2017-08-091-8/+28
| | | | | | | | | | statements Patch by: Reka Nikolett Kovacs Differential Revision: https://reviews.llvm.org/D36407 llvm-svn: 310449
* [Sema] Make BreakContinueFinder handle nested loops.Eli Friedman2017-07-041-6/+61
| | | | | | | | | | | | We don't care about break or continue statements that aren't associated with the current loop, so make sure the visitor doesn't find them. Fixes https://bugs.llvm.org/show_bug.cgi?id=32648 . Differential Revision: https://reviews.llvm.org/D34568 llvm-svn: 307051
* [coroutines] Fix co_await for range statementEric Fiselier2017-06-141-20/+32
| | | | | | | | | | | | | | | | | Summary: Currently we build the co_await expressions on the wrong implicit statements of the implicit ranged for; Specifically we build the co_await expression wrapping the range declaration, but it should wrap the begin expression. This patch fixes co_await on range for. Reviewers: rsmith, GorNishanov Reviewed By: GorNishanov Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D34021 llvm-svn: 305363
* [Sema][C++1z] Ensure binding in dependent range for have non-null typeErik Pilkington2017-06-121-1/+5
| | | | | | | | Fixes PR32172 Differential revision: https://reviews.llvm.org/D34096 llvm-svn: 305195
* [DebugInfo] Add kind of ImplicitParamDecl for emission of FlagObjectPointer.Alexey Bataev2017-06-091-8/+12
| | | | | | | | | | | | | | | | | Summary: If the first parameter of the function is the ImplicitParamDecl, codegen automatically marks it as an implicit argument with `this` or `self` pointer. Added internal kind of the ImplicitParamDecl to separate 'this', 'self', 'vtt' and other implicit parameters from other kind of parameters. Reviewers: rjmccall, aaron.ballman Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D33735 llvm-svn: 305075
* Minor fixes to for-loop warning.Richard Trieu2017-06-021-29/+22
| | | | | | | | | | | | | The warning for unchanged loop variables outputted a diagnostic that was dependent on iteration order from a pointer set, which is not always deterministic. Switch to a set vector, which allows fast querying and preserves ordering. Also make other minor changes in this area. Use more range-based for-loops. Remove limitation on SourceRanges that no logner exists. llvm-svn: 304519
* Fix PR32933: crash on lambda capture of VLAFaisal Vali2017-05-151-3/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://bugs.llvm.org/show_bug.cgi?id=32933 Turns out clang wasn't really handling vla's (*) in C++11's for-range entirely correctly. For e.g. This would lead to generation of buggy IR: void foo(int b) { int vla[b]; b = -1; // This store would affect the '__end = vla + b' for (int &c : vla) c = 0; } Additionally, code-gen would get confused when VLA's were reference-captured by lambdas, and then used in a for-range, which would result in an attempt to generate IR for '__end = vla + b' within the lambda's body - without any capture of 'b' - hence the assertion. This patch modifies clang, so that for VLA's it translates the end pointer approximately into: __end = __begin + sizeof(vla)/sizeof(vla->getElementType()) As opposed to the __end = __begin + b; I considered passing a magic value into codegen - or having codegen special case the '__end' variable when it referred to a variably-modified type, but I decided against that approach, because it smelled like I would be increasing a complicated form of coupling, that I think would be even harder to maintain than the above approach (which can easily be optimized (-O1) to refer to the run-time bound that was calculated upon array's creation or copied into the lambda's closure object). (*) why oh why gcc would you enable this by default?! ;) llvm-svn: 303026
* ANSIfy. No behavior change.Nico Weber2017-05-051-1/+1
| | | | llvm-svn: 302258
* [Sema][ObjC] Disallow jumping into ObjC fast enumeration loops.Akira Hatanaka2017-04-191-0/+1
| | | | | | | | rdar://problem/31635406 Differential Revision: https://reviews.llvm.org/D32187 llvm-svn: 300722
* [NFC, Scoped Enum] Convert Sema::ExpressionEvaluationContext into a scoped EnumFaisal Vali2017-04-011-5/+10
| | | | | | | | - also replace direct equality checks against the ConstantEvaluated enumerator with isConstantEvaluted(), in anticipation of adding finer granularity to the various ConstantEvaluated contexts and reinstating certain restrictions on where lambda expressions can occur in C++17. - update the clang tablegen backend that uses these Enumerators, and add the relevant scope where needed. llvm-svn: 299316
* Look through CXXBindTemporaryExprs when checking CXXFunctionCastExprsDaniel Jasper2017-03-271-2/+8
| | | | | | | | | | | | for unused values. This fixes a regression caused by r298676, where constructor calls to classes with non-trivial dtor were marked as unused if the first argument is an initializer list. This is inconsistent (as the test shows) and also warns on a reasonbly common code pattern where people just call constructors to create and immediately destroy an object. llvm-svn: 298853
* Add support for attribute enum_extensibility.Akira Hatanaka2017-03-211-8/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit adds support for a new attribute that will be used to distinguish between extensible and inextensible enums. There are three main purposes of this attribute: 1. Give better control over when enum-related warnings are issued. For example, in the code below, clang will not issue a -Wassign-enum warning if the enum is marked "open": enum __attribute__((enum_extensibility(closed))) EnumClosed { B0 = 1, B1 = 10 }; enum __attribute__((enum_extensibility(open))) EnumOpen { C0 = 1, C1 = 10 }; enum EnumClosed ec = 100; // warning issued enum EnumOpen eo = 100; // no warning 2. Enable code-completion and debugging tools to offer better suggestions. 3. Make it easier for swift's clang importer to determine which swift type an enum should be mapped to. For more details, see the discussion I started on cfe-dev: http://lists.llvm.org/pipermail/cfe-dev/2017-February/052748.html rdar://problem/12764379 rdar://problem/23145650 Differential Revision: https://reviews.llvm.org/D30766 llvm-svn: 298332
* Factor out function to determine whether we're performing a templateRichard Smith2017-02-211-1/+1
| | | | | | | | | instantiation. In preparation for converting the template stack to a more general context stack (so we can include context notes for other kinds of context). llvm-svn: 295686
* [Sema] Disallow returning a __block variable via a move.Akira Hatanaka2017-02-151-3/+5
| | | | | | | | | | | | | | | r274291 made changes to prefer calling a move constructor to calling a copy constructor when returning from a function. This caused programs to crash when a __block variable in the heap was moved out and used later. This commit fixes the bug by disallowing moving out of __block variables implicitly. rdar://problem/28181080 Differential Revision: https://reviews.llvm.org/D29908 llvm-svn: 295150
* Remove redundant passing around of a "ContainsAutoType" flag.Richard Smith2017-01-121-6/+3
| | | | | | | | | | | | This flag serves no purpose other than to prevent us walking through a type to check whether it contains an 'auto' specifier; this duplication of information is error-prone, does not appear to provide any performance benefit, and will become less practical once we support C++1z deduced class template types and eventually constrained types from the Concepts TS. No functionality change intended. llvm-svn: 291737
* [Sema] Avoid "case value not in enumerated type" warning for C++11 opaque enumsAlex Lorenz2016-12-081-1/+2
| | | | | | | | | | | | This commit ensures that the switch warning "case value not in enumerated type" isn't shown for opaque enums. We don't know the actual list of values in opaque enums, so that warning is incorrect. rdar://29230764 Differential Revision: https://reviews.llvm.org/D27299 llvm-svn: 289055
* Mass-rename the handful of error_* diagnostics to err_*.Richard Smith2016-12-021-5/+5
| | | | llvm-svn: 288545
* Add a warning for 'main' returning 'true' or 'false'.Richard Smith2016-11-291-0/+4
| | | | | | Patch by Joshua Hurwitz! llvm-svn: 288097
* [CUDA] Add Sema::CUDADiagBuilder and Sema::CUDADiagIf{Device,Host}Code().Justin Lebar2016-10-131-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Together these let you easily create diagnostics that - are never emitted for host code - are always emitted for __device__ and __global__ functions, and - are emitted for __host__ __device__ functions iff these functions are codegen'ed. At the moment there are only three diagnostics that need this treatment, but I have more to add, and it's not sustainable to write code for emitting every such diagnostic twice, and from a special wrapper in SemaCUDA.cpp. While we're at it, don't emit the function name in err_cuda_device_exceptions: It's not necessary to print it, and making this work in the new framework in the face of a null value for dyn_cast<FunctionDecl>(CurContext) isn't worth the effort. Reviewers: rnk Subscribers: cfe-commits, tra Differential Revision: https://reviews.llvm.org/D25139 llvm-svn: 284143
* PR25890: Fix incoherent error handling in PerformImplicitConversion andRichard Smith2016-10-061-0/+2
| | | | | | | | | | | | CheckSingleAssignmentConstraints. These no longer produce ExprError() when they have not emitted an error, and reliably inform the caller when they *have* emitted an error. This fixes some serious issues where we would fail to emit any diagnostic for invalid code and then attempt to emit code for an invalid AST, and conversely some issues where we would emit two diagnostics for the same problem. llvm-svn: 283508
* [CUDA] Disallow exceptions in device code.Justin Lebar2016-09-281-0/+4
| | | | | | | | | | Reviewers: tra Subscribers: cfe-commits, jhen Differential Revision: https://reviews.llvm.org/D25036 llvm-svn: 282646
* [ObjC] Warn on unguarded use of partial declarationErik Pilkington2016-08-161-1/+1
| | | | | | | | | | | | | | This commit adds a traversal of the AST after Sema of a function that diagnoses unguarded references to declarations that are partially available (based on availability attributes). This traversal is only done when we would otherwise emit -Wpartial-availability. This commit is part of a feature I proposed here: http://lists.llvm.org/pipermail/cfe-dev/2016-July/049851.html Differential revision: https://reviews.llvm.org/D23003 llvm-svn: 278826
* P0305R0: Semantic analysis and code generation for C++17 init-statement for ↵Richard Smith2016-07-141-13/+10
| | | | | | | | | | 'if' and 'switch': if (stmt; condition) { ... } Patch by Anton Bikineev! Some minor formatting and comment tweets by me. llvm-svn: 275350
* [Sema] Implement C++14's DR1579: Prefer returning by converting move constructorErik Pilkington2016-06-301-40/+51
| | | | | | | | Fixes PR28096. Differential Revision: http://reviews.llvm.org/D21619 llvm-svn: 274291
* P0305R1: Parsing support for init-statements in 'if' and 'switch' statements.Richard Smith2016-06-291-3/+10
| | | | | | | | | | | | | | | | | | No semantic analysis yet. This is a pain to disambiguate correctly, because the parsing rules for the declaration form of a condition and of an init-statement are quite different -- for a token sequence that looks like a declaration, we frequently need to disambiguate all the way to the ')' or ';'. We could do better here in some cases by stopping disambiguation once we've decided whether we've got an expression or not (rather than keeping going until we know whether it's an init-statement declaration or a condition declaration), by unifying our parsing code for the two types of declaration and moving the syntactic checks into Sema; if this has a measurable impact on parsing performance, I'll look into that. llvm-svn: 274169
* Implement p0292r2 (constexpr if), a likely C++1z feature.Richard Smith2016-06-231-20/+57
| | | | llvm-svn: 273602
* Re-commit r273548, reverted in r273589, with a fix to not produceRichard Smith2016-06-231-98/+59
| | | | | | | | | | | | | | | | -Wfor-loop-analysis warnings for a for-loop with a condition variable. In such a case, the loop condition variable is modified on each iteration of the loop by definition. Original commit message: Rearrange condition handling so that semantic checks on a condition variable are performed before the other substatements of the construct are parsed, rather than deferring them until the end. This allows better error recovery from semantic errors in the condition, improves diagnostic order, and is a prerequisite for C++17 constexpr if. llvm-svn: 273600
* Revert r273548, "Rearrange condition handling so that semantic checks on a ↵Peter Collingbourne2016-06-231-58/+98
| | | | | | | | condition variable" as it caused a regression in -Wfor-loop-analysis. llvm-svn: 273589
* Rearrange condition handling so that semantic checks on a condition variableRichard Smith2016-06-231-98/+58
| | | | | | | | | are performed before the other substatements of the construct are parsed, rather than deferring them until the end. This allows better error recovery from semantic errors in the condition, improves diagnostic order, and is a prerequisite for C++17 constexpr if. llvm-svn: 273548
* Re-commit "[Temporary] Add an ExprWithCleanups for each C++ ↵Tim Shen2016-06-211-0/+8
| | | | | | | | | | MaterializeTemporaryExpr." Since D21243 fixes relative clang-tidy tests. This reverts commit a71d9fbd41e99def9159af2b01ef6509394eaeed. llvm-svn: 273312
* Revert accidential "[MSVC] Late parsing of in-class defined member functions ↵Alexey Bataev2016-06-151-27/+0
| | | | | | | | in template" This reverts commit 0253605771b8bd9d414aba74fe2742c730d6fd1a. llvm-svn: 272776
* [MSVC] Late parsing of in-class defined member functions in templateAlexey Bataev2016-06-151-0/+27
| | | | | | | | | | | | | | | | | | | classes. MSVC actively uses unqualified lookup in dependent bases, lookup at the instantiation point (non-dependent names may be resolved on things declared later) etc. and all this stuff is the main cause of incompatibility between clang and MSVC. Clang tries to emulate MSVC behavior but it may fail in many cases. clang could store lexed tokens for member functions definitions within ClassTemplateDecl for later parsing during template instantiation. It will allow resolving many possible issues with lookup in dependent base classes and removing many already existing MSVC-specific hacks/workarounds from the clang code. llvm-svn: 272774
OpenPOWER on IntegriCloud