summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/Sema.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Remove trailing spaceFangrui Song2018-07-301-1/+1
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
* Implement cpu_dispatch/cpu_specific MultiversioningErich Keane2018-07-201-11/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As documented here: https://software.intel.com/en-us/node/682969 and https://software.intel.com/en-us/node/523346. cpu_dispatch multiversioning is an ICC feature that provides for function multiversioning. This feature is implemented with two attributes: First, cpu_specific, which specifies the individual function versions. Second, cpu_dispatch, which specifies the location of the resolver function and the list of resolvable functions. This is valuable since it provides a mechanism where the resolver's TU can be specified in one location, and the individual implementions each in their own translation units. The goal of this patch is to be source-compatible with ICC, so this implementation diverges from the ICC implementation in a few ways: 1- Linux x86/64 only: This implementation uses ifuncs in order to properly dispatch functions. This is is a valuable performance benefit over the ICC implementation. A future patch will be provided to enable this feature on Windows, but it will obviously more closely fit ICC's implementation. 2- CPU Identification functions: ICC uses a set of custom functions to identify the feature list of the host processor. This patch uses the cpu_supports functionality in order to better align with 'target' multiversioning. 1- cpu_dispatch function def/decl: ICC's cpu_dispatch requires that the function marked cpu_dispatch be an empty definition. This patch supports that as well, however declarations are also permitted, since the linker will solve the issue of multiple emissions. Differential Revision: https://reviews.llvm.org/D47474 llvm-svn: 337552
* Support implicit _Atomic struct load / storeJF Bastien2018-07-181-0/+1
| | | | | | | | | | | | | | | | | Summary: Using _Atomic to do implicit load / store is just a seq_cst atomic_load / atomic_store. Stores currently assert in Sema::ImpCastExprToType with 'can't implicitly cast lvalue to rvalue with this cast kind', but that's erroneous. The codegen is fine as the test shows. While investigating I found that Richard had found the problem here: https://reviews.llvm.org/D46112#1113557 <rdar://problem/40347123> Reviewers: dexonsmith Subscribers: cfe-commits, efriedma, rsmith, aaron.ballman Differential Revision: https://reviews.llvm.org/D49458 llvm-svn: 337410
* Add caching when looking up coroutine_traitsBrian Gesiak2018-07-141-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently clang looks up the coroutine_traits ClassTemplateDecl everytime it looks up the promise type. This is unnecessary as coroutine_traits doesn't change between promise type lookups. This diff caches the coroutine_traits lookup. Patch by Tanoy Sinha! Test Plan: I added log statements in the new lookupCoroutineTraits function to ensure that LookupQualifiedName was only called once even when multiple coroutines existed in the source file. Reviewers: modocache, GorNishanov Reviewed By: modocache Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D48981 llvm-svn: 337103
* [C++17] Disallow lambdas in template parameters (PR33696).Nicolas Lesser2018-07-121-1/+1
| | | | | | | | | | | | | | Summary: This revision disallows lambdas in template parameters, as reported in PR33696. Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D37442 llvm-svn: 336930
* [modules] Do not serialize / deserialize pending new/delete mismatchRichard Smith2018-06-281-10/+7
| | | | | | | | | | checks across module boundaries. This was causing us to load constructor definitions for all consumers of a module with a pending check. (In one case we saw ~7% of total frontend time spent loading constructors for this check.) llvm-svn: 335807
* [MS] Make sure __GetExceptionInfo works on types with no linkageReid Kleckner2018-06-201-0/+2
| | | | | | Fixes PR36327 llvm-svn: 335175
* [CUDA] Allow "extern __shared__ Foo foo[]" within anon. namespaces.Justin Lebar2018-05-171-0/+5
| | | | | | | | | | | | | | | Summary: Previously this triggered a -Wundefined-internal warning. But it's not an undefined variable -- any variable of this form is a pointer to the base of GPU core's shared memory. Reviewers: tra Subscribers: sanjoy, rsmith Differential Revision: https://reviews.llvm.org/D46782 llvm-svn: 332621
* [AST] Fix -ast-print for _Bool when have diagnosticsJoel E. Denny2018-05-141-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For example, given: #define bool _Bool _Bool i; void fn() { 1; } -ast-print produced: tmp.c:3:13: warning: expression result unused void fn() { 1; } ^ bool i; void fn() { 1; } That fails to compile because bool is undefined. Details: Diagnostics print _Bool as bool when the latter is defined as the former. However, diagnostics were altering the printing policy for -ast-print as well. The printed source was then invalid because the preprocessor eats the bool definition. Problematic diagnostics included suppressed warnings (e.g., add -Wno-unused-value to the above example), including those that are suppressed by default. This patch fixes this bug and cleans up some related comments. Reviewed by: aaron.ballman, rsmith Differential Revision: https://reviews.llvm.org/D45093 llvm-svn: 332275
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-091-11/+11
| | | | | | | | | | | | | | | | | | | 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
* [C++2a] Implement operator<=> CodeGen and ExprConstantEric Fiselier2018-05-071-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch tackles long hanging fruit for the builtin operator<=> expressions. It is currently needs some cleanup before landing, but I want to get some initial feedback. The main changes are: * Lookup, build, and store the required standard library types and expressions in `ASTContext`. By storing them in ASTContext we don't need to store (and duplicate) the required expressions in the BinaryOperator AST nodes. * Implement [expr.spaceship] checking, including diagnosing narrowing conversions. * Implement `ExprConstant` for builtin spaceship operators. * Implement builitin operator<=> support in `CodeGenAgg`. Initially I emitted the required comparisons using `ScalarExprEmitter::VisitBinaryOperator`, but this caused the operand expressions to be emitted once for every required cmp. * Implement [builtin.over] with modifications to support the intent of P0946R0. See the note on `BuiltinOperatorOverloadBuilder::addThreeWayArithmeticOverloads` for more information about the workaround. Reviewers: rsmith, aaron.ballman, majnemer, rnk, compnerd, rjmccall Reviewed By: rjmccall Subscribers: rjmccall, rsmith, aaron.ballman, junbuml, mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D45476 llvm-svn: 331677
* Revert r329684 (and follow-ups 329693, 329714). See discussion on ↵Nico Weber2018-04-101-22/+0
| | | | | | https://reviews.llvm.org/D43578. llvm-svn: 329739
* -ftime-report switch support in Clang.Andrew V. Tischenko2018-04-101-0/+22
| | | | | | | | | | The current support of the feature produces only 2 lines in report: -Some general Code Generation Time; -Total time of Backend Consumer actions. This patch extends Clang time report with new lines related to Preprocessor, Include Filea Search, Parsing, etc. Differential Revision: https://reviews.llvm.org/D43578 llvm-svn: 329684
* [MS] Fix late-parsed template infinite loop in eager instantiationReid Kleckner2018-03-261-0/+19
| | | | | | | | | | | | | | | | | | Summary: This fixes PR33561 and PR34185. Don't store pending template instantiations for late-parsed templates in the normal PendingInstantiations queue. Instead, use a separate list that will only be parsed and instantiated at end of TU when late template parsing actually works and doesn't infinite loop. Reviewers: rsmith, thakis, hans Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D44846 llvm-svn: 328567
* Sink PrettyDeclStackTrace down to the AST libraryJordan Rose2018-03-231-19/+1
| | | | | | | ...and add some very basic stack trace entries for module building. This would have helped track down rdar://problem/38434694 sooner. llvm-svn: 328276
* Re-land "[Sema] Make getCurFunction() return null outside function parsing"Reid Kleckner2018-03-121-19/+31
| | | | | | | | | | | | | | This relands r326965. There was a null dereference in typo correction that was triggered in Sema/diagnose_if.c. We are not always in a function scope when doing typo correction. The fix is to add a null check. LLVM's optimizer made it hard to find this bug. I wrote it up in a not-very-well-editted blog post here: http://qinsb.blogspot.com/2018/03/ub-will-delete-your-null-checks.html llvm-svn: 327334
* Revert "[Sema] Make getCurFunction() return null outside function parsing"Reid Kleckner2018-03-081-31/+19
| | | | | | | | | | This reverts r326965. It seems to have caused repeating test failures in clang/test/Sema/diagnose_if.c on some buildbots. I cannot reproduce the problem, and it's not immediately obvious what the problem is, so let's revert to green. llvm-svn: 326974
* [Sema] Make getCurFunction() return null outside function parsingReid Kleckner2018-03-081-19/+31
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Before this patch, Sema pre-allocated a FunctionScopeInfo and kept it in the first, always present element of the FunctionScopes stack. This meant that Sema::getCurFunction would return a pointer to this pre-allocated object when parsing code outside a function body. This is pretty much always a bug, so this patch moves the pre-allocated object into a separate unique_ptr. This should make bugs like PR36536 a lot more obvious. As you can see from this patch, there were a number of places that unconditionally assumed they were always called inside a function. However, there are also many places that null checked the result of getCurFunction(), so I think this is a reasonable direction. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D44039 llvm-svn: 326965
* Avoid including ScopeInfo.h from Sema.hReid Kleckner2018-03-071-0/+12
| | | | | | | | | | | | | | | | | Summary: This provides no measurable build speedup, but it reinstates an optimization from r112038 that was lost in r179618. It requires moving CapturedScopeInfo::Capture out to clang::sema, which might be too general since we have plenty of other Capture records in BlockDecl and other AST nodes. Reviewers: rjmccall Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D44221 llvm-svn: 326957
* [NFC] Move CommentOpts checks to the call sites that depend on it. ↵David L. Jones2018-03-021-2/+1
| | | | | | | | | | | | | | | | | | | | | | (Re-applying r326501.) When parsing comments, for example, for -Wdocumentation, slightly different behaviour occurs when -fparse-all-comments is specified. However, these differences are subtle: 1. All comments are saved during parsing, regardless of whether they are doc comments or not. 2. "Maybe-doc" comments, like <, !, etc, are saved as such, instead of marking them as ordinary comments. The maybe-doc type of comment is never saved otherwise. (Warning on these is the impetus of -Wdocumentation.) 3. All comments are treated as doc comments in ASTContext, even if they are ordinary. This change moves the logic for checking CommentOptions.ParseAllComments closer to where it has an effect. The overall logic is unchanged, but checks of the ParseAllComments flag are now done where the effect will be clearer. Subscribers: cfe-commits llvm-svn: 326512
* Revert r326501 due to buildbot breakage.David L. Jones2018-03-011-1/+2
| | | | | | | | | | | | | | | | | | | | Original change: [NFC] Move CommentOpts checks to the call sites that depend on it. When parsing comments, for example, for -Wdocumentation, slightly different behaviour occurs when -fparse-all-comments is specified. However, these differences are subtle: 1. All comments are saved during parsing, regardless of whether they are doc comments or not. 2. "Maybe-doc" comments, like //<, //!, etc, are saved as such, instead of marking them as ordinary comments. The maybe-doc type of comment is never saved otherwise. (Warning on these is the impetus of -Wdocumentation.) 3. All comments are treated as doc comments in ASTContext, even if they are ordinary. This change moves the logic for checking CommentOptions.ParseAllComments closer to where it has an effect. The overall logic is unchanged, but checks of the ParseAllComments flag are now done where the effect will be clearer. llvm-svn: 326508
* [NFC] Move CommentOpts checks to the call sites that depend on it.David L. Jones2018-03-011-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | When parsing comments, for example, for -Wdocumentation, slightly different behaviour occurs when -fparse-all-comments is specified. However, these differences are subtle: 1. All comments are saved during parsing, regardless of whether they are doc comments or not. 2. "Maybe-doc" comments, like //<, //!, etc, are saved as such, instead of marking them as ordinary comments. The maybe-doc type of comment is never saved otherwise. (Warning on these is the impetus of -Wdocumentation.) 3. All comments are treated as doc comments in ASTContext, even if they are ordinary. This change moves the logic for checking CommentOptions.ParseAllComments closer to where it has an effect. The overall logic is unchanged, but checks of the ParseAllComments flag are now done where the effect will be clearer. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D43663 llvm-svn: 326501
* [Templight] Template Instantiation ObserverGabor Horvath2018-02-101-0/+1
| | | | | | | | | | | | | | | | | | | | | This patch adds a base-class called TemplateInstantiationObserver which gets notified whenever a template instantiation is entered or exited during semantic analysis. This is a base class used to implement the template profiling and debugging tool called Templight (https://github.com/mikael-s-persson/templight). The patch also makes a few more changes: * ActiveTemplateInstantiation class is moved out of the Sema class (so it can be used with inclusion of Sema.h). * CreateFrontendAction function in front-end utilities is given external linkage (not longer a hidden static function). * TemplateInstObserverChain data member added to Sema class to hold the list of template-inst observers. * Notifications to the template-inst observer are added at the key places where templates are instantiated. Patch by: Abel Sinkovics! Differential Revision: https://reviews.llvm.org/D5767 llvm-svn: 324808
* Fix crash when trying to pack-expand a GNU statement expression.Richard Smith2018-02-031-2/+2
| | | | | | | | We could in principle support such pack expansion, using techniques similar to what we do for pack expansion of lambdas, but it's not clear it's worthwhile. For now at least, cleanly reject these cases rather than crashing. llvm-svn: 324160
* Implement Attribute Target MultiVersioningErich Keane2018-01-081-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | GCC's attribute 'target', in addition to being an optimization hint, also allows function multiversioning. We currently have the former implemented, this is the latter's implementation. This works by enabling functions with the same name/signature to coexist, so that they can all be emitted. Multiversion state is stored in the FunctionDecl itself, and SemaDecl manages the definitions. Note that it ends up having to permit redefinition of functions so that they can all be emitted. Additionally, all versions of the function must be emitted, so this also manages that. Note that this includes some additional rules that GCC does not, since defining something as a MultiVersion function after a usage has been made illegal. The only 'history rewriting' that happens is if a function is emitted before it has been converted to a multiversion'ed function, at which point its name needs to be changed. Function templates and virtual functions are NOT yet supported (not supported in GCC either). Additionally, constructors/destructors are disallowed, but the former is planned. llvm-svn: 322028
* Remove creation of out-of-bounds value of enumeration type (resulting in UB).Richard Smith2017-12-081-1/+1
| | | | | | | Also remove unnecessary initialization of out-parameters with this value, so that MSan is able to catch errors appropriately. llvm-svn: 320212
* Fix -Wunused-private-field to fire regardless of which implicit special ↵Richard Smith2017-11-011-1/+2
| | | | | | members have been implicitly declared. llvm-svn: 317076
* [Sema] -Wzero-as-null-pointer-constant: don't warn for system macros other ↵Roman Lebedev2017-10-261-2/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | than NULL. Summary: The warning was initially introduced in D32914 by @thakis, and the concerns were raised there, and later in rL302247 and PR33771. I do believe that it makes sense to relax the diagnostic e.g. in this case, when the expression originates from the system header, which can not be modified. This prevents adoption for the diagnostic for codebases which use pthreads (`PTHREAD_MUTEX_INITIALIZER`), gtest, etc. As @malcolm.parsons suggests, it *may* make sense to also not warn for the template types, but it is not obvious to me how to do that in here. Though, it still makes sense to complain about `NULL` macro. While there, add more tests. Reviewers: dblaikie, thakis, rsmith, rjmccall, aaron.ballman Reviewed By: thakis Subscribers: Rakete1111, hans, cfe-commits, thakis, malcolm.parsons Tags: #clang Differential Revision: https://reviews.llvm.org/D38954 llvm-svn: 316662
* Ignore implicity casts for zero-as-null-pointer-constant warningErich Keane2017-10-251-1/+1
| | | | | | | | | | The repro in https://bugs.llvm.org/show_bug.cgi?id=34362 caused the left nullptr to be cast to a int* implicitly, which resulted diagnosing this falsely. Differential Revision: https://reviews.llvm.org/D39301 llvm-svn: 316605
* [Modules TS] Diagnose missing/duplicate module-declaration.Richard Smith2017-10-111-0/+11
| | | | llvm-svn: 315397
* Implement C++ [basic.link]p8.Richard Smith2017-09-201-21/+58
| | | | | | | | | | | | | | If a function or variable has a type with no linkage (and is not extern "C"), any use of it requires a definition within the same translation unit; the idea is that it is not possible to define the entity elsewhere, so any such use is necessarily an error. There is an exception, though: some types formally have no linkage but nonetheless can be referenced from other translation units (for example, this happens to anonymous structures defined within inline functions). For entities with those types, we suppress the diagnostic except under -pedantic. llvm-svn: 313729
* Implement Itanium name mangling support for C++ Modules TS.Richard Smith2017-09-041-2/+16
| | | | | | | | | | | | 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
* Don't emit undefined-internal warnings for CXXDeductionGuideDecls.Richard Smith2017-08-031-0/+3
| | | | | | Patch by ~paul (cynecx on phabricator)! Some test massaging by me. llvm-svn: 309975
* Recommit r308327 3rd time: Add a warning for missingAlex Lorenz2017-07-281-0/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | '#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-54/+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/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | '#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-54/+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/+54
| | | | | | | | | | | | | | | | | | 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
* Don't set TUScope to null when generating a module in incremental processing ↵Raphael Isemann2017-07-181-1/+2
| | | | | | | | | | | | | | | | mode. Summary: When in incremental processing mode, we should never set `TUScope` to a nullptr otherwise any future lookups fail. We already have similar checks in the rest of the code, but we never hit this one because so far we didn't try to generate a module from the AST that Cling generates. Reviewers: rsmith, v.g.vassilev Reviewed By: v.g.vassilev Subscribers: cfe-commits, v.g.vassilev Differential Revision: https://reviews.llvm.org/D35536 llvm-svn: 308333
* Revert r308327Alex Lorenz2017-07-181-54/+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/+54
| | | | | | | | | | | | | | | | | | 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
* [modules ts] Declarations from a module interface unit are only visible outsideRichard Smith2017-07-051-0/+12
| | | | | | the module if declared in an export block. llvm-svn: 307115
* [OpenCL] Add function name to extension diagnosticJoey Gouly2017-06-301-2/+3
| | | | | | Slightly improve the diagnostic by including the function name. llvm-svn: 306827
* Prevent devirtualization of calls to un-instantiated functions.Sunil Srivastava2017-06-201-0/+3
| | | | | | | | PR 27895 Differential Revision: https://reviews.llvm.org/D22057 llvm-svn: 305862
* [modules] When creating a declaration, cache its owning module immediatelyRichard Smith2017-05-171-5/+4
| | | | | | | | | | | | | | | rather than waiting until it's queried. Currently this is only applied to local submodule visibility mode, as we don't yet allocate storage for the owning module in non-local-visibility modules compilations. This reinstates r302965, reverted in r303037, with a fix for the reported crash, which occurred when reparenting a local declaration to be a child of a hidden imported declaration (specifically during template instantiation). llvm-svn: 303224
* Revert r302965 - [modules] When creating a declaration, cache its owningDaniel Jasper2017-05-151-4/+5
| | | | | | | | | module immediately Also revert dependent r302969. This is leading to crashes. Will provide more details reproduction instructions to Richard. llvm-svn: 303037
* [modules] When creating a declaration, cache its owning module immediatelyRichard Smith2017-05-121-5/+4
| | | | | | | | | | rather than waiting until it's queried. Currently this is only applied to local submodule visibility mode, as we don't yet allocate storage for the owning module in non-local-visibility modules compilations. llvm-svn: 302965
* Reland "Warn about unused static file scope function template declarations."Vassil Vassilev2017-05-091-5/+27
| | | | | | | This patch reinstates r299930, reverted in r299956, as a separate diagnostic option (-Wunused-template). llvm-svn: 302518
* Introduce Wzero-as-null-pointer-constant.Nico Weber2017-05-051-0/+14
| | | | | | | | | Add an opt-in warning that fires when 0 is used as a null pointer. gcc has this warning, and there's some demand for it. https://reviews.llvm.org/D32914 llvm-svn: 302247
* [OPENMP] Fix handling of OpenMP code during template instantiation.Alexey Bataev2017-04-261-0/+7
| | | | | | | | | If some function template is instantiated during handling of OpenMP code, currently it may cause crash of compiler because of trying of capturing variables in non-capturing function scopes. Patch fixes this bug. llvm-svn: 301416
OpenPOWER on IntegriCloud