summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix PR34668 - P0704R1 implementation is too permissiveNicolas Lesser2018-07-131-2/+3
| | | | | | | | | | | | | | | | | | | Summary: https://bugs.llvm.org/show_bug.cgi?id=34668 Pretty straightforward. Reviewers: rsmith, Rakete1111 Reviewed By: Rakete1111 Subscribers: Rakete1111, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D38075 llvm-svn: 337017
* [NFC] Rename clang::AttributeList to clang::ParsedAttrErich Keane2018-07-1311-821/+780
| | | | | | | Since The type no longer contains the 'next' item anymore, it isn't a list, so rename it to ParsedAttr to be more accurate. llvm-svn: 337005
* PR38136: improve handling of template argument deduction of non-trailingRichard Smith2018-07-121-28/+52
| | | | | | | | | | | | | | | | | | | | | function parameter packs. This makes our handling of non-trailing function parameter packs consistent between the case of deduction at the top level in a function call and other cases where deduction encounters a non-trailing function parameter pack. Instead of treating a non-trailing pack and all later parameters as being non-deduced, we treat a non-trailing pack as exactly matching any explicitly-specified template arguments (or being an empty pack if there are no such arguments). This corresponds to the "never deduced" rule in [temp.deduct.call]p1, but generalized to all deduction contexts. Non-trailing template argument packs still result in the entire template argument list being treated as non-deduced, as specified in [temp.deduct.type]p9. llvm-svn: 336962
* PR38141: check whether noexcept-specifications are equivalent in redeclarationsRichard Smith2018-07-121-4/+10
| | | | llvm-svn: 336946
* AttributeList de-listifying:Erich Keane2018-07-1215-601/+431
| | | | | | | | | | | Basically, "AttributeList" loses all list-like mechanisms, ParsedAttributes is switched to use a TinyPtrVector (and a ParsedAttributesView is created to have a non-allocating attributes list). DeclaratorChunk gets the later kind, Declarator/DeclSpec keep ParsedAttributes. Iterators are added to the ParsedAttribute types so that for-loops work. llvm-svn: 336945
* [Hexagon] Diagnose intrinsics not supported by selected CPU/HVXKrzysztof Parzyszek2018-07-121-2/+792
| | | | llvm-svn: 336933
* Add tests for function conversions in conversion function templateRichard Smith2018-07-121-0/+3
| | | | | | deduction. llvm-svn: 336931
* [C++17] Disallow lambdas in template parameters (PR33696).Nicolas Lesser2018-07-124-26/+35
| | | | | | | | | | | | | | Summary: This revision disallows lambdas in template parameters, as reported in PR33696. Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D37442 llvm-svn: 336930
* [C++11] Fix warning when dropping cv-qualifiers when assigning to a ↵Nicolas Lesser2018-07-121-16/+29
| | | | | | reference with a braced initializer list llvm-svn: 336922
* [ASTImporter] Refactor Decl creationGabor Marton2018-07-121-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Generalize the creation of Decl nodes during Import. With this patch we do the same things after and before a new AST node is created (::Create) The import logic should be really simple, we create the node, then we mark that as imported, then we recursively import the parts for that node and then set them on that node. However, the AST is actually a graph, so we have to handle circles. If we mark something as imported (`MapImported()`) then we return with the corresponding `To` decl whenever we want to import that node again, this way circles are handled. In order to make this algorithm work we must ensure things, which are handled in the generic CreateDecl<> template: * There are no `Import()` calls in between any node creation (::Create) and the `MapImported()` call. * Before actually creating an AST node (::Create), we must check if the Node had been imported already, if yes then return with that one. One very important case for this is connected to templates: we may start an import both from the templated decl of a template and from the template itself. Now, the virtual `Imported` function is called in `ASTImporter::Impor(Decl *)`, but only once, when the `Decl` is imported. One point of this refactor is to separate responsibilities. The original `Imported()` had 3 responsibilities: - notify subclasses when an import happened - register the decl into `ImportedDecls` - initialise the Decl (set attributes, etc) Now all of these are in separate functions: - `Imported` - `MapImported` - `InitializeImportedDecl` I tried to check all the clients, I executed tests for `ExternalASTMerger.cpp` and some unittests for lldb. Reviewers: a.sidorin, balazske, xazax.hun, r.stahl Subscribers: rnkovacs, dkrupp, cfe-commits Differential Revision: https://reviews.llvm.org/D47632 llvm-svn: 336896
* Fix deduction for conversion function templates converting to referenceRichard Smith2018-07-111-4/+29
| | | | | | | | | | | | | | | | | | | types. We previously tried to use the "parameter is a reference" logic here, but that doesn't work because it gets P and A backwards. Instead, add a separate implementation of the "deduced A can be less qualified than A" rule. This also exposes that we incorrectly stripped cv-qualifiers from the referent of A if it was a reference. However, if we don't do that, we get the wrong results when P is a reference. In an attempt to match what sanity dictates and what other implementations are doing, we now remove cv-qualifiers from A and P unless both are reference types. I've brought this up on the core reflector too, to try to get the standard fixed. llvm-svn: 336867
* Fix determination of whether one set of cvr-qualifiers is compatibleRichard Smith2018-07-111-6/+6
| | | | | | | | | | with another in template argument deduction. We happened to typically get away with getting this wrong, because the cases where we'd produce a bogus deduction were caught by the final "deduced A is compatible with A" check. llvm-svn: 336852
* [NFC] Replace usage of QualType.getTypePtr()-> with operator->Erich Keane2018-07-111-1/+1
| | | | llvm-svn: 336836
* [clangd] Uprank delcarations when "using q::name" is present in the main fileKirill Bobyrev2018-07-111-14/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | Having `using qualified::name;` for some symbol is an important signal for clangd code completion as the user is more likely to use such symbol. This patch helps to uprank the relevant symbols by saving UsingShadowDecl in the new field of CodeCompletionResult and checking whether the corresponding UsingShadowDecl is located in the main file later in ClangD code completion routine. While the relative importance of such signal is a subject to change in the future, this patch simply bumps DeclProximity score to the value of 1.0 which should be enough for now. The patch was tested using `$ ninja check-clang check-clang-tools` No unexpected failures were noticed after running the relevant testsets. Reviewers: sammccall, ioeric Subscribers: MaskRay, jkorous, cfe-commits Differential Revision: https://reviews.llvm.org/D49012 llvm-svn: 336810
* DR330: look through array types when forming the cv-decomposition of a type.Richard Smith2018-07-112-43/+31
| | | | | | | | | | This allows more qualification conversions, eg. conversion from 'int *(*)[]' -> 'const int *const (*)[]' is now permitted, along with all the consequences of that: more types are similar, more cases are permitted by const_cast, and conversely, fewer "casting away constness" cases are permitted by reinterpret_cast. llvm-svn: 336745
* Fix determination of whether a reinterpret_cast casts away constness.Richard Smith2018-07-101-177/+184
| | | | | | | | | | | | | | The "casts away constness" check doesn't care at all how the different layers of the source and destination type were formed: for example, if the source is a pointer and the destination is a pointer-to-member, the types are still decomposed and their pointee qualifications are still checked. This rule is bizarre and somewhat ridiculous, so as an extension we accept code making use of such reinterpret_casts with a warning outside of SFINAE contexts. llvm-svn: 336738
* Revert -r336726, which included more files than intended.Erich Keane2018-07-104-188/+43
| | | | llvm-svn: 336727
* [NFC] Switch CodeGenFunction to use value init instead of member init listsErich Keane2018-07-104-43/+188
| | | | | | | | The member init list for the sole constructor for CodeGenFunction has gotten out of hand, so this patch moves the non-parameter-dependent initializations into the member value inits. llvm-svn: 336726
* [Sema] Fix a structured binding typo correction bugErik Pilkington2018-07-101-0/+2
| | | | | | | | | BindingDecls have null type until their initializer is processed, so we can't assume that a correction candidate has non-null type. rdar://41559582 llvm-svn: 336634
* [OPENMP] Do not mark local variables as declare target.Alexey Bataev2018-07-091-1/+5
| | | | | | | | | When the parsing of the functions happens inside of the declare target region, we may erroneously mark local variables as declare target thought they are not. This attribute can be applied only to global variables. llvm-svn: 336592
* [Builtins][Attributes][X86] Tag all X86 builtins with their required vector ↵Craig Topper2018-07-091-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | width. Add a min_vector_width function attribute and tag all x86 instrinsics with it This is part of an ongoing attempt at making 512 bit vectors illegal in the X86 backend type legalizer due to CPU frequency penalties associated with wide vectors on Skylake Server CPUs. We want the loop vectorizer to be able to emit IR containing wide vectors as intermediate operations in vectorized code and allow these wide vectors to be legalized to 256 bits by the X86 backend even though we are targetting a CPU that supports 512 bit vectors. This is similar to what happens with an AVX2 CPU, the vectorizer can emit wide vectors and the backend will split them. We want this splitting behavior, but still be able to use new Skylake instructions that work on 256-bit vectors and support things like masking and gather/scatter. Of course if the user uses explicit vector code in their source code we need to not split those operations. Especially if they have used any of the 512-bit vector intrinsics from immintrin.h. And we need to make it so that merely using the intrinsics produces the expected code in order to be backwards compatible. To support this goal, this patch adds a new IR function attribute "min-legal-vector-width" that can indicate the need for a minimum vector width to be legal in the backend. We need to ensure this attribute is set to the largest vector width needed by any intrinsics from immintrin.h that the function uses. The inliner will be reponsible for merging this attribute when a function is inlined. We may also need a way to limit inlining in the future as well, but we can discuss that in the future. To make things more complicated, there are two different ways intrinsics are implemented in immintrin.h. Either as an always_inline function containing calls to builtins(can be target specific or target independent) or vector extension code. Or as a macro wrapper around a taget specific builtin. I believe I've removed all cases where the macro was around a target independent builtin. To support the always_inline function case this patch adds attribute((min_vector_width(128))) that can be used to tag these functions with their vector width. All x86 intrinsic functions that operate on vectors have been tagged with this attribute. To support the macro case, all x86 specific builtins have also been tagged with the vector width that they require. Use of any builtin with this property will implicitly increase the min_vector_width of the function that calls it. I've done this as a new property in the attribute string for the builtin rather than basing it on the type string so that we can opt into it on a per builtin basis and avoid any impact to target independent builtins. There will be future work to support vectors passed as function arguments and supporting inline assembly. And whatever else we can find that isn't covered by this patch. Special thanks to Chandler who suggested this direction and reviewed a preview version of this patch. And thanks to Eric Christopher who has had many conversations with me about this issue. Differential Revision: https://reviews.llvm.org/D48617 llvm-svn: 336583
* P0806R2 Implicit capture of this with a capture-default of [=] isRichard Smith2018-07-071-0/+11
| | | | | | | | | | deprecated. Add a -Wdeprecated warning for this in C++2a onwards. (In C++17 and before, there isn't a reasonable alternative because [=,this] is ill-formed.) llvm-svn: 336480
* [Sema] Emit -Wincomplete-implementation for partial methods.Erik Pilkington2018-07-071-10/+2
| | | | | | Fixes rdar://40634455 llvm-svn: 336478
* Check returned type is valid before using it.Richard Trieu2018-07-071-0/+3
| | | | | | Add a .isNull() check to returned QualType. Fixes PR38077 llvm-svn: 336475
* [SemaCodeComplete] Expose a method to create CodeCompletionString for macros.Eric Liu2018-07-061-44/+49
| | | | | | | | | | | | | | | | | Summary: The method only takes PPreprocessor and don't require structures that might not be available (e.g. Sema and ASTContext) when CodeCompletionString needs to be generated for macros. Reviewers: sammccall Reviewed By: sammccall Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D48973 llvm-svn: 336427
* [Sema] -Wformat-pedantic only for NSInteger/NSUInteger %tu/%td on DarwinAlex Lorenz2018-07-051-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The '%tu'/'%td' as formatting specifiers have been used to print out the NSInteger/NSUInteger values for a long time. Typically their ABI matches, but that's not the case on watchOS. The ABI difference boils down to the following: - Regular 32-bit darwin targets (like armv7) use 'ptrdiff_t' of type 'int', which matches 'NSInteger'. - WatchOS arm target (armv7k) uses 'ptrdiff_t' of type 'long', which doesn't match 'NSInteger' of type 'int'. Because of this ABI difference these specifiers trigger -Wformat warnings only for watchOS builds, which is really inconvenient for cross-platform code. This patch avoids this -Wformat warning for '%tu'/'%td' and NS[U]Integer only, and instead uses the new -Wformat-pedantic warning that JF introduced in https://reviews.llvm.org/D47290. This is acceptable because Darwin guarantees that, despite the watchOS ABI differences, sizeof(ptrdiff_t) == sizeof(NS[U]Integer), and alignof(ptrdiff_t) == alignof(NS[U]Integer) so the warning is therefore noisy for pedantic reasons. I'll update public documentation to ensure that this behaviour is properly communicated. rdar://41739204 Differential Revision: https://reviews.llvm.org/D48852 llvm-svn: 336396
* [NFS] Wipe trailing whitespacesKirill Bobyrev2018-07-051-740/+740
| | | | | | | | This patch is a preparation for another one containing meaningful changes. This patch simply removes trailing whitespaces in few files affected by the upcoming patch and reformats llvm-svn: 336330
* [SemaCodeComplete] Make sure visited contexts are passed to completion ↵Eric Liu2018-07-041-107/+75
| | | | | | | | | | | | results handler. Reviewers: ilya-biryukov Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D48917 llvm-svn: 336255
* [Sema] Fix crash in getConstructorName.Ilya Biryukov2018-07-041-0/+2
| | | | | | | | | | | | | | | | Summary: Can happen when getConstructorName is called on invalid decls, specifically the ones that do not have the injected class name. Reviewers: bkramer, rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D48880 llvm-svn: 336244
* [Sema] Consider all format_arg attributes.Michael Kruse2018-07-041-6/+15
| | | | | | | | | | | | | | | | If a function has multiple format_arg attributes, clang only considers the first it finds (because AttributeLists are in reverse order, not necessarily the textually first) and ignores all others. Loop over all FormatArgAttr to print warnings for all declared format_arg attributes. For instance, libintl's ngettext (select plural or singular version of format string) has two __format_arg__ attributes. Differential Revision: https://reviews.llvm.org/D48734 llvm-svn: 336239
* [Sema] Discarded statment should be an evaluatable context.Erik Pilkington2018-07-031-1/+1
| | | | | | | | | | The constexpr evaluator was erroring out because these templates weren't defined. Despite being used in a discarded statement, we still need to constexpr evaluate them, which means that we need to instantiate them. Fixes PR37585. Differential revision: https://reviews.llvm.org/D48322 llvm-svn: 336233
* Per C++ [over.match.copy]p1, direct-initialization of a reference canRichard Smith2018-07-021-4/+6
| | | | | | only invoke converting constructors of the reference's underlying type. llvm-svn: 336153
* [X86] Remove masking from the avx512 rotate builtins. Use a select builtin ↵Craig Topper2018-06-301-12/+12
| | | | | | instead. llvm-svn: 336036
* Add protocol redefinition to the current scope/contextBruno Cardoso Lopes2018-06-301-0/+5
| | | | | | | | | | | | Not doing so causes the AST writter to assert since the decl in question never gets emitted. This is fine when modules is not used, but otherwise we need to serialize something other than garbage. rdar://problem/39844933 Differential Revision: https://reviews.llvm.org/D47297 llvm-svn: 336031
* [Fixed Point Arithmetic] Rename `-fsame-fbits` flagLeonard Chan2018-06-291-1/+1
| | | | | | | | | | | - Rename the `-fsame-fbits` flag to `-fpadding-on-unsigned-fixed-point` - Move the flag from a driver option to a cc1 option - Rename the `SameFBits` member in TargetInfo to `PaddingOnUnsignedFixedPoint` - Updated descriptions Differential Revision: https://reviews.llvm.org/D48727 llvm-svn: 335993
* [X86] Remove masking from the avx512 packed sqrt builtins. Use select ↵Craig Topper2018-06-291-2/+2
| | | | | | builtins instead. llvm-svn: 335945
* PR37979: integral promotions in C++ treat enum bit-fields like enums,Richard Smith2018-06-281-0/+13
| | | | | | | | | | | | | | | | | not like bit-fields. We used to get this right "by accident", because conversions for the selected built-in overloaded operator would convert the enum bit-field to its corresponding underlying type early. But after DR1687 that no longer happens. Technically this change should also apply to C, where bit-fields only have special promotion rules if the bit-field's declared type is _Bool, int, signed int, or unsigned int, but for GCC compatibility we only look at the bit-width and not the underlying type when performing bit-field integral promotions in C. llvm-svn: 335925
* [OPENMP] Fix incomplete type check for array reductionsJoel E. Denny2018-06-281-1/+1
| | | | | | | | | | | A reduction for an incomplete array type used to produce an assert fail during codegen. Now it produces a diagnostic. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D48735 llvm-svn: 335911
* Revert r335907: [OPENMP] Fix incomplete type check for array reductionsJoel E. Denny2018-06-281-1/+1
| | | | | | Sorry, forgot to add commit log attributes again. llvm-svn: 335910
* [OPENMP] Fix incomplete type check for array reductionsJoel E. Denny2018-06-281-1/+1
| | | | | | | A reduction for an incomplete array type used to produce an assert fail during codegen. Now it produces a diagnostic. llvm-svn: 335907
* [modules] Do not serialize / deserialize pending new/delete mismatchRichard Smith2018-06-281-10/+7
| | | | | | | | | | checks across module boundaries. This was causing us to load constructor definitions for all consumers of a module with a pending check. (In one case we saw ~7% of total frontend time spent loading constructors for this check.) llvm-svn: 335807
* DR1687: When overload resolution selects a built-in operator, implicitRichard Smith2018-06-274-23/+75
| | | | | | | | | | | conversions are only applied to operands of class type, and the second standard conversion sequence is not applied. When diagnosing an invalid builtin binary operator, talk about the original types rather than the converted types. If these differ by a user-defined conversion, tell the user what happened. llvm-svn: 335781
* DR1213: Ignore implicit conversions when determining if an operand of anRichard Smith2018-06-271-4/+14
| | | | | | | | array subscript expression is an array prvalue. Also apply DR1213 to vector prvalues for consistency. llvm-svn: 335779
* Diagnose missing 'template' keywords in more cases.Richard Smith2018-06-261-6/+27
| | | | | | | | | | | | | | | | | | | | We track when we see a name-shaped expression followed by a '<' token and parse the '<' as a comparison. Then: * if we see a token sequence that cannot possibly be an expression but can be a template argument (in particular, a type-id) that follows either a ',' or the '<', diagnose that the '<' was supposed to start a template argument list, and * if we see '>()', diagnose that the '<' was supposed to start a template argument list. This only changes the diagnostic for error cases, and in practice appears to catch the most common cases where a missing 'template' keyword leads to parse errors within a template. Differential Revision: https://reviews.llvm.org/D48571 llvm-svn: 335687
* [Sema] Fix infinite typo correction loop.Volodymyr Sapsai2018-06-261-4/+0
| | | | | | | | | | | | | | | | | | | | | | | NumTypos guard value ~0U doesn't prevent from creating new delayed typos. When you create new delayed typos during typo correction, value ~0U wraps around to 0. When NumTypos is 0 we can miss some typos and treat an expression as it can be typo-corrected. But if the expression is still invalid after correction, we can get stuck in infinite loop trying to correct it. Fix by not using value ~0U so that NumTypos correctly reflects the number of typos. rdar://problem/38642201 Reviewers: arphaman, majnemer, rsmith Reviewed By: rsmith Subscribers: rsmith, nicholas, cfe-commits Differential Revision: https://reviews.llvm.org/D47341 llvm-svn: 335638
* Fix an ambiguous overload issue pointed out by MSVCVedant Kumar2018-06-261-1/+2
| | | | | | | Log: http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/11390 llvm-svn: 335577
* [ubsan] Relax nullability-return for blocks with deduced typesVedant Kumar2018-06-261-1/+8
| | | | | | | | | | | | | | When the return type of an ObjC-style block literals is deduced, pick the candidate type with the strictest nullability annotation applicable to every other candidate. This suppresses a UBSan false-positive in situations where a too-strict nullability would be deduced, despite the fact that the returned value would be implicitly cast to _Nullable. rdar://41317163 llvm-svn: 335572
* Modernize a function, NFC.Vedant Kumar2018-06-261-5/+2
| | | | llvm-svn: 335571
* Revert "Append new attributes to the end of an AttributeList."Michael Kruse2018-06-251-13/+34
| | | | | | | This reverts commit r335084 as requested by David Jones and Eric Christopher because of differences of emitted warnings. llvm-svn: 335516
* [clang-cl] Don't emit dllexport inline functions etc. from pch files (PR37801)Hans Wennborg2018-06-251-0/+7
| | | | | | | | | | | | | | | | | | | | | | | With MSVC, PCH files are created along with an object file that needs to be linked into the final library or executable. That object file contains the code generated when building the headers. In particular, it will include definitions of inline dllexport functions, and because they are emitted in this object file, other files using the PCH do not need to emit them. See the bug for an example. This patch makes clang-cl match MSVC's behaviour in this regard, causing significant compile-time savings when building dlls using precompiled headers. For example, in a 64-bit optimized shared library build of Chromium with PCH, it reduces the binary size and compile time of stroke_opacity_custom.obj from 9315564 bytes to 3659629 bytes and 14.6 to 6.63 s. The wall-clock time of building blink_core.dll goes from 38m41s to 22m33s. ("user" time goes from 1979m to 1142m). Differential Revision: https://reviews.llvm.org/D48426 llvm-svn: 335466
OpenPOWER on IntegriCloud