summaryrefslogtreecommitdiffstats
path: root/clang/lib/AST
Commit message (Collapse)AuthorAgeFilesLines
* [ObjC] Allow declaring __weak pointer fields in C structs in ARC.Akira Hatanaka2018-03-104-10/+27
| | | | | | | | | | | | This patch uses the infrastructure added in r326307 for enabling non-trivial fields to be declared in C structs to allow __weak fields in C structs in ARC. rdar://problem/33599681 Differential Revision: https://reviews.llvm.org/D44095 llvm-svn: 327206
* PR36645: Go looking for an appropriate array bound when constant-evaluating aRichard Smith2018-03-091-4/+12
| | | | | | name of an array object. llvm-svn: 327099
* [analyzer] Correctly model iteration through "nil" objectsGeorge Karpenkov2018-03-081-0/+3
| | | | | | | | | | | | | | | | | | | | Previously, iteration through nil objects which resulted from objc-messages being set to nil were modeled incorrectly. There are a couple of notes about this patch: In principle, ExprEngineObjC might be left untouched IFF osx.loops checker is enabled. I however think that we should not do something completely incorrect depending on what checkers are left on. We should evaluate and potentially remove altogether the isConsumedExpr performance heuristic, as it seems very fragile. rdar://22205149 Differential Revision: https://reviews.llvm.org/D44178 llvm-svn: 326982
* [MS] Pass CVRU qualifiers properly in Itanium manglerReid Kleckner2018-03-081-1/+1
| | | | | | | | | We already have a mangling for the __unaligned qualifier, we just have to call Qualifiers::getFromCVRUMask instead of getFromCVRMask. PR36638 llvm-svn: 326971
* Reland r326766 (with a slightly modified test)George Burgess IV2018-03-071-1/+5
| | | | | | | | | The original revert was done in r326869, since reverting r326602 broke the test added by this. The new test should be less dependent on r326602. llvm-svn: 326872
* Revert 326766 too, after r326862 the test fails and I don't know how to fix.Nico Weber2018-03-071-5/+1
| | | | llvm-svn: 326869
* Revert r326602, it caused PR36620.Nico Weber2018-03-071-4/+6
| | | | llvm-svn: 326862
* [ExprConstant] Look through ExprWithCleanups for `allocsize`George Burgess IV2018-03-061-1/+5
| | | | llvm-svn: 326766
* [Attr] Fix parameter indexing for several attributesJoel E. Denny2018-03-021-6/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The patch fixes a number of bugs related to parameter indexing in attributes: * Parameter indices in some attributes (argument_with_type_tag, pointer_with_type_tag, nonnull, ownership_takes, ownership_holds, and ownership_returns) are specified in source as one-origin including any C++ implicit this parameter, were stored as zero-origin excluding any this parameter, and were erroneously printing (-ast-print) and confusingly dumping (-ast-dump) as the stored values. * For alloc_size, the C++ implicit this parameter was not subtracted correctly in Sema, leading to assert failures or to silent failures of __builtin_object_size to compute a value. * For argument_with_type_tag, pointer_with_type_tag, and ownership_returns, the C++ implicit this parameter was not added back to parameter indices in some diagnostics. This patch fixes the above bugs and aims to prevent similar bugs in the future by introducing careful mechanisms for handling parameter indices in attributes. ParamIdx stores a parameter index and is designed to hide the stored encoding while providing accessors that require each use (such as printing) to make explicit the encoding that is needed. Attribute declarations declare parameter index arguments as [Variadic]ParamIdxArgument, which are exposed as ParamIdx[*]. This patch rewrites all attribute arguments that are processed by checkFunctionOrMethodParameterIndex in SemaDeclAttr.cpp to be declared as [Variadic]ParamIdxArgument. The only exception is xray_log_args's argument, which is encoded as a count not an index. Differential Revision: https://reviews.llvm.org/D43248 llvm-svn: 326602
* [NFC] Move CommentOpts checks to the call sites that depend on it. ↵David L. Jones2018-03-022-13/+16
| | | | | | | | | | | | | | | | | | | | | | (Re-applying r326501.) When parsing comments, for example, for -Wdocumentation, slightly different behaviour occurs when -fparse-all-comments is specified. However, these differences are subtle: 1. All comments are saved during parsing, regardless of whether they are doc comments or not. 2. "Maybe-doc" comments, like <, !, etc, are saved as such, instead of marking them as ordinary comments. The maybe-doc type of comment is never saved otherwise. (Warning on these is the impetus of -Wdocumentation.) 3. All comments are treated as doc comments in ASTContext, even if they are ordinary. This change moves the logic for checking CommentOptions.ParseAllComments closer to where it has an effect. The overall logic is unchanged, but checks of the ParseAllComments flag are now done where the effect will be clearer. Subscribers: cfe-commits llvm-svn: 326512
* Revert r326501 due to buildbot breakage.David L. Jones2018-03-012-16/+13
| | | | | | | | | | | | | | | | | | | | Original change: [NFC] Move CommentOpts checks to the call sites that depend on it. When parsing comments, for example, for -Wdocumentation, slightly different behaviour occurs when -fparse-all-comments is specified. However, these differences are subtle: 1. All comments are saved during parsing, regardless of whether they are doc comments or not. 2. "Maybe-doc" comments, like //<, //!, etc, are saved as such, instead of marking them as ordinary comments. The maybe-doc type of comment is never saved otherwise. (Warning on these is the impetus of -Wdocumentation.) 3. All comments are treated as doc comments in ASTContext, even if they are ordinary. This change moves the logic for checking CommentOptions.ParseAllComments closer to where it has an effect. The overall logic is unchanged, but checks of the ParseAllComments flag are now done where the effect will be clearer. llvm-svn: 326508
* [NFC] Move CommentOpts checks to the call sites that depend on it.David L. Jones2018-03-012-13/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | When parsing comments, for example, for -Wdocumentation, slightly different behaviour occurs when -fparse-all-comments is specified. However, these differences are subtle: 1. All comments are saved during parsing, regardless of whether they are doc comments or not. 2. "Maybe-doc" comments, like //<, //!, etc, are saved as such, instead of marking them as ordinary comments. The maybe-doc type of comment is never saved otherwise. (Warning on these is the impetus of -Wdocumentation.) 3. All comments are treated as doc comments in ASTContext, even if they are ordinary. This change moves the logic for checking CommentOptions.ParseAllComments closer to where it has an effect. The overall logic is unchanged, but checks of the ParseAllComments flag are now done where the effect will be clearer. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D43663 llvm-svn: 326501
* [RecordLayout] Only assert that fundamental type sizes are power of two on MSVCMartin Storsjo2018-03-011-4/+26
| | | | | | | | | | Make types with sizes that aren't a power of two an error (that can be disabled) in structs with ms_struct layout, except on mingw where the situation is quite likely to occur and GCC handles it silently. Differential Revision: https://reviews.llvm.org/D43908 llvm-svn: 326476
* Remove redundant casts. NFCGeorge Burgess IV2018-03-0113-74/+73
| | | | | | | | | | | | | | | | | | | So I wrote a clang-tidy check to lint out redundant `isa`, `cast`, and `dyn_cast`s for fun. This is a portion of what it found for clang; I plan to do similar cleanups in LLVM and other subprojects when I find time. Because of the volume of changes, I explicitly avoided making any change that wasn't highly local and obviously correct to me (e.g. we still have a number of foo(cast<Bar>(baz)) that I didn't touch, since overloading is a thing and the cast<Bar> did actually change the type -- just up the class hierarchy). I also tried to leave the types we were cast<>ing to somewhere nearby, in cases where it wasn't locally obvious what we were dealing with before. llvm-svn: 326416
* [ObjC] Allow declaring __strong pointer fields in structs in Objective-CAkira Hatanaka2018-02-283-13/+60
| | | | | | | | | | | | | | | | | | | | | ARC mode. Declaring __strong pointer fields in structs was not allowed in Objective-C ARC until now because that would make the struct non-trivial to default-initialize, copy/move, and destroy, which is not something C was designed to do. This patch lifts that restriction. Special functions for non-trivial C structs are synthesized that are needed to default-initialize, copy/move, and destroy the structs and manage the ownership of the objects the __strong pointer fields point to. Non-trivial structs passed to functions are destructed in the callee function. rdar://problem/33599681 Differential Revision: https://reviews.llvm.org/D41228 llvm-svn: 326307
* Fix a couple of cases where we would fail to correctly parse deduced class ↵Richard Smith2018-02-281-0/+5
| | | | | | | | | | | | | | | | template specialization types. Specifically, we would not properly parse these types within template arguments (for non-type template parameters), and in tentative parses. Fixing both of these essentially requires that we parse deduced template specialization types as types in all contexts, even in template argument lists -- in particular, tentative parsing may look ahead and annotate a deduced template specialization type before we figure out that we're actually supposed to treat the tokens as a template-name. We deal with this by simply permitting deduced template specialization types when parsing template arguments, and converting them to template template arguments. llvm-svn: 326299
* [RecordLayout] Don't align to non-power-of-2 sizes when using -mms-bitfieldsMartin Storsjo2018-02-271-1/+6
| | | | | | | | | | | | | | | | | | | | When targeting GNU/MinGW for i386, the size of the "long double" data type is 12 bytes (while it is 8 bytes in MSVC). When building with -mms-bitfields to have struct layouts match MSVC, data types are laid out in a struct with alignment according to their size. However, this doesn't make sense for the long double type, since it doesn't match MSVC at all, and aligning to a non-power-of-2 size triggers other asserts later. This matches what GCC does, aligning a long double to 4 bytes in structs on i386 even when -mms-bitfields is specified. This fixes asserts when using the max_align_t data type when building for MinGW/i386 with the -mms-bitfields flag. Differential Revision: https://reviews.llvm.org/D43734 llvm-svn: 326173
* [ExprConstant] Fix crash when initialize an indirect field with another field.Volodymyr Sapsai2018-02-231-4/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | When indirect field is initialized with another field, you have MemberExpr with CXXThisExpr that corresponds to the field's immediate anonymous parent. But 'this' was referring to the non-anonymous parent. So when we were building LValue Designator, it was incorrect as it had wrong starting point. Usage of such designator would cause unexpected APValue changes and crashes. The fix is in adjusting 'this' for indirect fields from non-anonymous parent to the field's immediate parent. Discovered by OSS-Fuzz: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4985 rdar://problem/36359187 Reviewers: rsmith, efriedma Reviewed By: rsmith Subscribers: cfe-commits, jkorous-apple Differential Revision: https://reviews.llvm.org/D42498 llvm-svn: 325997
* [ODRHash] Fix hashing for friend functions.Richard Trieu2018-02-222-3/+6
| | | | | | | When hashing a templated function, use the hash of the function it was instantiated from. llvm-svn: 325742
* [ODRHash] Handle some template weirdness.Richard Trieu2018-02-222-19/+43
| | | | | | | | Build the index off of DeclarationName instead of Decl pointers. When finding an UnresolvedLookupExprClass, hash it as if it were a DeclRefExpr. This will allow methods to be hashed. llvm-svn: 325741
* In C++14 onwards, it is permitted to read mutable members in constantRichard Smith2018-02-211-10/+22
| | | | | | | | | expressions, if their lifetime began during the evaluation of the expression. This is technically not allowed in C++11, though we could consider permitting it there too, as an extension. llvm-svn: 325663
* Clean up use of C allocation functionsSerge Pavlov2018-02-211-1/+1
| | | | | | | | | | | | | | | | If the value returned by `malloc`, `calloc` or `realloc` is not checked for null pointer, this change replaces them for `safe_malloc`, `safe_calloc` or `safe_realloc`, which are defined in the namespace `llvm`. These function report fatal error on out of memory. In the plain C files, assertion statements are added to ensure that memory is successfully allocated. The aim of this change is to get better diagnostics of OOM on Windows. Differential Revision: https://reviews.llvm.org/D43017 llvm-svn: 325661
* Revert r325375 "[MS] Make constexpr static data members implicitly inline"Hans Wennborg2018-02-201-1/+1
| | | | | | | | | | | | | | | | This broke Clang bootstrap on Windows, PR36453. > This handles them exactly the same way that we handle const integral > static data members with inline definitions, which is what MSVC does. > > As a follow-up, now that we have a way to mark variables inline in the > AST, we should consider marking them implicitly inline there instead of > only treating them as inline in CodeGen. Unfortunately, this breaks a > lot of dllimport test cases, so that is future work for now. > > Fixes PR36125. llvm-svn: 325576
* [MS] Make constexpr static data members implicitly inlineReid Kleckner2018-02-161-1/+1
| | | | | | | | | | | | | | This handles them exactly the same way that we handle const integral static data members with inline definitions, which is what MSVC does. As a follow-up, now that we have a way to mark variables inline in the AST, we should consider marking them implicitly inline there instead of only treating them as inline in CodeGen. Unfortunately, this breaks a lot of dllimport test cases, so that is future work for now. Fixes PR36125. llvm-svn: 325375
* [OpenMP] Fix trailing space when printing pragmas, by Joel. E. DennyAlexey Bataev2018-02-141-42/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: -ast-print prints omp pragmas with a trailing space. While this behavior is likely of little concern to most users, surely it's unintentional, and it's annoying for some source-level work I'm pursuing. This patch focuses on omp pragmas, but it also fixes init_seg and loop hint pragmas because they share implementation. The testing strategy here is to add usually just one '{{$}}' per relevant -ast-print test file. This seems to achieve good code coverage. However, this strategy is probably easy to forget as the tests evolve. That's probably fine as this fix is far from critical. The main goal of the testing is to aid the initial review. This patch also adds a fixme for "#pragma unroll", which prints as "#pragma unroll (enable)", which is invalid syntax. Reviewers: ABataev Reviewed By: ABataev Subscribers: guansong, cfe-commits Differential Revision: https://reviews.llvm.org/D43204 llvm-svn: 325145
* [AST] Refine the condition for element-dependent array fillersIvan A. Kosarev2018-02-141-2/+23
| | | | | | | | | | | | This patch fixes clang to not consider braced initializers for aggregate elements of arrays to be potentially dependent on the indices of the initialized elements. Resolves bug 18978: initialize a large static array = clang oom? https://bugs.llvm.org/show_bug.cgi?id=18978 Differential Revision: https://reviews.llvm.org/D43187 llvm-svn: 325120
* Quick fix for 325116 buildbots: move template specialization into namespaceAleksei Sidorin2018-02-141-27/+29
| | | | llvm-svn: 325118
* [ASTImporter] Fix lexical DC for templated decls; support ↵Aleksei Sidorin2018-02-141-50/+109
| | | | | | | | | | VarTemplatePartialSpecDecl Also minor refactoring in related functions was done. Differential Revision: https://reviews.llvm.org/D43012 llvm-svn: 325116
* Fix a couple of places where we assumed that non-type template parameters ↵Richard Smith2018-02-141-1/+2
| | | | | | are always rvalues. llvm-svn: 325095
* Teach Wreturn-type, Wunreachable-code, and alpha.deadcode.UnreachableCode to ↵Nico Weber2018-02-131-0/+12
| | | | | | | | | treat __assume(0) like __builtin_unreachable. Fixes PR29134. https://reviews.llvm.org/D43221 llvm-svn: 325052
* Update StmtProfile.cpp to handle zero template arguments.Richard Trieu2018-02-131-2/+5
| | | | | | | Treat having no templates arguments differently than having zero template arguments when profiling. llvm-svn: 325040
* [Sema] Don't mark plain MS enums as fixedReid Kleckner2018-02-121-6/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This fixes a flaw in our AST: PR27098 MSVC always gives plain enums the underlying type 'int'. Clang does this as well, but we claim the enum is "fixed", as if the user actually wrote ': int'. It means we end up emitting spurious -Wsign-compare warnings on code like this: enum Vals { E1, E2, E3 }; bool f(unsigned v1, Vals v2) { return v1 == v2; } We think 'v2' can take on negative values because we think 'Vals' is fixed. This fixes that. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D43110 llvm-svn: 324913
* AST: support ObjC lifetime qualifiers in MS ABISaleem Abdulrasool2018-02-091-5/+60
| | | | | | | | | | | | | | | Adjust the ObjC protocol conformance workaround to be more extensible. Use a synthetic type for the protocol (`struct Protocol`). Embed this within a reserved namespace to permit extending the extended pointer type qualifiers similarly for ObjC lifetime qualifiers. Introduce additional special handling for `__autoreleasing`, `__strong`, and `__weak` Objective C lifetime qualifiers. We decorate these by creating an artificial template type `Autoreleasing`, `Strong`, or `Weak` in the `__ObjC` namespace. These are only considered in the template type specialization and not the function parameter. llvm-svn: 324701
* AST: support SwiftCC on MS ABISaleem Abdulrasool2018-02-071-3/+3
| | | | | | | | Microsoft has reserved the identifier 'S' as the swift calling convention. Decorate the symbols appropriately. This enables swift on Windows. llvm-svn: 324439
* Add support for attribute 'trivial_abi'.Akira Hatanaka2018-02-053-5/+73
| | | | | | | | | | | | | | | | | | | | | | | | | The 'trivial_abi' attribute can be applied to a C++ class, struct, or union. It makes special functions of the annotated class (the destructor and copy/move constructors) to be trivial for the purpose of calls and, as a result, enables the annotated class or containing classes to be passed or returned using the C ABI for the underlying type. When a type that is considered trivial for the purpose of calls despite having a non-trivial destructor (which happens only when the class type or one of its subobjects is a 'trivial_abi' class) is passed to a function, the callee is responsible for destroying the object. For more background, see the discussions that took place on the mailing list: http://lists.llvm.org/pipermail/cfe-dev/2017-November/055955.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180101/thread.html#214043 rdar://problem/35204524 Differential Revision: https://reviews.llvm.org/D41039 llvm-svn: 324269
* Make __has_unique_object_representations reject empty union types.Eric Fiselier2018-02-021-1/+1
| | | | | | | | | | | | | | | | | Summary: Clang incorrectly reports empty unions as having a unique object representation. However, this is not correct since `sizeof(EmptyUnion) == 1` AKA it has 8 bits of padding. Therefore it should be treated the same as an empty struct and report `false`. @erichkeane also suggested this fix should be merged into the 6.0 release branch, so the initial release of `__has_unique_object_representations` is as bug-free as possible. Reviewers: erichkeane, rsmith, aaron.ballman, majnemer Reviewed By: erichkeane Subscribers: cfe-commits, erichkeane Differential Revision: https://reviews.llvm.org/D42863 llvm-svn: 324134
* [AST] namespace ns { extern "C" { int X; }} prints as "ns::X", not as "X"Sam McCall2018-02-021-3/+4
| | | | llvm-svn: 324081
* PR36181: Teach CodeGen to properly ignore requests to emit dependent entities.Richard Smith2018-02-011-0/+13
| | | | | | | Previously, friend function definitions within class templates slipped through the gaps and caused the MS mangler to assert. llvm-svn: 323935
* [PR32482] Fix bitfield layout for -mms-bitfield and pragma packAlex Lorenz2018-01-311-3/+4
| | | | | | | | | | | The patch ensures that a new storage unit is created when the new bitfield's size is wider than the available bits. rdar://36343145 Differential Revision: https://reviews.llvm.org/D42660 llvm-svn: 323921
* [ASTImporter] Add support to import some AST nodes:Gabor Horvath2018-01-271-23/+108
| | | | | | | | | | | | | | | | * CXXOperatorCallExpr * SizeOfPackExpr * DependentTemplateSpecializationType * DependentSizedArray * CXXTypeidExpr * Fix importing CXXTemporaryObjectExpr Some of the changes are based on https://github.com/haoNoQ/clang/blob/summary-ipa-draft/lib/AST/ASTImporter.cpp Differential Revision: https://reviews.llvm.org/D42335 llvm-svn: 323589
* AST: support protocol conformances on id/class/interfaces in MS ABISaleem Abdulrasool2018-01-261-3/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | Add support for mangling ObjC protocol conformances in MS ABI as if they are COM interfaces. By diverging from the itanium mangling of `objc_protocol` prefixed names, this approach allows for a semi-reasonable, albeit of questionable sanity, undecoration via existing tooling. There is also the possibility of adding an extension and taking part of the namespace to add the conformance via the `L` and `Z` "modifiers", but the existing tooling would not be able to properly undecorated the symbol even though incidentally `undname` currently produces something legible while wine's implementation is not able to cope with the extension. This allows for the disambiguation of overloads where the parameter differs only in the protocol conformance of the ObjC type, e.g. ``` @protocol P; void f(std::vector<id>); void f(std::vector<id<P>>); ``` which clang would previously fail due to the mangling being identical as the protocol conformance was ignored. llvm-svn: 323547
* [AST] Use bit packing to reduce sizeof(TypedefNameDecl) from 88 to 80.Benjamin Kramer2018-01-261-3/+1
| | | | | | | | We can stash the cached transparent tag bit in existing pointer padding. Everything coming out of ASTContext is always aligned to a multiple of 8, so we have 8 spare bits. llvm-svn: 323528
* [ASTImporter] avoid warnings: unused var, switch coveredSam McCall2018-01-262-8/+6
| | | | llvm-svn: 323524
* [ASTImporter] Support LambdaExprs and improve template supportAleksei Sidorin2018-01-263-61/+334
| | | | | | | | | | | | | | Also, a number of style and bug fixes was done: * ASTImporterTest: added sanity check for source node * ExternalASTMerger: better lookup for template specializations * ASTImporter: don't add templated declarations into DeclContext * ASTImporter: introduce a helper, ImportTemplateArgumentListInfo getting SourceLocations * ASTImporter: proper set ParmVarDecls for imported FunctionProtoTypeLoc Differential Revision: https://reviews.llvm.org/D42301 llvm-svn: 323519
* AST: inline a single-use variable (NFC)Saleem Abdulrasool2018-01-251-2/+1
| | | | | | Inline the single use variable into the only use. NFC. llvm-svn: 323461
* AST: correct mangling for SEL on MS ABISaleem Abdulrasool2018-01-231-1/+0
| | | | | | | | We would previously treat `SEL` as a pointer-only type. This is not the case. It should be treated similarly to `id` and `Class`. Add some test cases to ensure that it will be properly handled as well. llvm-svn: 323257
* AST: adjust ObjC MS mangling to work with typedefsSaleem Abdulrasool2018-01-231-5/+0
| | | | | | | | | Rather than hardcode the pointerness of the `id` and `class` types, handle them generically. This allows for the template type specialization of `remove_pointer<id>` which would look through the `id` type and deal with the `objc_object` structure without the pointer. llvm-svn: 323241
* [CUDA] CUDA has no device-side library builtins.Artem Belevich2018-01-231-0/+7
| | | | | | | | | | We should (almost) never consider a device-side declaration to match a library builtin functio. Otherwise clang may ignore the implementation provided by the CUDA headers and emit clang's idea of the builtin. Differential Revision: https://reviews.llvm.org/D42319 llvm-svn: 323239
* Allow BlockDecl in CXXRecord scope to have no access specifier.Richard Trieu2018-01-191-0/+2
| | | | | | | | | Using a BlockDecl in a default member initializer causes it to be attached to CXXMethodDecl without its access specifier being set. This prevents a crash where getAccess is called on this BlockDecl, since that method expects any Decl in CXXRecord scope to have an access specifier. llvm-svn: 322984
* [DeclPrinter] Fix two cases that crash clang -ast-print.Artem Belevich2018-01-171-4/+5
| | | | | | | | | | | | | Both are related to handling anonymous structures. * clang didn't handle () around an anonymous struct variable. * clang also crashed on syntax errors that could lead to other syntactic constructs following the declaration of an anonymous struct. While the code is invalid, that's not a good reason to panic compiler. Differential Revision: https://reviews.llvm.org/D41788 llvm-svn: 322742
OpenPOWER on IntegriCloud