summaryrefslogtreecommitdiffstats
path: root/clang/lib/Serialization/ASTWriter.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Modules: Rename MemoryBufferCache to InMemoryModuleCacheDuncan P. N. Exon Smith2019-03-091-6/+7
| | | | | | | | | | | | | Change MemoryBufferCache to InMemoryModuleCache, moving it from Basic to Serialization. Another patch will start using it to manage module build more explicitly, but this is split out because it's mostly mechanical. Because of the move to Serialization we can no longer abuse the Preprocessor to forward it to the ASTReader. Besides the rename and file move, that means Preprocessor::Preprocessor has one fewer parameter and ASTReader::ASTReader has one more. llvm-svn: 355777
* [OPENMP 5.0]Add initial support for 'allocate' directive.Alexey Bataev2019-03-071-0/+14
| | | | | | | Added parsing/sema analysis/serialization/deserialization support for 'allocate' directive. llvm-svn: 355614
* [OpenMP 5.0] Parsing/sema support for from clause with mapper modifier.Michael Kruse2019-02-251-0/+4
| | | | | | | | | | | | | | | | | | | | This patch implements the parsing and sema support for the OpenMP 'from'-clause with potential user-defined mappers attached. User-defined mappers are a new feature in OpenMP 5.0. A 'from'-clause can have an explicit or implicit associated mapper, which instructs the compiler to generate and use customized mapping functions. An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len]) struct S ss; #pragma omp target update from(mapper(id): ss) // use the mapper with name 'id' to map ss from device Contributed-by: Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D58638 llvm-svn: 354817
* [OpenMP 5.0] Parsing/sema support for to clause with mapper modifier.Michael Kruse2019-02-221-0/+4
| | | | | | | | | | | | | | | | | | | This patch implements the parsing and sema support for OpenMP to clause with potential user-defined mappers attached. User defined mapper is a new feature in OpenMP 5.0. A to/from clause can have an explicit or implicit associated mapper, which instructs the compiler to generate and use customized mapping functions. An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len]) struct S ss; #pragma omp target update to(mapper(id): ss) // use the mapper with name 'id' to map ss to device Contributed-by: <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D58523 llvm-svn: 354698
* [OpenMP 5.0] Parsing/sema support for map clause with mapper modifier.Michael Kruse2019-02-191-0/+4
| | | | | | | | | | | | | | | | | | | This patch implements the parsing and sema support for OpenMP map clauses with potential user-defined mapper attached. User defined mapper is a new feature in OpenMP 5.0. A map clause can have an explicit or implicit associated mapper, which instructs the compiler to generate extra data mapping. An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len]) struct S ss; #pragma omp target map(mapper(id) tofrom: ss) // use the mapper with name 'id' to map ss Contributed-by: Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D58074 llvm-svn: 354347
* Rename getTypeQualifiers to getMethodQualifiers.Anastasia Stulova2019-01-281-2/+2
| | | | | | | | Use more descriptive name for the method qualifiers getter. Differential Revision: https://reviews.llvm.org/D56792 llvm-svn: 352349
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [OPENMP] parsing and sema support for 'close' map-type-modifierKelvin Li2018-12-181-1/+4
| | | | | | | | | | | | A map clause with the close map-type-modifier is a hint to prefer that the variables are mapped using a copy into faster memory. Patch by Ahsan Saghir (saghir) Differential Revision: https://reviews.llvm.org/D55719 llvm-svn: 349551
* [OpenCL] Add generic AS to 'this' pointerMikael Nilsson2018-12-131-1/+1
| | | | | | | | | | | | | Address spaces are cast into generic before invoking the constructor. Added support for a trailing Qualifiers object in FunctionProtoType. Note: This recommits the previously reverted patch, but now it is commited together with a fix for lldb. Differential Revision: https://reviews.llvm.org/D54862 llvm-svn: 349019
* Revert "[OpenCL] Add generic AS to 'this' pointer"Mikael Nilsson2018-12-121-1/+1
| | | | | | Reverting because the patch broke lldb. llvm-svn: 348931
* [OpenCL] Add generic AS to 'this' pointerMikael Nilsson2018-12-121-1/+1
| | | | | | | | | | Address spaces are cast into generic before invoking the constructor. Added support for a trailing Qualifiers object in FunctionProtoType. Differential Revision: https://reviews.llvm.org/D54862 llvm-svn: 348927
* PTH-- Remove feature entirely-Erich Keane2018-12-041-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When debugging a boost build with a modified version of Clang, I discovered that the PTH implementation stores TokenKind in 8 bits. However, we currently have 368 TokenKinds. The result is that the value gets truncated and the wrong token gets picked up when including PTH files. It seems that this will go wrong every time someone uses a token that uses the 9th bit. Upon asking on IRC, it was brought up that this was a highly experimental features that was considered a failure. I discovered via googling that BoostBuild (mostly Boost.Math) is the only user of this feature, using the CC1 flag directly. I believe that this can be transferred over to normal PCH with minimal effort: https://github.com/boostorg/build/issues/367 Based on advice on IRC and research showing that this is a nearly completely unused feature, this patch removes it entirely. Note: I considered leaving the build-flags in place and making them emit an error/warning, however since I've basically identified and warned the only user, it seemed better to just remove them. Differential Revision: https://reviews.llvm.org/D54547 Change-Id: If32744275ef1f585357bd6c1c813d96973c4d8d9 llvm-svn: 348266
* Add support for 'atomic_default_mem_order' clause on 'requires' directive. ↵Patrick Lyster2018-11-021-0/+7
| | | | | | Also renamed test files relating to 'requires'. Differntial review: https://reviews.llvm.org/D53513 llvm-svn: 345967
* [OpenCL] Fix serialization of OpenCLExtensionDeclsAndrew Savonichev2018-10-291-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: I recently discovered that adding the following code into `opencl-c.h` causes failure of `test/Headers/opencl-c-header.cl`: ``` #pragma OPENCL EXTENSION cl_my_ext : begin void cl_my_ext_foobarbaz(); #pragma OPENCL EXTENSIOn cl_my_ext : end ``` Clang crashes at the assertion is `ASTReader::getGlobalSubmoduleID()`: ``` assert(I != M.SubmoduleRemap.end() && "Invalid index into submodule index remap"); ``` The root cause of the problem that to deserialize `OPENCL_EXTENSION_DECLS` section `ASTReader` needs to deserialize a Decl contained in it. In turn, deserializing a Decl requires information about whether this declaration is part of a (sub)module, but this information is not read yet because it is located further in a module file. Reviewers: Anastasia, yaxunl, JDevlieghere Reviewed By: Anastasia Subscribers: sidorovd, cfe-commits, asavonic Differential Revision: https://reviews.llvm.org/D53200 llvm-svn: 345497
* Add support for 'dynamic_allocators' clause on 'requires' directive. ↵Patrick Lyster2018-10-111-0/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D53079 llvm-svn: 344249
* [OPENMP] Add reverse_offload clause to requires directivePatrick Lyster2018-10-031-0/+2
| | | | llvm-svn: 343711
* Add support for unified_shared_memory clause on requires directivePatrick Lyster2018-10-011-0/+3
| | | | llvm-svn: 343472
* llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)Fangrui Song2018-09-261-9/+7
| | | | | | | | | | | | | | Summary: The convenience wrapper in STLExtras is available since rL342102. Reviewers: rsmith, #clang, dblaikie Reviewed By: rsmith, #clang Subscribers: mgrang, arphaman, kadircet, cfe-commits Differential Revision: https://reviews.llvm.org/D52576 llvm-svn: 343147
* [OPENMP] Add support for OMP5 requires directive + unified_address clauseKelvin Li2018-09-261-0/+2
| | | | | | | | | Add support for OMP5.0 requires directive and unified_address clause. Patches to follow will include support for additional clauses. Differential Revision: https://reviews.llvm.org/D52359 llvm-svn: 343063
* [AST] Various optimizations + refactoring in DeclarationName(Table)Bruno Ricci2018-09-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce the following optimizations in DeclarationName(Table): 1. Store common kinds inline in DeclarationName instead of DeclarationNameExtra. Currently the kind of C++ constructor, destructor, conversion function and overloaded operator names is stored in DeclarationNameExtra. Instead store it inline in DeclarationName. To do this align IdentifierInfo, CXXSpecialName, DeclarationNameExtra and CXXOperatorIdName to 8 bytes so that we can use the lower 3 bits of DeclarationName::Ptr. This is already the case on 64 bits archs anyway. This also allow us to remove DeclarationNameExtra from CXXSpecialName and CXXOperatorIdName, which shave off a pointer from CXXSpecialName. 2. Synchronize the enumerations DeclarationName::NameKind, DeclarationName::StoredNameKind and Selector::IdentifierInfoFlag. This makes DeclarationName::getNameKind much more efficient since we can replace the switch table by a single comparison and an addition. 3. Put the overloaded operator names inline in DeclarationNameTable to remove an indirection. This increase the size of DeclarationNameTable a little bit but this is not important since it is only used in ASTContext, and never copied nor moved from. This also get rid of the last dynamic allocation in DeclarationNameTable. Altogether these optimizations cut the run time of parsing all of Boost by about 0.8%. While we are at it, do the following NFC modifications: 1. Put the internal classes CXXSpecialName, CXXDeductionGuideNameExtra, CXXOperatorIdName, CXXLiteralOperatorIdName and DeclarationNameExtra in a namespace detail since these classes are only meant to be used by DeclarationName and DeclarationNameTable. Make this more explicit by making the members of these classes private and friending DeclarationName(Table). 2. Make DeclarationName::getFETokenInfo a non-template since every users are using it to get a void *. It was supposed to be used with a type to avoid a subsequent static_cast. 3. Change the internal functions DeclarationName::getAs* to castAs* since when we use them we already know the correct kind. This has no external impact since all of these are private. Reviewed By: erichkeane, rjmccall Differential Revision: https://reviews.llvm.org/D52267 llvm-svn: 342729
* [OPENMP] Fix spelling of getLoopCounter (NFC)Mike Rice2018-09-201-1/+1
| | | | llvm-svn: 342666
* [OPENMP] Move OMPClauseReader/Writer classes to ASTReader/Writer (NFC)Kelvin Li2018-09-151-0/+465
| | | | | | | | | | | | | | Move declarations for OMPClauseReader, OMPClauseWriter to ASTReader.h and ASTWriter.h and move implementation to ASTReader.cpp and ASTWriter.cpp. This change helps generalize the serialization of OpenMP clauses and will be used in the future implementation of new OpenMP directives (e.g. requires). Patch by Patrick Lyster Differential Revision: https://reviews.llvm.org/D52097 llvm-svn: 342322
* Model type attributes as regular Attrs.Richard Smith2018-08-201-20/+13
| | | | | | | | | | | | | | Specifically, AttributedType now tracks a regular attr::Kind rather than having its own parallel Kind enumeration, and AttributedTypeLoc now holds an Attr* instead of holding an ad-hoc collection of Attr fields. Differential Revision: https://reviews.llvm.org/D50526 This reinstates r339623, reverted in r339638, with a fix to not fail template instantiation if we instantiate a QualType with no associated type source information and we encounter an AttributedType. llvm-svn: 340215
* [OPENMP] FIx processing of declare target variables.Alexey Bataev2018-08-151-0/+1
| | | | | | | | The compiler may produce unexpected error messages/crashes when declare target variables were used. Patch fixes problems with the declarations marked as declare target to or link. llvm-svn: 339805
* Revert r339623 "Model type attributes as regular Attrs."Reid Kleckner2018-08-141-13/+20
| | | | | | | | This breaks compiling atlwin.h in Chromium. I'm sure the code is invalid in some way, but we put a lot of work into accepting it, and I'm sure rejecting it was not an intended consequence of this refactoring. :) llvm-svn: 339638
* Model type attributes as regular Attrs.Richard Smith2018-08-131-20/+13
| | | | | | | | | | Specifically, AttributedType now tracks a regular attr::Kind rather than having its own parallel Kind enumeration, and AttributedTypeLoc now holds an Attr* instead of holding an ad-hoc collection of Attr fields. Differential Revision: https://reviews.llvm.org/D50526 llvm-svn: 339623
* Port getLocStart -> getBeginLocStephen Kelly2018-08-091-1/+1
| | | | | | | | | | Reviewers: teemperor! Subscribers: jholewinski, whisperity, jfb, cfe-commits Differential Revision: https://reviews.llvm.org/D50350 llvm-svn: 339385
* [AST][1/4] Move the bit-fields from TagDecl, EnumDecl and RecordDecl into ↵Erich Keane2018-08-011-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DeclContext DeclContext has a little less than 8 bytes free due to the alignment requirements on 64 bits archs. This set of patches moves the bit-fields from classes deriving from DeclContext into DeclContext. On 32 bits archs this increases the size of DeclContext by 4 bytes but this is balanced by an equal or larger reduction in the size of the classes deriving from it. On 64 bits archs the size of DeclContext stays the same but most of the classes deriving from it shrink by 8/16 bytes. (-print-stats diff here https://reviews.llvm.org/D49728) When doing an -fsyntax-only on all of Boost this result in a 3.6% reduction in the size of all Decls and a 1% reduction in the run time due to the lower cache miss rate. For now CXXRecordDecl is not touched but there is an easy 6 (if I count correctly) bytes gain available there by moving some bits from DefinitionData into the free space of DeclContext. This will be the subject of another patch. This patch sequence also enable the possibility of refactoring FunctionDecl: To save space some bits from classes deriving from FunctionDecl were moved to FunctionDecl. This resulted in a lot of stuff in FunctionDecl which do not belong logically to it. After this set of patches however it is just a simple matter of adding a SomethingDeclBitfields in DeclContext and moving the bits to it from FunctionDecl. This first patch introduces the anonymous union in DeclContext and all the *DeclBitfields classes holding the bit-fields, and moves the bits from TagDecl, EnumDecl and RecordDecl into DeclContext. This patch is followed by https://reviews.llvm.org/D49732, https://reviews.llvm.org/D49733 and https://reviews.llvm.org/D49734. Differential Revision: https://reviews.llvm.org/D49729 Patch By: bricci llvm-svn: 338630
* PR15730/PR16986 Allow dependently typed vector_size types.Erich Keane2018-07-131-0/+13
| | | | | | | | | | | | | | | | | As listed in the above PRs, vector_size doesn't allow dependent types/values. This patch introduces a new DependentVectorType to handle a VectorType that has a dependent size or type. In the future, ALL the vector-types should be able to create one of these to handle dependent types/sizes as well. For example, DependentSizedExtVectorType could likely be switched to just use this instead, though that is left as an exercise for the future. Differential Revision: https://reviews.llvm.org/D49045 llvm-svn: 337036
* Revert -r336726, which included more files than intended.Erich Keane2018-07-101-12/+0
| | | | llvm-svn: 336727
* [NFC] Switch CodeGenFunction to use value init instead of member init listsErich Keane2018-07-101-0/+12
| | | | | | | | 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
* [PCH] Add an option to not write comments into PCHIlya Biryukov2018-07-091-1/+4
| | | | | | | | | | | | | | | | | | Summary: Will be used in clangd, see the follow-up change. Clangd does not use comments read from PCH to avoid crashes due to changed contents of the file. However, reading them considerably slows down code completion on files with large preambles. Reviewers: sammccall Reviewed By: sammccall Subscribers: ioeric, cfe-commits Differential Revision: https://reviews.llvm.org/D48942 llvm-svn: 336539
* [modules] Emit the type of the TypeSourceInfo for a DeclaratorDecl (butRichard Smith2018-06-291-2/+2
| | | | | | | | | | | not the corresponding location information) earlier. We need the type as written in order to properly merge functions with deduced return types, so we need to load that early. But we don't want to load the location information early, because that contains problematic things such as the function parameters. llvm-svn: 336016
* [modules] Do not serialize / deserialize pending new/delete mismatchRichard Smith2018-06-281-7/+9
| | | | | | | | | | 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
* [clang-cl] Don't emit dllexport inline functions etc. from pch files (PR37801)Hans Wennborg2018-06-251-4/+11
| | | | | | | | | | | | | | | | | | | | | | | 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
* Move VersionTuple from clang/Basic to llvm/SupportPavel Labath2018-06-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Summary: This kind of functionality is useful to other project apart from clang. LLDB works with version numbers a lot, but it does not have a convenient abstraction for this. Moving this class to a lower level library allows it to be freely used within LLDB. Since this class is used in a lot of places in clang, and it used to be in the clang namespace, it seemed appropriate to add it to the list of adopted classes in LLVM.h to avoid prefixing all uses with "llvm::". Also, I didn't find any tests specific for this class, so I wrote a couple of quick ones for the more interesting bits of functionality. Reviewers: zturner, erik.pilkington Subscribers: mgorny, cfe-commits, llvm-commits Differential Revision: https://reviews.llvm.org/D47887 llvm-svn: 334399
* Support: Simplify endian stream interface. NFCI.Peter Collingbourne2018-05-181-17/+16
| | | | | | | | | | | | Provide some free functions to reduce verbosity of endian-writing a single value, and replace the endianness template parameter with a field. Part of PR37466. Differential Revision: https://reviews.llvm.org/D47032 llvm-svn: 332757
* [AST] Print correct tag decl for tag specifierJoel E. Denny2018-05-141-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For example, given: void fn() { struct T *p0; struct T { int i; } *p1; } -ast-print produced: void fn() { struct T { int i; } *p0; struct T { int i; } *p1; } Compiling that fails with a redefinition error. Given: void fn() { struct T *p0; struct __attribute__((deprecated)) T *p1; } -ast-print dropped the attribute. Details: For a tag specifier (that is, struct/union/class/enum used as a type specifier in a declaration) that was also a tag declaration (that is, first occurrence of the tag) or tag redeclaration (that is, later occurrence that specifies attributes or a member list), clang printed the tag specifier as either (1) the full tag definition if one existed, or (2) the first tag declaration otherwise. Redefinition errors were sometimes introduced, as in the first example above. Even when that was impossible because no member list was ever specified, attributes were sometimes lost, thus changing semantics and diagnostics, as in the second example above. This patch fixes a major culprit for these problems. It does so by creating an ElaboratedType with a new OwnedDecl member wherever an occurrence of a tag type is a (re)declaration of that tag type. PrintingPolicy's IncludeTagDefinition used to trigger printing of the member list, attributes, etc. for a tag specifier by using a tag (re)declaration selected as described above. Now, it triggers the same thing except it uses the tag (re)declaration stored in the OwnedDecl. Of course, other tooling can now make use of the new OwnedDecl as well. Also, to be more faithful to the original source, this patch suppresses printing of attributes inherited from previous declarations. Reviewed by: rsmith, aaron.ballman Differential Revision: https://reviews.llvm.org/D45463 llvm-svn: 332281
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-091-33/+33
| | | | | | | | | | | | | | | | | | | This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
* Track the result of evaluating a computed noexcept specification on theRichard Smith2018-05-031-1/+1
| | | | | | | | | | | | | | FunctionProtoType. We previously re-evaluated the expression each time we wanted to know whether the type is noexcept or not. We now evaluate the expression exactly once. This is not quite "no functional change": it fixes a crasher bug during AST deserialization where we would try to evaluate the noexcept specification in a situation where we have not deserialized sufficient portions of the AST to permit such evaluation. llvm-svn: 331428
* PR37189 Fix incorrect end source location and spelling for a split '>>' token.Richard Smith2018-04-301-0/+2
| | | | | | | | | | | | | | | | | | When a '>>' token is split into two '>' tokens (in C++11 onwards), or (as an extension) when we do the same for other tokens starting with a '>', we can't just use a location pointing to the first '>' as the location of the split token, because that would result in our miscomputing the length and spelling for the token. As a consequence, for example, a refactoring replacing 'A<X>' with something else would sometimes replace one character too many, and similarly diagnostics highlighting a template-id source range would highlight one character too many. Fix this by creating an expansion range covering the first character of the '>>' token, whose spelling is '>'. For this to work, we generalize the expansion range of a macro FileID to be either a token range (the common case) or a character range (used in this new case). llvm-svn: 331155
* Revert rC330794 and some dependent tiny bug fixes Faisal Vali2018-04-261-1/+0
| | | | | | | | | | | | | | See Richard's humbling feedback here: http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180423/226482.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180423/226486.html Wish I'd had the patience to solicit the feedback prior to committing :) Sorry for the noise guys. Thank you Richard for being the steward that clang deserves! llvm-svn: 330888
* [c++2a] [concepts] Add rudimentary parsing support for template concept ↵Faisal Vali2018-04-251-0/+1
| | | | | | | | | | | | | | declarations This patch is a tweak of changyu's patch: https://reviews.llvm.org/D40381. It differs in that the recognition of the 'concept' token is moved into the machinery that recognizes declaration-specifiers - this allows us to leverage the attribute handling machinery more seamlessly. See the test file to get a sense of the basic parsing that this patch supports. There is much more work to be done before concepts are usable... Thanks Changyu! llvm-svn: 330794
* Record whether a module came from a private module mapJordan Rose2018-04-201-1/+3
| | | | | | | | | | | Right now we only use this information in one place, immediately after we calculate it, but it's still nice information to have. The Swift project is going to use this to tidy up its "API notes" feature (see past discussion on cfe-dev that never quite converged). Reviewed by Bruno Cardoso Lopes. llvm-svn: 330452
* [ObjC++] Never pass structs that transitively contain __weak fields inAkira Hatanaka2018-04-091-1/+1
| | | | | | | | | | | | | | | | | | | | registers. This patch fixes a bug in r328731 that caused structs transitively containing __weak fields to be passed in registers. The patch replaces the flag RecordDecl::CanPassInRegisters with a 2-bit enum that indicates whether the struct or structs containing the struct are forced to be passed indirectly. This reapplies r329617. r329617 didn't specify the underlying type for enum ArgPassingKind, which caused regression tests to fail on a windows bot. rdar://problem/39194693 Differential Revision: https://reviews.llvm.org/D45384 llvm-svn: 329635
* Revert "[ObjC++] Never pass structs that transitively contain __weak fields in"Akira Hatanaka2018-04-091-1/+1
| | | | | | | | This reverts commit r329617. It broke a windows bot. http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/16372/steps/test/logs/stdio llvm-svn: 329627
* [ObjC++] Never pass structs that transitively contain __weak fields inAkira Hatanaka2018-04-091-1/+1
| | | | | | | | | | | | | | registers. This patch fixes a bug in r328731 that caused structs transitively containing __weak fields to be passed in registers. The patch replaces the flag RecordDecl::CanPassInRegisters with a 2-bit enum that indicates whether the struct or structs containing the struct are forced to be passed indirectly. rdar://problem/39194693 llvm-svn: 329617
* Fix typos in clangAlexander Kornienko2018-04-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Found via codespell -q 3 -I ../clang-whitelist.txt Where whitelist consists of: archtype cas classs checkk compres definit frome iff inteval ith lod methode nd optin ot pres statics te thru Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few files that have dubious fixes reverted.) Differential revision: https://reviews.llvm.org/D44188 llvm-svn: 329399
* DR1672, DR1813, DR1881, DR2120: Implement recent fixes to "standardRichard Smith2018-04-051-1/+3
| | | | | | | | | | | | | | | | | layout" rules. The new rules say that a standard-layout struct has its first non-static data member and all base classes at offset 0, and consider a class to not be standard-layout if that would result in multiple subobjects of a single type having the same address. We track "is C++11 standard-layout class" separately from "is standard-layout class" so that the ABIs that need this information can still use it. Differential Revision: https://reviews.llvm.org/D45176 llvm-svn: 329332
* [ObjC++] Make parameter passing and function return compatible with ObjCAkira Hatanaka2018-03-281-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ObjC and ObjC++ pass non-trivial structs in a way that is incompatible with each other. For example: typedef struct { id f0; __weak id f1; } S; // this code is compiled in c++. extern "C" { void foo(S s); } void caller() { // the caller passes the parameter indirectly and destructs it. foo(S()); } // this function is compiled in c. // 'a' is passed directly and is destructed in the callee. void foo(S a) { } This patch fixes the incompatibility by passing and returning structs with __strong or weak fields using the C ABI in C++ mode. __strong and __weak fields in a struct do not cause the struct to be destructed in the caller and __strong fields do not cause the struct to be passed indirectly. Also, this patch fixes the microsoft ABI bug mentioned here: https://reviews.llvm.org/D41039?id=128767#inline-364710 rdar://problem/38887866 Differential Revision: https://reviews.llvm.org/D44908 llvm-svn: 328731
OpenPOWER on IntegriCloud