summaryrefslogtreecommitdiffstats
path: root/clang/lib/Serialization/ASTWriter.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Re-land: "[Support] Replace HashString with djbHash."Jonas Devlieghere2018-02-261-62/+62
| | | | | | | | | | | | | | | | | | | | | This patch removes the HashString function from StringExtraces and replaces its uses with calls to djbHash from DJB.h. This change is *almost* NFC. While the algorithm is identical, the djbHash implementation in StringExtras used 0 as its default seed while the implementation in DJB uses 5381. The latter has been shown to result in less collisions and improved avalanching and is used by the DWARF accelerator tables. Because some test were implicitly relying on the hash order, I've reverted to using zero as a seed for the following two files: lld/include/lld/Core/SymbolTable.h llvm/lib/Support/StringMap.cpp Differential revision: https://reviews.llvm.org/D43615 llvm-svn: 326091
* Revert "[Support] Replace HashString with djbHash."Jonas Devlieghere2018-02-261-62/+62
| | | | | | | | | | | | | It looks like some of our tests depend on the ordering of hashed values. I'm reverting my changes while I try to reproduce and fix this locally. Failing builds: lab.llvm.org:8011/builders/lld-x86_64-darwin13/builds/18388 lab.llvm.org:8011/builders/clang-cmake-x86_64-sde-avx512-linux/builds/6743 lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/15607 llvm-svn: 326082
* [Support] Replace HashString with djbHash.Jonas Devlieghere2018-02-261-62/+62
| | | | | | | | | | | | | | | This removes the HashString function from StringExtraces and replaces its uses with calls to djbHash from DJB.h This is *almost* NFC. While the algorithm is identical, the djbHash implementation in StringExtras used 0 as its seed while the implementation in DJB uses 5381. The latter has been shown to result in less collisions and improved avalanching. https://reviews.llvm.org/D43615 (cherry picked from commit 77f7f965bc9499a9ae768a296ca5a1f7347d1d2c) llvm-svn: 326081
* [modules] Fix incorrect diagnostic mapping computation when a module changesRichard Smith2018-02-091-2/+5
| | | | | | | | | | | | | | | diagnostic settings using _Pragma within a macro. The AST writer had previously been assuming that all diagnostic state transitions would occur within a FileID corresponding to a file. When a diagnostic state change occured within a macro, it was unable to form a location for that state change and would instead corrupt the diagnostic state of the "root" node (and thus that of the main compilation). Also introduce a "#pragma clang __debug diag_mapping" debugging utility that I added to track this issue down. llvm-svn: 324695
* Add support for attribute 'trivial_abi'.Akira Hatanaka2018-02-051-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* [index] Fix crash when indexing a C++14 PCH/module related to ↵Argyrios Kyrtzidis2018-01-261-1/+3
| | | | | | | | | | | | | TemplateTemplateParmDecls of alias templates TemplateTemplateParmDecls of alias templates ended-up serialized as 'file-level decls' which was causing a crash while trying to index a PCH/module file that contained them. Commit makes sure TemplateTemplateParmDecls are not recorded as such kind of decls. Fixes crash of rdar://36608297 Differential Revision: https://reviews.llvm.org/D42588 llvm-svn: 323549
* [PCH] Serialize skipped preprocessor rangesCameron Desrochers2018-01-151-0/+21
| | | | | | | | The skipped preprocessor ranges are now serialized in the AST PCH file. This fixes, for example, libclang's clang_getSkippedRanges() returning zero ranges after reparsing a translation unit. Differential Revision: https://reviews.llvm.org/D20124 llvm-svn: 322503
* Again reverting an attempt to convert the DeclSpec enums into scoped enums.Faisal Vali2018-01-011-3/+3
| | | | | | | | | | | | - reverts r321622, r321625, and r321626. - the use of bit-fields is still resulting in warnings - even though we can use static-asserts to harden the code and ensure the bit-fields are wide enough. The bots still complain of warnings being seen. - to silence the warnings requires specifying the bit-fields with the underlying enum type (as opposed to the enum type itself), which then requires lots of unnecessary static casts of each enumerator within DeclSpec to the underlying-type, which even though could be seen as implementation details, it does hamper readability - and given the additional litterings, makes me question the value of the change. So in short - I give up (for now at least). Sorry about the noise. llvm-svn: 321628
* [NFC] Modernize enums TypeSpecifierWidth, TypeSpecifierSign & ↵Faisal Vali2018-01-011-3/+3
| | | | | | | | | | | | TypeSpecifierType into scoped enums with underlying types. - Since these enums are used as bit-fields - for the bit-fields to be interpreted as unsigned, the underlying type must be specified as unsigned. Previous failed attempt - wherein I did not specify an underlying type - was the sum of: https://reviews.llvm.org/rC321614 https://reviews.llvm.org/rC321615 llvm-svn: 321622
* Revert r321614 and r321615Faisal Vali2018-01-011-3/+3
| | | | | | | | - the enum changes to TypeSpecifierType are breaking some tests - and will require a more careful integration. Sorry about rushing these changes - thought I could sneak them in prior to heading out for new years ;) llvm-svn: 321616
* Add scope specifiers to updated scoped-enums (that I somehow missed in r321614)Faisal Vali2018-01-011-3/+3
| | | | llvm-svn: 321615
* Generalize "static data member instantiated" notification to cover variable ↵Richard Smith2017-12-051-6/+22
| | | | | | | | | templates too. While here, split the "point of instantiation changed" notification out from it; these two really are orthogonal changes. llvm-svn: 319727
* Correctly handle line table entries without filenames during AST serializationHans Wennborg2017-12-041-1/+2
| | | | | | | | | | The current code would hit an assert in ASTWriter when trying to write out the filename for a line table entry that didn't have any. Fix this by allowing the -1 sentinel value to round-trip through serialization. Differential revision: https://reviews.llvm.org/D40746 llvm-svn: 319707
* [Serialization] Fix some Clang-tidy modernize and Include What You Use ↵Eugene Zelenko2017-11-111-54/+96
| | | | | | warnings; other minor fixes (NFC). llvm-svn: 317953
* [preamble] Also record the "skipping" state of the preprocessorErik Verbruggen2017-11-031-0/+11
| | | | | | | | | | When a preamble ends in a conditional preprocessor block that is being skipped, the preprocessor needs to continue skipping that block when the preamble is used. This fixes PR34570. llvm-svn: 317308
* PR33746: Store the 'inline'ness of a static data member with the update recordRichard Smith2017-11-021-0/+2
| | | | | | | | | for instantiating its definition. We model the 'inline'ness as being instantiated with the static data member in order to track whether the declaration has become a definition yet. llvm-svn: 317147
* Support for destroying operator delete, per C++2a proposal P0722.Richard Smith2017-10-131-1/+3
| | | | | | | | | | This feature is not (yet) approved by the C++ committee, so this is liable to be reverted or significantly modified based on committee feedback. No functionality change intended for existing code (a new type must be defined in namespace std to take advantage of this feature). llvm-svn: 315662
* Dependent Address Space SupportAndrew Gozillon2017-10-021-0/+18
| | | | | | | | | | | | | | This patch relates to: https://reviews.llvm.org/D33666 This adds support for template parameters to be passed to the address_space attribute. The main goal is to add further flexibility to the attribute and allow for it to be used easily with templates. The main additions are a new type (DependentAddressSpaceType) alongside its TypeLoc and its mangling. As well as the logic required to support dependent address spaces which mainly resides in TreeTransform.h and SemaType.cpp. llvm-svn: 314649
* Minor cleanups to address feedback from Bruno. NFCDouglas Gregor2017-09-141-1/+0
| | | | llvm-svn: 313318
* [Module map] Introduce a private module re-export directive.Douglas Gregor2017-09-141-0/+13
| | | | | | | | | | | | | Introduce a new "export_as" directive for top-level modules, which indicates that the current module is a "private" module whose symbols will eventually be exported through the named "public" module. This is in support of a common pattern in the Darwin ecosystem where a single public framework is constructed of several private frameworks, with (currently) header duplication and some support from the linker. Addresses rdar://problem/34438420. llvm-svn: 313316
* Fix MSVC narrowing conversion warning.Simon Pilgrim2017-09-041-1/+1
| | | | llvm-svn: 312479
* Implement Itanium name mangling support for C++ Modules TS.Richard Smith2017-09-041-2/+3
| | | | | | | | | | | | This follows the scheme agreed with Nathan Sidwell, which can be found here: https://gcc.gnu.org/wiki/cxx-modules?action=AttachFile This will be proposed to the itanium-cxx-abi list once we have some experience with how well it works; the ABI for this TS should be considered unstable until it is part of the Itanium C++ ABI. llvm-svn: 312467
* [modules] Add ability to specify module name to module file mapping (reapply)Boris Kolpackov2017-08-311-4/+14
| | | | | | | | | | | | | | | | | | | | Extend the -fmodule-file option to support the [<name>=]<file> value format. If the name is omitted, then the old semantics is preserved (the module file is loaded whether needed or not). If the name is specified, then the mapping is treated as just another prebuilt module search mechanism, similar to -fprebuilt-module-path, and the module file is only loaded if actually used (e.g., via import). With one exception: this mapping also overrides module file references embedded in other modules (which can be useful if module files are moved/renamed as often happens during remote compilation). This override semantics requires some extra work: we now store the module name in addition to the file name in the serialized AST representation. Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D35020 llvm-svn: 312220
* Revert r312105 [modules] Add ability to specify module name to module file ↵Victor Leschuk2017-08-301-14/+4
| | | | | | | | mapping Looks like it breaks win10 builder. llvm-svn: 312112
* [modules] Add ability to specify module name to module file mappingBoris Kolpackov2017-08-301-4/+14
| | | | | | | | | | | | | | | | | | | | Extend the -fmodule-file option to support the [<name>=]<file> value format. If the name is omitted, then the old semantics is preserved (the module file is loaded whether needed or not). If the name is specified, then the mapping is treated as just another prebuilt module search mechanism, similar to -fprebuilt-module-path, and the module file is only loaded if actually used (e.g., via import). With one exception: this mapping also overrides module file references embedded in other modules (which can be useful if module files are moved/renamed as often happens during remote compilation). This override semantics requires some extra work: we now store the module name in addition to the file name in the serialized AST representation. Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D35020 llvm-svn: 312105
* PR19668, PR23034: Fix handling of move constructors and deleted copyRichard Smith2017-08-161-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | constructors when deciding whether classes should be passed indirectly. This fixes ABI differences between Clang and GCC: * Previously, Clang ignored the move constructor when making this determination. It now takes the move constructor into account, per https://github.com/itanium-cxx-abi/cxx-abi/pull/17 (this change may seem recent, but the ABI change was agreed on the Itanium C++ ABI list a long time ago). * Previously, Clang's behavior when the copy constructor was deleted was unstable -- depending on whether the lazy declaration of the copy constructor had been triggered, you might get different behavior. We now eagerly declare the copy constructor whenever its deletedness is unclear, and ignore deleted copy/move constructors when looking for a trivial such constructor. This also fixes an ABI difference between Clang and MSVC: * If the copy constructor would be implicitly deleted (but has not been lazily declared yet), for instance because the class has an rvalue reference member, we would pass it directly. We now pass such a class indirectly, matching MSVC. Based on a patch by Vassil Vassilev, which was based on a patch by Bernd Schmidt, which was based on a patch by Reid Kleckner! This is a re-commit of r310401, which was reverted in r310464 due to ARM failures (which should now be fixed). llvm-svn: 310983
* Revert "PR19668, PR23034: Fix handling of move constructors and deleted copy ↵Diana Picus2017-08-091-3/+0
| | | | | | | | | constructors when deciding whether classes should be passed indirectly." This reverts commit r310401 because it seems to have broken some ARM bot(s). llvm-svn: 310464
* PR19668, PR23034: Fix handling of move constructors and deleted copyRichard Smith2017-08-081-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | constructors when deciding whether classes should be passed indirectly. This fixes ABI differences between Clang and GCC: * Previously, Clang ignored the move constructor when making this determination. It now takes the move constructor into account, per https://github.com/itanium-cxx-abi/cxx-abi/pull/17 (this change may seem recent, but the ABI change was agreed on the Itanium C++ ABI list a long time ago). * Previously, Clang's behavior when the copy constructor was deleted was unstable -- depending on whether the lazy declaration of the copy constructor had been triggered, you might get different behavior. We now eagerly declare the copy constructor whenever its deletedness is unclear, and ignore deleted copy/move constructors when looking for a trivial such constructor. This also fixes an ABI difference between Clang and MSVC: * If the copy constructor would be implicitly deleted (but has not been lazily declared yet), for instance because the class has an rvalue reference member, we would pass it directly. We now pass such a class indirectly, matching MSVC. llvm-svn: 310401
* Recommit r308327 3rd time: Add a warning for missingAlex Lorenz2017-07-281-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | '#pragma pack (pop)' and suspicious uses of '#pragma pack' in included files The second recommit (r309106) was reverted because the "non-default #pragma pack value chages the alignment of struct or union members in the included file" warning proved to be too aggressive for external projects like Chromium (https://bugs.chromium.org/p/chromium/issues/detail?id=749197). This recommit makes the problematic warning a non-default one, and gives it the -Wpragma-pack-suspicious-include warning option. The first recommit (r308441) caused a "non-default #pragma pack value might change the alignment of struct or union members in the included file" warning in LLVM itself. This recommit tweaks the added warning to avoid warnings for #includes that don't have any records that are affected by the non-default alignment. This tweak avoids the previously emitted warning in LLVM. Original message: This commit adds a new -Wpragma-pack warning. It warns in the following cases: - When a translation unit is missing terminating #pragma pack (pop) directives. - When entering an included file if the current alignment value as determined by '#pragma pack' directives is different from the default alignment value. - When leaving an included file that changed the state of the current alignment value. rdar://10184173 Differential Revision: https://reviews.llvm.org/D35484 llvm-svn: 309386
* Revert r309106 "Recommit r308327 2nd time: Add a warning for missing"Hans Wennborg2017-07-261-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The warning fires on non-suspicious code in Chromium. Reverting until a solution is figured out. > Recommit r308327 2nd time: Add a warning for missing > '#pragma pack (pop)' and suspicious uses of '#pragma pack' in included files > > The first recommit (r308441) caused a "non-default #pragma pack value might > change the alignment of struct or union members in the included file" warning > in LLVM itself. This recommit tweaks the added warning to avoid warnings for > #includes that don't have any records that are affected by the non-default > alignment. This tweak avoids the previously emitted warning in LLVM. > > Original message: > > This commit adds a new -Wpragma-pack warning. It warns in the following cases: > > - When a translation unit is missing terminating #pragma pack (pop) directives. > - When entering an included file if the current alignment value as determined > by '#pragma pack' directives is different from the default alignment value. > - When leaving an included file that changed the state of the current alignment > value. > > rdar://10184173 > > Differential Revision: https://reviews.llvm.org/D35484 llvm-svn: 309186
* Recommit r308327 2nd time: Add a warning for missingAlex Lorenz2017-07-261-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | '#pragma pack (pop)' and suspicious uses of '#pragma pack' in included files The first recommit (r308441) caused a "non-default #pragma pack value might change the alignment of struct or union members in the included file" warning in LLVM itself. This recommit tweaks the added warning to avoid warnings for #includes that don't have any records that are affected by the non-default alignment. This tweak avoids the previously emitted warning in LLVM. Original message: This commit adds a new -Wpragma-pack warning. It warns in the following cases: - When a translation unit is missing terminating #pragma pack (pop) directives. - When entering an included file if the current alignment value as determined by '#pragma pack' directives is different from the default alignment value. - When leaving an included file that changed the state of the current alignment value. rdar://10184173 Differential Revision: https://reviews.llvm.org/D35484 llvm-svn: 309106
* Revert r308441 "Recommit r308327: Add a warning for missing '#pragma pack ↵Hans Wennborg2017-07-191-1/+0
| | | | | | | | | | | | | | | | | | | | | (pop)' and suspicious uses of '#pragma pack' in included files" This seems to have broken the sanitizer-x86_64-linux buildbot. Reverting until it's fixed, especially since this landed just before the 5.0 branch. > This commit adds a new -Wpragma-pack warning. It warns in the following cases: > > - When a translation unit is missing terminating #pragma pack (pop) directives. > - When entering an included file if the current alignment value as determined > by '#pragma pack' directives is different from the default alignment value. > - When leaving an included file that changed the state of the current alignment > value. > > rdar://10184173 > > Differential Revision: https://reviews.llvm.org/D35484 llvm-svn: 308455
* Recommit r308327: Add a warning for missing '#pragma pack (pop)'Alex Lorenz2017-07-191-0/+1
| | | | | | | | | | | | | | | | | | and suspicious uses of '#pragma pack' in included files This commit adds a new -Wpragma-pack warning. It warns in the following cases: - When a translation unit is missing terminating #pragma pack (pop) directives. - When entering an included file if the current alignment value as determined by '#pragma pack' directives is different from the default alignment value. - When leaving an included file that changed the state of the current alignment value. rdar://10184173 Differential Revision: https://reviews.llvm.org/D35484 llvm-svn: 308441
* Revert r308327Alex Lorenz2017-07-181-1/+0
| | | | | | I forgot to test clang-tools-extra which is now failing. llvm-svn: 308328
* Add a warning for missing '#pragma pack (pop)' and suspicious usesAlex Lorenz2017-07-181-0/+1
| | | | | | | | | | | | | | | | | | of '#pragma pack' in included files This commit adds a new -Wpragma-pack warning. It warns in the following cases: - When a translation unit is missing terminating #pragma pack (pop) directives. - When entering an included file if the current alignment value as determined by '#pragma pack' directives is different from the default alignment value. - When leaving an included file that changed the state of the current alignment value. rdar://10184173 Differential Revision: https://reviews.llvm.org/D35484 llvm-svn: 308327
* [NFC] Refactor the Preprocessor function that handles Macro definitions and ↵Faisal Vali2017-07-171-3/+3
| | | | | | | | | | | | | | | | | rename Arguments to Parameters in Macro Definitions. - Extracted the reading of the tokens out into a separate function. - Replace 'Argument' with 'Parameter' when referring to the identifiers of the macro definition (as opposed to the supplied arguments - MacroArgs - during the macro invocation). This is in preparation for submitting patches for review to implement __VA_OPT__ which will otherwise just keep lengthening the HandleDefineDirective function and making it less comprehensible. I will also directly update some extra clang tooling that is broken by the change from Argument to Parameter. Hopefully the bots will stay appeased. Thanks! llvm-svn: 308190
* Revert changes from my previous refactoring - will need to fix dependencies ↵Faisal Vali2017-07-171-3/+3
| | | | | | | | in clang's extra tooling (such as clang-tidy etc.). Sorry about that. llvm-svn: 308158
* [NFC] Refactor the Preprocessor function that handles Macro definitions and ↵Faisal Vali2017-07-171-3/+3
| | | | | | | | | | | | | | rename Arguments to Parameters in Macro Definitions. - Extracted the reading of the tokens out into a separate function. - Replace 'Argument' with 'Parameter' when referring to the identifiers of the macro definition (as opposed to the supplied arguments - MacroArgs - during the macro invocation). This is in preparation for submitting patches for review to implement __VA_OPT__ which will otherwise just keep lengthening the HandleDefineDirective function and making it less comprehensible. Thanks! llvm-svn: 308157
* [modules ts] Improve merging of module-private declarations.Richard Smith2017-07-051-1/+1
| | | | | | | | | | These cases occur frequently for declarations in the global module (above the module-declaration) in a Modules TS module interface. When we merge a definition from another module into such a module-private definition, ensure that we transitively make everything lexically within that definition visible to that translation unit. llvm-svn: 307129
* Track the set of module maps read while building a .pcm file and reload ↵Richard Smith2017-06-291-6/+12
| | | | | | those when preprocessing from that .pcm file. llvm-svn: 306628
* PR33002: When we instantiate the definition of a static data member, we mightRichard Smith2017-06-221-1/+10
| | | | | | | have attached an initializer to the in-class declaration. If so, include the initializer in the update record for the instantiation. llvm-svn: 306065
* Retain header search and preprocessing options from AST file when emittingRichard Smith2017-06-061-0/+2
| | | | | | preprocessed text for an AST file. llvm-svn: 304756
* [Modules] Fix use after scope.Benjamin Kramer2017-06-021-1/+2
| | | | | | Found by asan. llvm-svn: 304568
* Support lazy stat'ing of files referenced by module maps.Richard Smith2017-06-021-42/+114
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds support for a `header` declaration in a module map to specify certain `stat` information (currently, size and mtime) about that header file. This has two purposes: - It removes the need to eagerly `stat` every file referenced by a module map. Instead, we track a list of unresolved header files with each size / mtime (actually, for simplicity, we track submodules with such headers), and when attempting to look up a header file based on a `FileEntry`, we check if there are any unresolved header directives with that `FileEntry`'s size / mtime and perform deferred `stat`s if so. - It permits a preprocessed module to be compiled without the original files being present on disk. The only reason we used to need those files was to get the `stat` information in order to do header -> module lookups when using the module. If we're provided with the `stat` information in the preprocessed module, we can avoid requiring the files to exist. Unlike most `header` directives, if a `header` directive with `stat` information has no corresponding on-disk file the enclosing module is *not* marked unavailable (so that behavior is consistent regardless of whether we've resolved a header directive, and so that preprocessed modules don't get marked unavailable). We could actually do this for all `header` directives: the only reason we mark the module unavailable if headers are missing is to give a diagnostic slightly earlier (rather than waiting until we actually try to build the module / load and validate its .pcm file). Differential Revision: https://reviews.llvm.org/D33703 llvm-svn: 304515
* [modules] When compiling a preprocessed module map, look for headers relativeRichard Smith2017-05-311-4/+5
| | | | | | | | | | | | to the original module map. Also use the path and name of the original module map when emitting that information into the .pcm file. The upshot of this is that the produced .pcm file will track information for headers in their original locations (where the module was preprocessed), not relative to whatever directory the preprocessed module map was in when it was built. llvm-svn: 304346
* Allow for unfinished #if blocks in preamblesErik Verbruggen2017-05-301-0/+13
| | | | | | | | | | | | | | | | | | | Previously, a preamble only included #if blocks (and friends like ifdef) if there was a corresponding #endif before any declaration or definition. The problem is that any header file that uses include guards will not have a preamble generated, which can make code-completion very slow. To prevent errors about unbalanced preprocessor conditionals in the preamble, and unbalanced preprocessor conditionals after a preamble containing unfinished conditionals, the conditional stack is stored in the pch file. This fixes PR26045. Differential Revision: http://reviews.llvm.org/D15994 llvm-svn: 304207
* [modules] Switch from inferring owning modules based on source location toRichard Smith2017-05-181-19/+0
| | | | | | | | | | | | | | | inferring based on the current module at the point of creation. This should result in no functional change except when building a preprocessed module (or more generally when using #pragma clang module begin/end to switch module in the middle of a file), in which case it allows us to correctly track the owning module for declarations. We can't map from FileID to module in the preprocessed module case, since all modules would have the same FileID. There are still a couple of remaining places that try to infer a module from a source location; I'll clean those up in follow-up changes. llvm-svn: 303322
* Remove unused tracking of owning module for MacroInfo objects.Richard Smith2017-05-121-1/+0
| | | | llvm-svn: 302966
* Silences gcc's -Wnarrowing.Daniel Jasper2017-05-031-2/+3
| | | | | | | | | I think this is a false positive in GCC's warning, but nonetheless, we should try to be warning-free. Smaller reproducer (reproduces with GCC 6.3): https://godbolt.org/g/cJuO2z llvm-svn: 302003
* [modules] Round-trip -Werror flag through explicit module build.Richard Smith2017-05-031-1/+19
| | | | | | | | | | | | | | | The intent for an explicit module build is that the diagnostics produced within the module are those that were configured when the module was built, not those that are enabled within a user of the module. This includes diagnostics that don't actually show up until the module is used (for instance, diagnostics produced during template instantiation and weird cases like -Wpadded). We serialized and restored the diagnostic state for individual warning groups, but previously did not track the state for flags like -Werror and -Weverything, which are implemented as separate bits rather than as part of the diagnostics mapping information. llvm-svn: 301992
OpenPOWER on IntegriCloud