summaryrefslogtreecommitdiffstats
path: root/clang/lib/Serialization
Commit message (Collapse)AuthorAgeFilesLines
* Merging r345497:Tom Stellard2018-11-291-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ------------------------------------------------------------------------ r345497 | asavonic | 2018-10-29 04:14:01 -0700 (Mon, 29 Oct 2018) | 29 lines [OpenCL] Fix serialization of OpenCLExtensionDecls 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: 347834
* Merging r339603:Hans Wennborg2018-08-162-6/+21
| | | | | | | | | | | | | ------------------------------------------------------------------------ r339603 | abataev | 2018-08-13 21:04:24 +0200 (Mon, 13 Aug 2018) | 4 lines [OPENMP] Fix emission of the loop doacross constructs. The number of loops associated with the OpenMP loop constructs should not be considered as the number loops to collapse. ------------------------------------------------------------------------ llvm-svn: 339851
* [Modules] Do not emit relocation error when -fno-validate-pch is setYuka Takahashi2018-08-011-3/+8
| | | | | | | | | | | | Summary: Clang emits error when implicit modules was relocated from the first build directory. However this was biting our usecase where we copy the contents of build directory to another directory in order to distribute. Differential Revision: https://reviews.llvm.org/D49852 llvm-svn: 338503
* [serialization] PR34728: Don't assume that only a suffix of templateRichard Smith2018-07-311-15/+9
| | | | | | | | | | | | | parameters can have default arguments. At least for function templates and class template partial specializations, it's possible for a template parameter with a default argument to be followed by a non-pack template parameter with no default argument, and this case was not properly handled here. Testcase by Steve O'Brien! llvm-svn: 338438
* Remove trailing spaceFangrui Song2018-07-307-105/+105
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
* [AST] Sink 'part of explicit cast' down into ImplicitCastExprRoman Lebedev2018-07-272-2/+2
| | | | | | | | | | | | | | | | | | | | | | | Summary: As discussed in IRC with @rsmith, it is slightly not good to keep that in the `CastExpr` itself: Given the explicit cast, which is represented in AST as an `ExplicitCastExpr` + `ImplicitCastExpr`'s, only the `ImplicitCastExpr`'s will be marked as `PartOfExplicitCast`, but not the `ExplicitCastExpr` itself. Thus, it is only ever `true` for `ImplicitCastExpr`'s, so we don't need to write/read/dump it for `ExplicitCastExpr`'s. We don't need to worry that we write the `PartOfExplicitCast` in PCH after `CastExpr::path_iterator`, since the `ExprImplicitCastAbbrev` is only used when the `NumBaseSpecs == 0`, i.e. there is no 'path'. Reviewers: rsmith, rjmccall, erichkeane, aaron.ballman Reviewed By: rsmith, erichkeane Subscribers: vsk, cfe-commits, rsmith Tags: #clang Differential Revision: https://reviews.llvm.org/D49838 llvm-svn: 338108
* [ODRHash] Support hashing enums.Richard Trieu2018-07-253-2/+210
| | | | llvm-svn: 337978
* [Sema] Mark implicitly-inserted ICE's as being part of explicit cast (PR38166)Roman Lebedev2018-07-243-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: As discussed in [[ https://bugs.llvm.org/show_bug.cgi?id=38166 | PR38166 ]], we need to be able to distinqush whether the cast we are visiting is actually a cast, or part of an `ExplicitCast`. There are at least four ways to get there: 1. Introduce a new `CastKind`, and use it instead of `IntegralCast` if we are in `ExplicitCast`. Would work, but does not scale - what if we will need more of these cast kinds? 2. Introduce a flag in `CastExprBits`, whether this cast is part of `ExplicitCast` or not. Would work, but it isn't immediately clear where it needs to be set. 2. Fix `ScalarExprEmitter::VisitCastExpr()` to visit these `NoOp` casts. As pointed out by @rsmith, CodeGenFunction::EmitMaterializeTemporaryExpr calls skipRValueSubobjectAdjustments, which steps over the CK_NoOp cast`, which explains why we currently don't visit those. This is probably impossible, as @efriedma points out, that is intentional as per `[class.temporary]` in the standard 3. And the simplest one, just record which NoOp casts we skip. It just kinda works as-is afterwards. But, the approach with a flag is the least intrusive one, and is probably the best one overall. Reviewers: rsmith, rjmccall, majnemer, efriedma Reviewed By: rsmith Subscribers: cfe-commits, aaron.ballman, vsk, llvm-commits, rsmith Differential Revision: https://reviews.llvm.org/D49508 llvm-svn: 337815
* Reapply r336660: [Modules] Autoload subdirectory modulemaps with specific ↵Bruno Cardoso Lopes2018-07-181-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | LangOpts Summary: Reproducer and errors: https://bugs.llvm.org/show_bug.cgi?id=37878 lookupModule was falling back to loadSubdirectoryModuleMaps when it couldn't find ModuleName in (proper) search paths. This was causing iteration over all files in the search path subdirectories for example "/usr/include/foobar" in bugzilla case. Users don't expect Clang to load modulemaps in subdirectories implicitly, and also the disk access is not cheap. if (AllowExtraModuleMapSearch) true with ObjC with @import ModuleName. Reviewers: rsmith, aprantl, bruno Subscribers: cfe-commits, teemperor, v.g.vassilev Differential Revision: https://reviews.llvm.org/D48367 llvm-svn: 337430
* PR15730/PR16986 Allow dependently typed vector_size types.Erich Keane2018-07-132-0/+29
| | | | | | | | | | | | | | | | | 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 "[modules] Fix 37878; Autoload subdirectory modulemaps with specific ↵Bruno Cardoso Lopes2018-07-121-3/+1
| | | | | | | | | | | | | | | LangOpts" This reverts commit f40124d4f05ecf4f880cf4e8f26922d861f705f3 / r336660. This change shouldn't be affecting `@import` behavior, but turns out it is: https://ci.swift.org/view/swift-master-next/job/oss-swift-incremental-RA-osx-master-next/2800/consoleFull#-12570166563122a513-f36a-4c87-8ed7-cbc36a1ec144 Working on a reduced testcase for this, reverting in the meantime. rdar://problem/42102222 llvm-svn: 336920
* Revert -r336726, which included more files than intended.Erich Keane2018-07-102-27/+0
| | | | llvm-svn: 336727
* [NFC] Switch CodeGenFunction to use value init instead of member init listsErich Keane2018-07-102-0/+27
| | | | | | | | 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
* [modules] Fix 37878; Autoload subdirectory modulemaps with specific LangOptsYuka Takahashi2018-07-101-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Reproducer and errors: https://bugs.llvm.org/show_bug.cgi?id=37878 lookupModule was falling back to loadSubdirectoryModuleMaps when it couldn't find ModuleName in (proper) search paths. This was causing iteration over all files in the search path subdirectories for example "/usr/include/foobar" in bugzilla case. Users don't expect Clang to load modulemaps in subdirectories implicitly, and also the disk access is not cheap. if (AllowExtraModuleMapSearch) true with ObjC with @import ModuleName. Reviewers: rsmith, aprantl, bruno Subscribers: cfe-commits, teemperor, v.g.vassilev Differential Revision: https://reviews.llvm.org/D48367 llvm-svn: 336660
* [ODRHash] Merge the two function hashes into one.Richard Trieu2018-07-101-3/+66
| | | | | | | | | | | Functions that are a sub-Decl of a record were hashed differently than other functions. This change keeps the AddFunctionDecl function and the hash of records now calls this function. In addition, AddFunctionDecl has an option to perform a hash as if the body was absent, which is required for some checks after loading modules. Additional logic prevents multiple error message from being printed. llvm-svn: 336632
* [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
* [clang-cl, PCH] Implement support for MS-style PCH through headersErich Keane2018-07-051-0/+11
| | | | | | | | | | | | | | | | | | | | | Implement support for MS-style PCH through headers. This enables support for /Yc and /Yu where the through header is either on the command line or included in the source. It replaces the current support the requires the header also be specified with /FI. This change adds a -cc1 option -pch-through-header that is used to either start or stop compilation during PCH create or use. When creating a PCH, the compilation ends after compilation of the through header. When using a PCH, tokens are skipped until after the through header is seen. Patch By: mikerice Differential Revision: https://reviews.llvm.org/D46652 llvm-svn: 336379
* PR33924: merge local declarations that have linkage of some kind withinRichard Smith2018-07-042-25/+99
| | | | | | | | | | | | | | | | | | | | | | | | | | | merged function definitions; also merge functions with deduced return types. This seems like two independent fixes, but unfortunately they are hard to separate because it's challenging to reliably test either one of them without also testing the other. A complication arises with deduced return type support: we need the type of the function in order to know how to merge it, but we can't load the actual type of the function because it might reference an entity declared within the function (and we need to have already merged the function to correctly merge that entity, which we would need to do to determine if the function types match). So we instead compare the declared function type when merging functions, and defer loading the actual type of a function with a deduced type until we've finished loading and merging the function. This reverts r336175, reinstating r336021, with one change (for PR38015): we look at the TypeSourceInfo of the first-so-far declaration of each function when considering whether to merge two functions. This works around a problem where the calling convention in the TypeSourceInfo for subsequent redeclarations may not match if it was implicitly adjusted. llvm-svn: 336240
* Revert r336021 "PR33924: merge local declarations that have linkage of some ↵Hans Wennborg2018-07-032-94/+25
| | | | | | | | | | | | | | | | | | | | | | | | | kind within" This caused test failures in 32-bit builds (PR38015). > merged function definitions; also merge functions with deduced return > types. > > This seems like two independent fixes, but unfortunately they are hard > to separate because it's challenging to reliably test either one of them > without also testing the other. > > A complication arises with deduced return type support: we need the type > of the function in order to know how to merge it, but we can't load the > actual type of the function because it might reference an entity > declared within the function (and we need to have already merged the > function to correctly merge that entity, which we would need to do to > determine if the function types match). So we instead compare the > declared function type when merging functions, and defer loading the > actual type of a function with a deduced type until we've finished > loading and merging the function. llvm-svn: 336175
* PR33924: merge local declarations that have linkage of some kind withinRichard Smith2018-06-292-25/+94
| | | | | | | | | | | | | | | | | | | | | merged function definitions; also merge functions with deduced return types. This seems like two independent fixes, but unfortunately they are hard to separate because it's challenging to reliably test either one of them without also testing the other. A complication arises with deduced return type support: we need the type of the function in order to know how to merge it, but we can't load the actual type of the function because it might reference an entity declared within the function (and we need to have already merged the function to correctly merge that entity, which we would need to do to determine if the function types match). So we instead compare the declared function type when merging functions, and defer loading the actual type of a function with a deduced type until we've finished loading and merging the function. llvm-svn: 336021
* [modules] Emit the type of the TypeSourceInfo for a DeclaratorDecl (butRichard Smith2018-06-294-17/+26
| | | | | | | | | | | 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
* [modules] Ensure that an in-class function definition is attached to theRichard Smith2018-06-281-0/+13
| | | | | | | | | | | declaration of the function that ends up in the primary definition of the class. ... at least for class templates. This is necessary for us to be able to track when an inline friend function has a definition that needs to be (lazily) instantiated. llvm-svn: 335805
* Revert "Append new attributes to the end of an AttributeList."Michael Kruse2018-06-251-11/+22
| | | | | | | 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-252-5/+19
| | | | | | | | | | | | | | | | | | | | | | | 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
* [Fixed Point Arithmetic] Fixed Point Precision Bits and Fixed Point LiteralsLeonard Chan2018-06-202-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This diff includes the logic for setting the precision bits for each primary fixed point type in the target info and logic for initializing a fixed point literal. Fixed point literals are declared using the suffixes ``` hr: short _Fract uhr: unsigned short _Fract r: _Fract ur: unsigned _Fract lr: long _Fract ulr: unsigned long _Fract hk: short _Accum uhk: unsigned short _Accum k: _Accum uk: unsigned _Accum ``` Errors are also thrown for illegal literal values ``` unsigned short _Accum u_short_accum = 256.0uhk; // expected-error{{the integral part of this literal is too large for this unsigned _Accum type}} ``` Differential Revision: https://reviews.llvm.org/D46915 llvm-svn: 335148
* Append new attributes to the end of an AttributeList.Michael Kruse2018-06-191-22/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... instead of prepending it at the beginning (the original behavior since implemented in r122535 2010-12-23). This builds up an AttributeList in the the order in which the attributes appear in the source. The reverse order caused nodes for attributes in the AST (e.g. LoopHint) to be in the reverse, and therefore printed in the wrong order by -ast-dump. Some TODO comments mention this. The order was explicitly reversed for enable_if attribute overload resolution and name mangling, which is not necessary anymore with this patch. The change unfortunately has some secondary effects, especially for diagnostic output. In the simplest cases, the CHECK lines or expected diagnostic were changed to the the new output. If the kind of error/warning changed, the attribute's order was changed instead. It also causes some 'previous occurrence here' hints to be textually after the main marker. This typically happens when attributes are merged, but are incompatible. Interchanging the role of the the main and note SourceLocation will also cause the case where two different declaration's attributes (in contrast to multiple attributes of the same declaration) are merged to be reversed. There is no easy fix because sometimes previous attributes are merged into a new declaration's attribute list, sometimes new attributes are added to a previous declaration's attribute list. Since 'previous occurrence here' pointing to locations after the main marker is not rare, I left the markers as-is; it is only relevant when the attributes are declared in the same declaration anyway, which often is on the same line. Differential Revision: https://reviews.llvm.org/D48100 llvm-svn: 335084
* Revert r335019 "Update NRVO logic to support early return (Attempt 2)"Taiju Tsuiki2018-06-192-3/+3
| | | | llvm-svn: 335022
* Update NRVO logic to support early return (Attempt 2)Taiju Tsuiki2018-06-192-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is the second attempt of r333500 (Update NRVO logic to support early return). The previous one was reverted for a miscompilation for an incorrect NRVO set up on templates such as: ``` struct Foo {}; template <typename T> T bar() { T t; if (false) return T(); return t; } ``` Where, `t` is marked as non-NRVO variable before its instantiation. However, while its instantiation, it's left an NRVO candidate, turned into an NRVO variable later. Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D47586 llvm-svn: 335019
* [Fixed Point Arithmetic] Addition of the remaining fixed point types and ↵Leonard Chan2018-06-142-0/+108
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | their saturated equivalents This diff includes changes for the remaining _Fract and _Sat fixed point types. ``` signed short _Fract s_short_fract; signed _Fract s_fract; signed long _Fract s_long_fract; unsigned short _Fract u_short_fract; unsigned _Fract u_fract; unsigned long _Fract u_long_fract; // Aliased fixed point types short _Accum short_accum; _Accum accum; long _Accum long_accum; short _Fract short_fract; _Fract fract; long _Fract long_fract; // Saturated fixed point types _Sat signed short _Accum sat_s_short_accum; _Sat signed _Accum sat_s_accum; _Sat signed long _Accum sat_s_long_accum; _Sat unsigned short _Accum sat_u_short_accum; _Sat unsigned _Accum sat_u_accum; _Sat unsigned long _Accum sat_u_long_accum; _Sat signed short _Fract sat_s_short_fract; _Sat signed _Fract sat_s_fract; _Sat signed long _Fract sat_s_long_fract; _Sat unsigned short _Fract sat_u_short_fract; _Sat unsigned _Fract sat_u_fract; _Sat unsigned long _Fract sat_u_long_fract; // Aliased saturated fixed point types _Sat short _Accum sat_short_accum; _Sat _Accum sat_accum; _Sat long _Accum sat_long_accum; _Sat short _Fract sat_short_fract; _Sat _Fract sat_fract; _Sat long _Fract sat_long_fract; ``` This diff only allows for declaration of these fixed point types. Assignment and other operations done on fixed point types according to http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf will be added in future patches. Differential Revision: https://reviews.llvm.org/D46911 llvm-svn: 334718
* Move VersionTuple from clang/Basic to llvm/SupportPavel Labath2018-06-112-3/+3
| | | | | | | | | | | | | | | | | | | | | | | 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
* This diff includes changes for supporting the following types.Leonard Chan2018-06-042-0/+36
| | | | | | | | | | | | | | | | | | | | | | | | | // Primary fixed point types signed short _Accum s_short_accum; signed _Accum s_accum; signed long _Accum s_long_accum; unsigned short _Accum u_short_accum; unsigned _Accum u_accum; unsigned long _Accum u_long_accum; // Aliased fixed point types short _Accum short_accum; _Accum accum; long _Accum long_accum; This diff only allows for declaration of the fixed point types. Assignment and other operations done on fixed point types according to http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf will be added in future patches. The saturated versions of these types and the equivalent _Fract types will also be added in future patches. The tests included are for asserting that we can declare these types. Fixed the test that was failing by not checking for dso_local on some targets. Differential Revision: https://reviews.llvm.org/D46084 llvm-svn: 333923
* Revert "This diff includes changes for supporting the following types."Leonard Chan2018-06-022-36/+0
| | | | | | | This reverts commit r333814, which fails for a test checking the bit width on ubuntu. llvm-svn: 333815
* This diff includes changes for supporting the following types.Leonard Chan2018-06-022-0/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | ``` // Primary fixed point types signed short _Accum s_short_accum; signed _Accum s_accum; signed long _Accum s_long_accum; unsigned short _Accum u_short_accum; unsigned _Accum u_accum; unsigned long _Accum u_long_accum; // Aliased fixed point types short _Accum short_accum; _Accum accum; long _Accum long_accum; ``` This diff only allows for declaration of the fixed point types. Assignment and other operations done on fixed point types according to http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf will be added in future patches. The saturated versions of these types and the equivalent `_Fract` types will also be added in future patches. The tests included are for asserting that we can declare these types. Differential Revision: https://reviews.llvm.org/D46084 llvm-svn: 333814
* Revert "Update NRVO logic to support early return"Sam McCall2018-05-302-3/+3
| | | | | | This reverts commit r333500, which causes stage2 compiler crashes. llvm-svn: 333547
* Update NRVO logic to support early returnTaiju Tsuiki2018-05-302-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The previous implementation misses an opportunity to apply NRVO (Named Return Value Optimization) below. That discourages user to write early return code. ``` struct Foo {}; Foo f(bool b) { if (b) return Foo(); Foo oo; return oo; } ``` That is, we can/should apply RVO for a local variable if: * It's directly returned by at least one return statement. * And, all reachable return statements in its scope returns the variable directly. While, the previous implementation disables the RVO in a scope if there are multiple return statements that refers different variables. On the new algorithm, local variables are in NRVO_Candidate state at first, and a return statement changes it to NRVO_Disabled for all visible variables but the return statement refers. Then, at the end of the function AST traversal, NRVO is enabled for variables in NRVO_Candidate state and refers from at least one return statement. Reviewers: rsmith Reviewed By: rsmith Subscribers: xbolva00, Quuxplusone, arthur.j.odwyer, cfe-commits Differential Revision: https://reviews.llvm.org/D47067 llvm-svn: 333500
* [ODRHash] Support FunctionTemplateDecl in records.Richard Trieu2018-05-301-1/+318
| | | | llvm-svn: 333486
* Fix unaligned memory access when reading INPUT_FILE_OFFSETS dataRaphael Isemann2018-05-231-1/+2
| | | | | | | | | | | | | | Summary: The blob data is unaligned, so we also should read it as such. Should fix the random failures with the sanitizer builds. Reviewers: rsmith, v.g.vassilev Reviewed By: v.g.vassilev Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D47247 llvm-svn: 333069
* Support: Simplify endian stream interface. NFCI.Peter Collingbourne2018-05-183-21/+20
| | | | | | | | | | | | 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
* Move helper classes into anonymous namespaces. NFCI.Benjamin Kramer2018-05-151-2/+2
| | | | llvm-svn: 332400
* [AST] Print correct tag decl for tag specifierJoel E. Denny2018-05-142-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-0910-153/+153
| | | | | | | | | | | | | | | | | | | 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-032-2/+2
| | | | | | | | | | | | | | 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
* Implement P0482R2, support for char8_t type.Richard Smith2018-05-012-0/+6
| | | | | | | | | | | | This is not yet part of any C++ working draft, and so is controlled by the flag -fchar8_t rather than a -std= flag. (The GCC implementation is controlled by a flag with the same name.) This implementation is experimental, and will be removed or revised substantially to match the proposal as it makes its way through the C++ committee. llvm-svn: 331244
* [Modules] Handle ObjC/C ODR-like semantics for EnumConstantDeclBruno Cardoso Lopes2018-04-301-4/+20
| | | | | | | | | | | | | | Support for ObjC/C ODR-like semantics with structural equivalence checking was added back in r306918. There enums are handled and also checked for structural equivalence. However, at use time of EnumConstantDecl, support was missing for preventing ambiguous name lookup. Add the missing bits for properly merging EnumConstantDecl. rdar://problem/38374569 llvm-svn: 331232
* PR37189 Fix incorrect end source location and spelling for a split '>>' token.Richard Smith2018-04-302-0/+3
| | | | | | | | | | | | | | | | | | 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
* [Modules][ObjC] ASTReader should add protocols for class extensionsBruno Cardoso Lopes2018-04-271-0/+6
| | | | | | | | | | | | During deserialization clang is currently missing the merging of protocols into the canonical interface for the class extension. This merging only currently happens during parsing and should also be considered during deserialization. rdar://problem/38724303 llvm-svn: 331063
* Revert rC330794 and some dependent tiny bug fixes Faisal Vali2018-04-264-18/+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-254-0/+18
| | | | | | | | | | | | | | 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
* [ODRHash] Hash template arguments of methods.Richard Trieu2018-04-251-0/+92
| | | | llvm-svn: 330789
OpenPOWER on IntegriCloud