summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema
Commit message (Collapse)AuthorAgeFilesLines
...
* Reland r348741 "[Sema] Further improvements to to static_assert diagnostics."Clement Courbet2018-12-112-34/+40
| | | | | | Fix a dangling reference to temporary, never return nullptr. llvm-svn: 348834
* Revert r348830 "[Sema]improve static_assert(!expr)"Clement Courbet2018-12-111-14/+0
| | | | | | Submitted the wrong change. llvm-svn: 348831
* [Sema]improve static_assert(!expr)Clement Courbet2018-12-111-0/+14
| | | | llvm-svn: 348830
* [constexpr][c++2a] Try-catch blocks in constexpr functionsBruno Cardoso Lopes2018-12-101-14/+49
| | | | | | | | | | | | | | | | | | | | | | Implement support for try-catch blocks in constexpr functions, as proposed in http://wg21.link/P1002 and voted in San Diego for c++20. The idea is that we can still never throw inside constexpr, so the catch block is never entered. A try-catch block like this: try { f(); } catch (...) { } is then morally equivalent to just { f(); } Same idea should apply for function/constructor try blocks. rdar://problem/45530773 Differential Revision: https://reviews.llvm.org/D55097 llvm-svn: 348789
* Use zip_longest for iterator range comparisons. NFC.Michael Kruse2018-12-101-10/+13
| | | | | | | | | | | | | | | | | | | Use zip_longest in two locations that compare iterator ranges. zip_longest allows the iteration using a range-based for-loop and to be symmetric over both ranges instead of prioritizing one over the other. In that latter case code have to handle the case that the first is longer than the second, the second is longer than the first, and both are of the same length, which must partially be checked after the loop. With zip_longest, this becomes an element comparison within the loop like the comparison of the elements themselves. The symmetry makes it clearer that neither the first and second iterators are handled differently. The iterators are not event used directly anymore, just the ranges. Differential Revision: https://reviews.llvm.org/D55468 llvm-svn: 348762
* Misc typos fixes in ./lib folderRaphael Isemann2018-12-107-12/+12
| | | | | | | | | | | | | | 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
* Revert r348741 "[Sema] Further improvements to to static_assert diagnostics."Clement Courbet2018-12-102-42/+38
| | | | | | Seems to break build bots. llvm-svn: 348742
* [Sema] Further improvements to to static_assert diagnostics.Clement Courbet2018-12-102-38/+42
| | | | | | | | | | | | | | Summary: We're now handling cases like `static_assert(!expr)` and static_assert(!(expr))`. Reviewers: aaron.ballman, Quuxplusone Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D55270 llvm-svn: 348741
* [CodeComplete] Fix assertion failureIlya Biryukov2018-12-071-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: ...that fires when running completion inside an argument of UnresolvedMemberExpr (see the added test). The assertion that fires is from Sema::TryObjectArgumentInitialization: assert(FromClassification.isLValue()); This happens because Sema::AddFunctionCandidates does not account for object types which are pointers. It ends up classifying them incorrectly. All usages of the function outside code completion are used to run overload resolution for operators. In those cases the object type being passed is always a non-pointer type, so it's not surprising the function did not expect a pointer in the object argument. However, code completion reuses the same function and calls it with the object argument coming from UnresolvedMemberExpr, which can be a pointer if the member expr is an arrow ('->') access. Extending AddFunctionCandidates to allow pointer object types does not seem too crazy since all the functions down the call chain can properly handle pointer object types if we properly classify the object argument as an l-value, i.e. the classification of the implicitly dereferenced pointer. Reviewers: kadircet Reviewed By: kadircet Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D55331 llvm-svn: 348590
* [attributes] Add an attribute os_consumes_this, with similar semantics to ↵George Karpenkov2018-12-061-0/+3
| | | | | | | | | | | ns_consumes_self The attribute specifies that the call of the C++ method consumes a reference to "this". Differential Revision: https://reviews.llvm.org/D55155 llvm-svn: 348532
* Diagnose friend function template redefinitions.Serge Pavlov2018-12-062-1/+26
| | | | | | | | | | | | | | Friend function template defined in a class template becomes available if the enclosing class template is instantiated. Until the function template is used, it does not have a body, but still is considered a definition for the purpose of redeclaration checks. This change modifies redefinition check so that it can find the friend function template definitions in instantiated classes. Differential Revision: http://reviews.llvm.org/D21508 llvm-svn: 348473
* [Sema/Attribute] Check for noderef attributeLeonard Chan2018-12-064-7/+199
| | | | | | | | | | 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
* [Sema] Push and Pop Expression Evaluation Context Records at the start and ↵Leonard Chan2018-12-063-5/+30
| | | | | | | | | | | | end of function definitions This patch creates a new context for every function definition we enter. Currently we do not push and pop on these, usually working off of the global context record added in the Sema constructor, which never gets popped. Differential Revision: https://reviews.llvm.org/D54014 llvm-svn: 348434
* [Hexagon] Add intrinsics for Hexagon V66Krzysztof Parzyszek2018-12-051-735/+747
| | | | llvm-svn: 348419
* Do not check for parameters shadowing fields in function declarations.Aaron Ballman2018-12-052-7/+12
| | | | | | We would issue a false-positive diagnostic for parameters in function declarations shadowing fields; we now only issue the diagnostic on a function definition instead. llvm-svn: 348400
* [CodeComplete] Fix a crash in access checks of inner classesIlya Biryukov2018-12-052-12/+31
| | | | | | | | | | | | | | Summary: The crash was introduced in r348135. Reviewers: kadircet Reviewed By: kadircet Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D55260 llvm-svn: 348387
* [OpenCL] Diagnose conflicting address spaces in templates.Anastasia Stulova2018-12-052-16/+29
| | | | | | | | | | | | | Added new diagnostic when templates are instantiated with different address space from the one provided in its definition. This also prevents deducing generic address space in pointer type of templates to allow giving them concrete address space during instantiation. Differential Revision: https://reviews.llvm.org/D55127 llvm-svn: 348382
* Fix crash if an in-class explicit function specialization has explicitRichard Smith2018-12-041-10/+12
| | | | | | template arguments referring to template paramaeters. llvm-svn: 348313
* [WIP][Sema] Improve static_assert diagnostics for type traits.Clement Courbet2018-12-041-1/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In our codebase, `static_assert(std::some_type_trait<Ts...>::value, "msg")` (where `some_type_trait` is an std type_trait and `Ts...` is the appropriate template parameters) account for 11.2% of the `static_assert`s. In these cases, the `Ts` are typically not spelled out explicitly, e.g. `static_assert(std::is_same<SomeT::TypeT, typename SomeDependentT::value_type>::value, "message");` The diagnostic when the assert fails is typically not very useful, e.g. `static_assert failed due to requirement 'std::is_same<SomeT::TypeT, typename SomeDependentT::value_type>::value' "message"` This change makes the diagnostic spell out the types explicitly , e.g. `static_assert failed due to requirement 'std::is_same<int, float>::value' "message"` See tests for more examples. After this is submitted, I intend to handle `static_assert(!std::some_type_trait<Ts...>::value, "msg")`, which is another 6.6% of static_asserts. Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D54903 llvm-svn: 348239
* [Sema] Provide -fvisibility-global-new-delete-hidden optionPetr Hosek2018-12-041-3/+4
| | | | | | | | | | | | | | | | | | | | | | | When the global new and delete operators aren't declared, Clang provides and implicit declaration, but this declaration currently always uses the default visibility. This is a problem when the C++ library itself is being built with non-default visibility because the implicit declaration will force the new and delete operators to have the default visibility unlike the rest of the library. The existing workaround is to use assembly to enforce the visiblity: https://fuchsia.googlesource.com/zircon/+/master/system/ulib/zxcpp/new.cpp#108 but that solution is not always available, e.g. in the case of of libFuzzer which is using an internal version of libc++ that's also built with -fvisibility=hidden where the existing behavior is causing issues. This change introduces a new option -fvisibility-global-new-delete-hidden which makes the implicit declaration of the global new and delete operators hidden. Differential Revision: https://reviews.llvm.org/D53787 llvm-svn: 348234
* Fix -Wmismatched-tags to not warn on redeclarations of structs in systemRichard Smith2018-12-041-46/+76
| | | | | | | | | | | | | | | | | | | | | | | | headers. Previously, we would only check whether the new declaration is in a system header, but that requires the user to be able to correctly guess whether a declaration in a system header is declared as a struct or a class when specializing standard library traits templates. We now entirely ignore declarations for which the warning was disabled when determining whether to warn on a tag mismatch. Also extend the diagnostic message to clarify that a) code containing such a tag mismatch is in fact valid and correct, and b) the (non-coding-style) reason to emit such a warning is that the Microsoft C++ ABI is broken and includes the tag kind in decorated names, as it seems a lot of users are confused by our diagnostic here (either not understanding why we produce it, or believing that it represents an actual language rule). llvm-svn: 348233
* [AST][Sema] Remove CallExpr::setNumArgsBruno Ricci2018-12-032-41/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CallExpr::setNumArgs is the only thing that prevents storing the arguments in a trailing array. There is only 3 places in Sema where setNumArgs is called. D54900 dealt with one of them. This patch remove the other two calls to setNumArgs in ConvertArgumentsForCall. To do this we do the following changes: 1.) Replace the first call to setNumArgs by an assertion since we are moving the responsability to allocate enough space for the arguments from Sema::ConvertArgumentsForCall to its callers (which are Sema::BuildCallToMemberFunction, and Sema::BuildResolvedCallExpr). 2.) Add a new member function CallExpr::shrinkNumArgs, which can only be used to drop arguments and then replace the second call to setNumArgs by shrinkNumArgs. 3.) Add a new defaulted parameter MinNumArgs to CallExpr and its derived classes which specifies a minimum number of argument slots to allocate. The actual number of arguments slots allocated will be max(number of args, MinNumArgs) with the extra args nulled. Note that after the creation of the call expression all of the arguments will be non-null. It is just during the creation of the call expression that some of the last arguments can be temporarily null, until filled by default arguments. 4.) Update Sema::BuildCallToMemberFunction by passing the number of parameters in the function prototype to the constructor of CXXMemberCallExpr. Here the change is pretty straightforward. 5.) Update Sema::BuildResolvedCallExpr. Here the change is more complicated since the type-checking for the function type was done after the creation of the call expression. We need to move this before the creation of the call expression, and then pass the number of parameters in the function prototype (if any) to the constructor of the call expression. 6.) Update the deserialization of CallExpr and its derived classes. Differential Revision: https://reviews.llvm.org/D54902 Reviewed By: aaron.ballman llvm-svn: 348145
* [OpenCL][Sema] Improving formattingMarco Antognini2018-12-031-3/+2
| | | | | | | Reformat comment added in r348120 following review https://reviews.llvm.org/D55136. llvm-svn: 348139
* [CodeComplete] Cleanup access checking in code completionIlya Biryukov2018-12-033-40/+63
| | | | | | | | | | | | | | Summary: Also fixes a crash (see the added 'accessibility-crash.cpp' test). Reviewers: ioeric, kadircet Reviewed By: kadircet Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D55124 llvm-svn: 348135
* [Sema] Avoid CallExpr::setNumArgs in Sema::BuildCallToObjectOfClassTypeBruno Ricci2018-12-031-25/+23
| | | | | | | | | | | | | | | | | | | | | | CallExpr::setNumArgs is the only thing that prevents storing the arguments of a call expression in a trailing array since it might resize the argument array. setNumArgs is only called in 3 places in Sema, and for all of them it is possible to avoid it. This deals with the call to setNumArgs in BuildCallToObjectOfClassType. Instead of constructing the CXXOperatorCallExpr first and later calling setNumArgs if we have default arguments, we first construct a large enough SmallVector, do the promotion/check of the arguments, and then construct the CXXOperatorCallExpr. Incidentally this also avoid reallocating the arguments when the call operator has default arguments but this is not the primary goal. Differential Revision: https://reviews.llvm.org/D54900 Reviewed By: aaron.ballman llvm-svn: 348134
* [OpenCL][Sema] Improve BuildResolvedCallExpr handling of builtinsMarco Antognini2018-12-031-7/+10
| | | | | | | | | | | | | | | | | | | | | Summary: This is a follow-up on https://reviews.llvm.org/D52879, addressing a few issues. This: - adds a FIXME for later improvement for specific builtins: I previously have only checked OpenCL ones and ensured tests cover those. - fixed the CallExpr type. Reviewers: riccibruno Reviewed By: riccibruno Subscribers: yaxunl, Anastasia, kristina, svenvh, cfe-commits Differential Revision: https://reviews.llvm.org/D55136 llvm-svn: 348120
* OpenCL: Extend argument promotion rules to vector typesMatt Arsenault2018-12-011-5/+18
| | | | | | | | The spec is ambiguous on whether vector types are allowed to be implicitly converted. The only legal context I think this can be used for OpenCL is printf, where it seems necessary. llvm-svn: 348083
* Revert "Revert r347417 "Re-Reinstate 347294 with a fix for the failures.""Fangrui Song2018-11-3013-80/+133
| | | | | | | | | 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
* Revert r347417 "Re-Reinstate 347294 with a fix for the failures."Fangrui Song2018-11-3013-133/+80
| | | | | | | | | | 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
* [attributes] Add a family of OS_CONSUMED, OS_RETURNS and OS_RETURNS_RETAINED ↵George Karpenkov2018-11-302-66/+149
| | | | | | | | | | | | | | | | | | | | | attributes The addition adds three attributes for communicating ownership, analogous to existing NS_ and CF_ attributes. The attributes are meant to be used for communicating ownership of all objects in XNU (Darwin kernel) and all of the kernel modules. The ownership model there is very similar, but still different from the Foundation model, so we think that introducing a new family of attributes is appropriate. The addition required a sizeable refactoring of the existing code for CF_ and NS_ ownership attributes, due to tight coupling and the fact that differentiating between the types was previously done using a boolean. Differential Revision: https://reviews.llvm.org/D54912 llvm-svn: 347947
* [OpenCL] Improve diags for addr spaces in templatesAnastasia Stulova2018-11-293-21/+31
| | | | | | | | | | | Fix ICEs on template instantiations that were leading to the creation of invalid code patterns with address spaces. Incorrect cases are now diagnosed properly. Differential Revision: https://reviews.llvm.org/D54858 llvm-svn: 347865
* Allow cpu-dispatch forward declarations.Erich Keane2018-11-281-8/+9
| | | | | | | | As a followup to r347805, allow forward declarations of cpu-dispatch and cpu-specific for the same reasons. Change-Id: Ic1bde9be369b1f8f1d47d58e6fbdc2f9dfcdd785 llvm-svn: 347812
* Correct 'target' default behavior on redecl, allow forward declaration.Erich Keane2018-11-281-5/+47
| | | | | | | | | | | | | | | | | | | | | | | Declarations without the attribute were disallowed because it would be ambiguous which 'target' it was supposed to be on. For example: void ___attribute__((target("v1"))) foo(); void foo(); // Redecl of above, or fwd decl of below? void ___attribute__((target("v2"))) foo(); However, a first declaration doesn't have that problem, and erroring prevents it from working in cases where the forward declaration is useful. Additionally, a forward declaration of target==default wouldn't properly cause multiversioning, so this patch fixes that. The patch was not split since the 'default' fix would require implementing the same check for that case, followed by undoing the same change for the fwd-decl implementation. Change-Id: I66f2c5bc2477bcd3f7544b9c16c83ece257077b0 llvm-svn: 347805
* [OPENMP]Fix emission of the target regions in virtual functions.Alexey Bataev2018-11-281-1/+4
| | | | | | | | Fixed emission of the target regions found in the virtual functions. Previously we may end up with the situation when those regions could be skipped. llvm-svn: 347793
* [NFC] Move MultIversioning::Type into Decl so that it can be used inErich Keane2018-11-281-43/+29
| | | | | | | CodeGen Change-Id: I32b14edca3501277e0e65672eafe3eea38c6f9ae llvm-svn: 347791
* Re-commit r347417 "Re-Reinstate 347294 with a fix for the failures."Hans Wennborg2018-11-2813-80/+133
| | | | | | | 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
* Move LoopHint.h from Sema to ParseRichard Trieu2018-11-281-1/+0
| | | | | | | | struct LoopHint was only used within Parse and not in any of the Sema or Codegen files. In the non-Parse files where it was included, it either wasn't used or LoopHintAttr was used, so its inclusion did nothing. llvm-svn: 347728
* [clang][slh] add attribute for speculative load hardeningZola Bridges2018-11-271-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Resubmit this with no changes because I think the build was broken by a different diff. ----- The prior diff had to be reverted because there were two tests that failed. I updated the two tests in this diff clang/test/Misc/pragma-attribute-supported-attributes-list.test clang/test/SemaCXX/attr-speculative-load-hardening.cpp ----- Summary from Previous Diff (Still Accurate) ----- LLVM IR already has an attribute for speculative_load_hardening. Before this commit, when a user passed the -mspeculative-load-hardening flag to Clang, every function would have this attribute added to it. This Clang attribute will allow users to opt into SLH on a function by function basis. This can be applied to functions and Objective C methods. Reviewers: chandlerc, echristo, kristof.beyls, aaron.ballman Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D54915 llvm-svn: 347701
* Derive builtin return type from its definitionMarco Antognini2018-11-272-10/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Prior to this patch, OpenCL code such as the following would attempt to create a BranchInst with a non-bool argument: if (enqueue_kernel(get_default_queue(), 0, nd, ^(void){})) /* ... */ This patch is a follow up on a similar issue with pipe builtin operations. See commit r280800 and https://bugs.llvm.org/show_bug.cgi?id=30219. This change, while being conservative on non-builtin functions, should set the type of expressions invoking builtins to the proper type, instead of defaulting to `bool` and requiring manual overrides in Sema::CheckBuiltinFunctionCall. In addition to tests for enqueue_kernel, the tests are extended to check other OpenCL builtins. Reviewers: Anastasia, spatel, rsmith Reviewed By: Anastasia Subscribers: kristina, cfe-commits, svenvh Differential Revision: https://reviews.llvm.org/D52879 llvm-svn: 347658
* Revert r347417 "Re-Reinstate 347294 with a fix for the failures."Hans Wennborg2018-11-2713-133/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "[clang][slh] add attribute for speculative load hardening"Zola Bridges2018-11-271-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | until I figure out why the build is failing or timing out *************************** Summary: The prior diff had to be reverted because there were two tests that failed. I updated the two tests in this diff clang/test/Misc/pragma-attribute-supported-attributes-list.test clang/test/SemaCXX/attr-speculative-load-hardening.cpp LLVM IR already has an attribute for speculative_load_hardening. Before this commit, when a user passed the -mspeculative-load-hardening flag to Clang, every function would have this attribute added to it. This Clang attribute will allow users to opt into SLH on a function by function basis. This can be applied to functions and Objective C methods. Reviewers: chandlerc, echristo, kristof.beyls, aaron.ballman Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D54915 This reverts commit a5b3c232d1e3613f23efbc3960f8e23ea70f2a79. (r347617) llvm-svn: 347628
* [clang][slh] add attribute for speculative load hardeningZola Bridges2018-11-271-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The prior diff had to be reverted because there were two tests that failed. I updated the two tests in this diff clang/test/Misc/pragma-attribute-supported-attributes-list.test clang/test/SemaCXX/attr-speculative-load-hardening.cpp ----- Summary from Previous Diff (Still Accurate) ----- LLVM IR already has an attribute for speculative_load_hardening. Before this commit, when a user passed the -mspeculative-load-hardening flag to Clang, every function would have this attribute added to it. This Clang attribute will allow users to opt into SLH on a function by function basis. This can be applied to functions and Objective C methods. Reviewers: chandlerc, echristo, kristof.beyls, aaron.ballman Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D54915 llvm-svn: 347617
* Revert "[clang][slh] add attribute for speculative load hardening"Zola Bridges2018-11-261-3/+0
| | | | | | This reverts commit 801eaf91221ba6dd6996b29ff82659ad6359e885. llvm-svn: 347588
* [clang][slh] add attribute for speculative load hardeningZola Bridges2018-11-261-0/+3
| | | | | | | | | | | | | | | | | | Summary: LLVM IR already has an attribute for speculative_load_hardening. Before this commit, when a user passed the -mspeculative-load-hardening flag to Clang, every function would have this attribute added to it. This Clang attribute will allow users to opt into SLH on a function by function basis. This can be applied to functions and Objective C methods. Reviewers: chandlerc, echristo Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D54555 llvm-svn: 347586
* [AArch64] Add aarch64_vector_pcs function attribute to ClangSander de Smalen2018-11-262-8/+20
| | | | | | | | | | | | | | | | | | | | This is the Clang patch to complement the following LLVM patches: https://reviews.llvm.org/D51477 https://reviews.llvm.org/D51479 More information describing the vector ABI and procedure call standard can be found here: https://developer.arm.com/products/software-development-tools/\ hpc/arm-compiler-for-hpc/vector-function-abi Patch by Kerry McLaughlin. Reviewed By: rjmccall Differential Revision: https://reviews.llvm.org/D54425 llvm-svn: 347571
* [CodeComplete] Simplify CodeCompleteConsumer.cpp, NFCFangrui Song2018-11-251-77/+69
| | | | | | | | Use range-based for loops Use XStr.compare(YStr) < 0 Format misaligned code llvm-svn: 347529
* isEvaluatable() implies a constant context.Bill Wendling2018-11-241-1/+6
| | | | | | | | | | 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. llvm-svn: 347512
* [CodeComplete] Delete unused variable in rC342449Fangrui Song2018-11-241-1/+0
| | | | llvm-svn: 347508
* [CodeComplete] Format SemaCodeComplete.cpp and improve code consistencyFangrui Song2018-11-241-1187/+1135
| | | | | | | | | There are some mis-indented places and missing spaces here and there. Just format the whole file. Also, newer code (from 2014 onwards) in this file prefers const auto *X = dyn_cast to not repeat the Decl type name. Make other occurrences consistent. Remove two anonymous namespaces that are not very necessary: 1) a typedef 2) a local function (should use static) llvm-svn: 347507
* Re-Reinstate 347294 with a fix for the failures.Bill Wendling2018-11-2113-80/+128
| | | | | | | | | 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
OpenPOWER on IntegriCloud