summaryrefslogtreecommitdiffstats
path: root/clang/test/Sema
Commit message (Collapse)AuthorAgeFilesLines
...
* [DeclPrinter] Fix two cases that crash clang -ast-print.Artem Belevich2018-01-171-0/+4
| | | | | | | | | | | | | Both are related to handling anonymous structures. * clang didn't handle () around an anonymous struct variable. * clang also crashed on syntax errors that could lead to other syntactic constructs following the declaration of an anonymous struct. While the code is invalid, that's not a good reason to panic compiler. Differential Revision: https://reviews.llvm.org/D41788 llvm-svn: 322742
* Revert 319303: Add _Float128 as alias to __float128 to enable compilations ↵Erich Keane2018-01-151-22/+0
| | | | | | | | on Fedora27/glibc2 Differential Revision: https://reviews.llvm.org/D40673 llvm-svn: 322518
* [X86][Sema] Range check the constant argument for the vpshld/vpshrd builtins ↵Craig Topper2018-01-111-0/+76
| | | | | | to ensure it fits in 8-bits. llvm-svn: 322247
* Implement Attribute Target MultiVersioningErich Keane2018-01-082-0/+113
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix a couple of wrong self-comparison diagnostics.Richard Smith2018-01-071-0/+5
| | | | | | | | Check whether we are comparing the same entity, not merely the same declaration, and don't assume that weak declarations resolve to distinct entities. llvm-svn: 321976
* Factor out common tautological comparison code from scalar and vector ↵Richard Smith2018-01-071-6/+6
| | | | | | | | compare checking. In passing, improve vector compare diagnostic to match scalar compare diagnostic. llvm-svn: 321972
* Add support for a limited subset of TS 18661-3 math builtins.Benjamin Kramer2018-01-061-4/+21
| | | | | | | | | | | | | | | | | These just overloads for _Float128. They're supported by GCC 7 and used by glibc. APFloat support is already there so just add the overloads. __builtin_copysignf128 __builtin_fabsf128 __builtin_huge_valf128 __builtin_inff128 __builtin_nanf128 __builtin_nansf128 This is the same support that GCC has, according to the documentation, but limited to _Float128. llvm-svn: 321948
* Fix TLS support check for Darwin 32-bit simulator targets.Volodymyr Sapsai2018-01-051-0/+6
| | | | | | | | | | | | | | | | | Also instead of checking architecture explicitly, use recently added "simulator" environment in the triple. rdar://problem/35083787 Reviewers: arphaman, bob.wilson Reviewed By: arphaman Subscribers: gparker42, cfe-commits Differential Revision: https://reviews.llvm.org/D41750 llvm-svn: 321890
* Introduce some infrastructure for adding C attributes with [[]] syntax.Aaron Ballman2018-01-031-1/+5
| | | | | | | | This patch adds support to the attribute tablegen for specifying a [[]] attribute is allowed in C mode. This patch also adds the annotate attribute to the list of double square bracket attributes we support in C mode. Eventually, I anticipate that this logic will be reversed (you have to opt out of allowing an attribute in C rather than opting in), but I want to see how the design plays out as more attributes are considered. llvm-svn: 321763
* [Sema] -Wtautological-constant-compare is too good. Cripple it.Roman Lebedev2018-01-036-41/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The diagnostic was mostly introduced in D38101 by me, as a reaction to wasting a lot of time, see [[ https://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20171009/206427.html | mail ]]. However, the diagnostic is pretty dumb. While it works with no false-positives, there are some questionable cases that are diagnosed when one would argue that they should not be. The common complaint is that it diagnoses the comparisons between an `int` and `long` when compiling for a 32-bit target as tautological, but not when compiling for 64-bit targets. The underlying problem is obvious: data model. In most cases, 64-bit target is `LP64` (`int` is 32-bit, `long` and pointer are 64-bit), and the 32-bit target is `ILP32` (`int`, `long`, and pointer are 32-bit). I.e. the common pattern is: (pseudocode) ``` #include <limits> #include <cstdint> int main() { using T1 = long; using T2 = int; T1 r; if (r < std::numeric_limits<T2>::min()) {} if (r > std::numeric_limits<T2>::max()) {} } ``` As an example, D39149 was trying to fix this diagnostic in libc++, and it was not well-received. This *could* be "fixed", by changing the diagnostics logic to something like `if the types of the values being compared are different, but are of the same size, then do diagnose`, and i even attempted to do so in D39462, but as @rjmccall rightfully commented, that implementation is incomplete to say the least. So to stop causing trouble, and avoid contaminating upcoming release, lets do this workaround: * move these three diags (`warn_unsigned_always_true_comparison`, `warn_unsigned_enum_always_true_comparison`, `warn_tautological_constant_compare`) into it's own `-Wtautological-constant-in-range-compare` * Disable them by default * Make them part of `-Wextra` * Additionally, give `warn_tautological_constant_compare` it's own flag `-Wtautological-type-limit-compare`. I'm not happy about that name, but i can't come up with anything better. This way all three of them can be enabled/disabled either altogether, or one-by-one. Reviewers: aaron.ballman, rsmith, smeenai, rjmccall, rnk, mclow.lists, dim Reviewed By: aaron.ballman, rsmith, dim Subscribers: thakis, compnerd, mehdi_amini, dim, hans, cfe-commits, rjmccall Tags: #clang Differential Revision: https://reviews.llvm.org/D41512 llvm-svn: 321691
* [Sema] Don't emit the -Wstrict-prototypes warning for variadic functions.Volodymyr Sapsai2018-01-021-0/+6
| | | | | | | | | | | | | | rdar://problem/33251668 Reviewers: arphaman, ahatanak Reviewed By: arphaman Subscribers: ptitei, cfe-commits Differential Revision: https://reviews.llvm.org/D41528 llvm-svn: 321660
* Revert "[CodeGen] Fix crash when a function taking transparent union is ↵Volodymyr Sapsai2017-12-211-29/+0
| | | | | | | | | | | | redeclared." This reverts commit r321296. It caused performance regressions FAIL: imp.execution_time FAIL: 2007-01-04-KNR-Args.execution_time FAIL: sse_expandfft.execution_time FAIL: sse_stepfft.execution_time llvm-svn: 321306
* [CodeGen] Fix crash when a function taking transparent union is redeclared.Volodymyr Sapsai2017-12-211-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a function taking transparent union is declared as taking one of union members earlier in the translation unit, clang would hit an "Invalid cast" assertion during EmitFunctionProlog. This case corresponds to function f1 in test/CodeGen/transparent-union-redecl.c. We decided to cast i32 to union because after merging function declarations function parameter type becomes int, CGFunctionInfo::ArgInfo type matches with ABIArgInfo type, so we decide it is a trivial case. But these types should also be castable to parameter declaration type which is not the case here. The fix is in checking for the trivial case if ABIArgInfo type matches with parameter declaration type. It exposed inconsistency that we check hasScalarEvaluationKind for different types in EmitParmDecl and EmitFunctionProlog, and comment says they should match. Additional tests in Sema/transparent-union.c capture current behavior and make sure there are no regressions. rdar://problem/34949329 Reviewers: rjmccall, rafael Reviewed By: rjmccall Subscribers: aemerson, cfe-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D41311 llvm-svn: 321296
* Fix an assertion failure regression in isDesignatorAtObjectEnd forAlex Lorenz2017-12-201-0/+19
| | | | | | | | | | | | | | __builtin_object_size with incomplete array type in struct The commit r316245 introduced a regression that causes an assertion failure when Clang tries to cast an IncompleteArrayType to a PointerType when evaluating __builtin_object_size. rdar://36094951 Differential Revision: https://reviews.llvm.org/D41405 llvm-svn: 321222
* Add support for ObjectFormat to TargetSpecificAttrErich Keane2017-12-201-1/+1
| | | | | | | | | | | | | | | | Looking through the code, I saw a FIXME on IFunc to switch it to a target specific attribute. In looking through it, i saw that the no-longer-appropriately-named TargetArch didn't support ObjectFormat checking. This patch changes the name of TargetArch to TargetSpecific (since it checks much more than just Arch), makes "Arch" optional, adds support for ObjectFormat, better documents the TargetSpecific type, and changes IFunc over to a TargetSpecificAttr. Differential Revision: https://reviews.llvm.org/D41303 llvm-svn: 321201
* [VerifyDiagnosticConsumer] support -verify=<prefixes>Hal Finkel2017-12-163-510/+58
| | | | | | | | | | | | | | | | | | | | This mimics FileCheck's --check-prefixes option. The default prefix is "expected". That is, "-verify" is equivalent to "-verify=expected". The goal is to permit exercising a single test suite source file with different compiler options producing different sets of diagnostics. While cpp can be combined with the existing -verify to accomplish the same goal, source is often easier to maintain when it's not cluttered with preprocessor directives or duplicate passages of code. For example, this patch also rewrites some existing clang tests to demonstrate the benefit of this feature. Patch by Joel E. Denny, thanks! Differential Revision: https://reviews.llvm.org/D39694 llvm-svn: 320908
* [ThreadSafetyAnalysis] Fix isCapabilityExprYi Kong2017-12-141-0/+17
| | | | | | | | | | | | There are many more expr types that can be a capability expr, like CXXThisExpr, CallExpr, MemberExpr. Instead of enumerating all of them, just check typeHasCapability for any type given. Also add & and * operators to allowed unary operators. Differential Revision: https://reviews.llvm.org/D41224 llvm-svn: 320753
* Unify implementation of our two different flavours of -Wtautological-compare,Richard Smith2017-12-082-98/+156
| | | | | | | | | | | | | | | | | | | | | | | | | and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
* Revert "Unify implementation of our two different flavours of ↵Hans Wennborg2017-12-082-138/+98
| | | | | | | | | | | | | | | | | | | | | | | | | | -Wtautological-compare." > Unify implementation of our two different flavours of -Wtautological-compare. > > In so doing, fix a handful of remaining bugs where we would report false > positives or false negatives if we promote a signed value to an unsigned type > for the comparison. This caused a new warning in Chromium: ../../base/trace_event/trace_log.cc:1545:29: error: comparison of constant 64 with expression of type 'unsigned int' is always true [-Werror,-Wtautological-constant-out-of-range-compare] DCHECK(handle.event_index < TraceBufferChunk::kTraceBufferChunkSize); ~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The 'unsigned int' is really a 6-bit bitfield, which is why it's always less than 64. I thought we didn't use to warn (with out-of-range-compare) when comparing against the boundaries of a type? llvm-svn: 320162
* Unify implementation of our two different flavours of -Wtautological-compare.Richard Smith2017-12-082-98/+138
| | | | | | | | In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. llvm-svn: 320122
* [ARM] ACLE parallel arithmetic and DSP style multiplicationsSjoerd Meijer2017-12-071-0/+184
| | | | | | | | | | | This is a follow up of r302131, in which we forgot to add SemaChecking tests. Adding these tests revealed two problems which have been fixed: - added missing intrinsic __qdbl, - properly range checking ssat16 and usat16. Differential Revision: https://reviews.llvm.org/D40888 llvm-svn: 320019
* Fix a bunch of wrong "tautological unsigned enum compare" diagnostics in C++.Richard Smith2017-12-061-24/+29
| | | | | | | An enumeration with a fixed underlying type can have any value in its underlying type, not just those spanned by the values of its enumerators. llvm-svn: 319875
* Add _Float128 as alias to __float128 to enable compilations on ↵Erich Keane2017-12-041-0/+22
| | | | | | | | | | | | | | | | | Fedora27/glibc2-26 Fedora27 is using a new version of glibc that refers to the _Float128 type. This patch adds that name as an alias to float128. I also added some predefined macro values for the digits, mantissa, epilon, etc (FloatMacros). For the test case, I copied an existing float128 test. This functionality needs work long term, but it should be sufficient to tread water for a while. At Intel we have test servers running our LLVM compiler with various open source workloads, the server has been upgraded to Fedora27 so many workloads are failing due to _Float128. Patch-By: mibintc Differential Revision: https://reviews.llvm.org/D40673 llvm-svn: 319703
* Disallow a cleanup attribute from appertaining to a parameter (the attribute ↵Aaron Ballman2017-12-011-4/+6
| | | | | | only appertains to local variables and is silently a noop on parameters). This repurposes the unused (and syntactically incorrect) NormalVar attribute subject. llvm-svn: 319555
* Remove duplicate, nonsense information from an attribute diagnostic. The ↵Aaron Ballman2017-12-011-1/+1
| | | | | | NonParmVar subject does not need to mention functions, and the resulting diagnostic definitely does not need to mention functions twice. llvm-svn: 319549
* Perform a bounds check on a function's argument list before accessing any ↵Aaron Ballman2017-11-291-0/+23
| | | | | | | | index value specified by an 'argument_with_type_tag' attribute. Fixes PR28520. Patch by Matt Davis. llvm-svn: 319383
* Determine the attribute subject for diagnostics based on declarative ↵Aaron Ballman2017-11-2621-36/+36
| | | | | | | | | | information in DeclNodes.td. This greatly reduces the number of enumerated values used for more complex diagnostics; these are now only required when the "attribute only applies to" diagnostic needs to be generated manually as part of semantic processing. This also clarifies some terminology used by the diagnostic (methods -> Objective-C methods, fields -> non-static data members, etc). Many of the tests needed to be updated in multiple places for the diagnostic wording tweaks. The first instance of the diagnostic for that attribute is fully specified and subsequent instances cut off the complete list (to make it easier if additional subjects are added in the future for the attribute). llvm-svn: 319002
* PR35214: don't crash if we see an array of unknown bound added to an empty ↵Richard Smith2017-11-151-0/+8
| | | | | | but invalid designator. llvm-svn: 318258
* Clarify the error message for unsupported aliases on DarwinAlex Lorenz2017-11-071-4/+1
| | | | | | rdar://35109556 llvm-svn: 317532
* [Sema] Document+test the -Wsign-conversion change for enums in C code [NFC]Roman Lebedev2017-11-041-0/+13
| | | | | | | | | | | | Basically a regression after r316268. However the diagnostic is correct, but the test coverage is bad. So just like rL316500, introduce yet more tests, and adjust the release notes. See https://bugs.llvm.org/show_bug.cgi?id=35200 llvm-svn: 317421
* [Sema] Document+test the -Wsign-compare change for enums in C code [NFC]Roman Lebedev2017-10-241-0/+24
| | | | | | | | | | | | | | | | | | rL316268 / D39122 has fixed PR35009, and now when in C, these three(?) diagnostics properly use the enum's underlying datatype. While it was fixed, the test coverage was clearly insufficient, because the -Wsign-compare change didn't show up in any of the tests, until it was reported in the post-commit mail for rL316268. So add the test for the -Wsign-compare diagnostic for enum for C code, and while there, document this in the release notes. The fix itself was obviously correct, so unless we want to silence this new diagnosed case, i deem this commit to be NFC. llvm-svn: 316500
* [Sema] Add support for flexible array members in Obj-C.Volodymyr Sapsai2017-10-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow Obj-C ivars with incomplete array type but only as the last ivar. Also add a requirement for ivars that contain a flexible array member to be at the end of class too. It is possible to add in a subclass another ivar at the end but we'll emit a warning in this case. Also we'll emit a warning if a variable sized ivar is declared in class extension or in implementation because subclasses won't know they should avoid adding new ivars. In ARC incomplete array objects are treated as __unsafe_unretained so require them to be marked as such. Prohibit synthesizing ivars with flexible array members because order of synthesized ivars is not obvious and tricky to control. Spelling out ivar explicitly gives control to developers and helps to avoid surprises with unexpected ivar ordering. For C and C++ changed diagnostic to tell explicitly a field is not the last one and point to the next field. It is not as useful as in Obj-C but it is an improvement and it is consistent with Obj-C. For C for unions emit more specific err_flexible_array_union instead of generic err_field_incomplete. rdar://problem/21054495 Reviewers: rjmccall, theraven Reviewed By: rjmccall Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D38773 llvm-svn: 316381
* [Sema] Fixes for enum handling for tautological comparison diagnosticsRoman Lebedev2017-10-214-50/+1211
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: As Mattias Eriksson has reported in PR35009, in C, for enums, the underlying type should be used when checking for the tautological comparison, unlike C++, where the enumerator values define the value range. So if not in CPlusPlus mode, use the enum underlying type. Also, i have discovered a problem (a crash) when evaluating tautological-ness of the following comparison: ``` enum A { A_a = 0 }; if (a < 0) // expected-warning {{comparison of unsigned enum expression < 0 is always false}} return 0; ``` This affects both the C and C++, but after the first fix, only C++ code was affected. That was also fixed, while preserving (i think?) the proper diagnostic output. And while there, attempt to enhance the test coverage. Yes, some tests got moved around, sorry about that :) Fixes PR35009 Reviewers: aaron.ballman, rsmith, rjmccall Reviewed By: aaron.ballman Subscribers: Rakete1111, efriedma, materi, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D39122 llvm-svn: 316268
* Enable support for the [[maybe_unused]] attribute from WG14 N2053 when ↵Aaron Ballman2017-10-182-0/+47
| | | | | | enabling double square bracket attributes in C code. llvm-svn: 316096
* Silencing a redefinition warning that was not germane to the test.Aaron Ballman2017-10-181-3/+3
| | | | llvm-svn: 316086
* Enable support for the [[fallthrough]] attribute from WG14 N2052 when ↵Aaron Ballman2017-10-181-0/+75
| | | | | | enabling double square bracket attributes in C code. llvm-svn: 316083
* Fix PR34981, a crash-on-invalid merging dllimport to an invalid redecl.Nico Weber2017-10-171-1/+6
| | | | | | This is basically like r288207, just the other way round. llvm-svn: 316032
* Enable support for the [[nodiscard]] attribute from WG14 N2050 when enabling ↵Aaron Ballman2017-10-171-0/+49
| | | | | | double square bracket attributes in C code. llvm-svn: 316026
* [OpenCL] Restrict swizzle length check to OpenCL modeBruno Cardoso Lopes2017-10-171-0/+10
| | | | | | | | | | | Changes behavior introduced in r298369 to only error out on vector component invalid length access on OpenCL mode. Differential Revision: https://reviews.llvm.org/D38868 rdar://problem/33568748 llvm-svn: 316016
* [Sema] Re-land: Diagnose tautological comparison with type's min/max valuesRoman Lebedev2017-10-153-186/+864
| | | | | | | | | | | | | | | | | | | | | | | | | The first attempt, rL315614 was reverted because one libcxx test broke, and i did not know at the time how to deal with it. Summary: Currently, clang only diagnoses completely out-of-range comparisons (e.g. `char` and constant `300`), and comparisons of unsigned and `0`. But gcc also does diagnose the comparisons with the `std::numeric_limits<>::max()` / `std::numeric_limits<>::min()` so to speak Finally Fixes https://bugs.llvm.org/show_bug.cgi?id=34147 Continuation of https://reviews.llvm.org/D37565 Reviewers: rjmccall, rsmith, aaron.ballman Reviewed By: rsmith Subscribers: rtrieu, jroelofs, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D38101 llvm-svn: 315875
* Add -f[no-]double-square-bracket-attributes as new driver options to control ↵Aaron Ballman2017-10-151-0/+54
| | | | | | use of [[]] attributes in all language modes. This is the initial implementation of WG14 N2165, which is a proposal to add [[]] attributes to C2x, but also allows you to enable these attributes in C++98, or disable them in C++11 or later. llvm-svn: 315856
* Revert "[Sema] Diagnose tautological comparison with type's min/max values"Roman Lebedev2017-10-123-864/+186
| | | | | | | | | | | | | | | | | | | | | This reverts r315614,r315615,r315621,r315622 Breaks http://bb9.pgr.jp/#/builders/20/builds/59 /home/bb9/bootstrap-clang-libcxx-lld-i686-linux/llvm-project/libcxx/test/std/experimental/filesystem/fs.op.funcs/fs.op.last_write_time/last_write_time.pass.cpp:95:17: error: comparison 'long long' > 9223372036854775807 is always false [-Werror,-Wtautological-constant-compare] if (max_sec > Lim::max()) return false; ~~~~~~~ ^ ~~~~~~~~~~ /home/bb9/bootstrap-clang-libcxx-lld-i686-linux/llvm-project/libcxx/test/std/experimental/filesystem/fs.op.funcs/fs.op.last_write_time/last_write_time.pass.cpp:124:13: error: comparison 'long long' < -9223372036854775808 is always false [-Werror,-Wtautological-constant-compare] if (sec < Lim::min() || sec > Lim::max()) return false; ~~~ ^ ~~~~~~~~~~ /home/bb9/bootstrap-clang-libcxx-lld-i686-linux/llvm-project/libcxx/test/std/experimental/filesystem/fs.op.funcs/fs.op.last_write_time/last_write_time.pass.cpp:124:33: error: comparison 'long long' > 9223372036854775807 is always false [-Werror,-Wtautological-constant-compare] if (sec < Lim::min() || sec > Lim::max()) return false; ~~~ ^ ~~~~~~~~~~ 3 errors generated. -- I'm not yet sure what is the proper fix. llvm-svn: 315631
* [Sema] Diagnose tautological comparison with type's min/max valuesRoman Lebedev2017-10-123-186/+864
| | | | | | | | | | | | | | | | | | | | | | Summary: Currently, clang only diagnoses completely out-of-range comparisons (e.g. `char` and constant `300`), and comparisons of unsigned and `0`. But gcc also does diagnose the comparisons with the `std::numeric_limits<>::max()` / `std::numeric_limits<>::min()` so to speak Finally Fixes https://bugs.llvm.org/show_bug.cgi?id=34147 Continuation of https://reviews.llvm.org/D37565 Reviewers: rjmccall, rsmith, aaron.ballman Reviewed By: rsmith Subscribers: rtrieu, jroelofs, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D38101 llvm-svn: 315614
* Driver: hoist the `wchar_t` handling to the driverSaleem Abdulrasool2017-10-061-1/+1
| | | | | | | | | | | | | | | | Move the logic for determining the `wchar_t` type information into the driver. Rather than passing the single bit of information of `-fshort-wchar` indicate to the frontend the desired type of `wchar_t` through a new `-cc1` option of `-fwchar-type` and indicate the signedness through `-f{,no-}signed-wchar`. This replicates the current logic which was spread throughout Basic into the `RenderCharacterOptions`. Most of the changes to the tests are to ensure that the frontend uses the correct type. Add a new test set under `test/Driver/wchar_t.c` to ensure that we calculate the proper types for the various cases. llvm-svn: 315126
* -Wdocumentation should allow '...' params in variadic function type aliasesAlex Lorenz2017-10-062-0/+33
| | | | | | rdar://34811344 llvm-svn: 315103
* Fix 'section' warning behavior with tentatively-defined valuesErich Keane2017-10-041-0/+9
| | | | | | | | | As reported on cfe-commits, r314262 resulted in tentatively-defined variables not being excluded for the warning. Patch By: Elizabeth Andrews llvm-svn: 314939
* PR34822: Fix a collection of related bugs with our handling of C89 implicit ↵Richard Smith2017-10-042-4/+15
| | | | | | | | | | | | | | | | | function declarations. We were injecting the function into the wrong semantic context, resulting in it failing to be registered as a global for redeclaration lookup. As a consequence, we accepted invalid code since r310616. Fixing that resulted in the "out-of-scope declaration" diagnostic firing a lot more often. It turned out that warning codepath was non-conforming, because it did not cause us to inject the implicitly-declared function into the enclosing block scope. We now only warn if the type of the out-of-scope declaration doesn't match the type of an implicitly-declared function; in all other cases, we produce the normal warning for an implicitly-declared function. llvm-svn: 314871
* Suppress -Wmissing-braces warning when aggregate-initializing a struct with ↵Richard Smith2017-10-031-2/+5
| | | | | | | | | | a single field that is itself an aggregate. In C++, such initialization of std::array<T, N> types is guaranteed to work by the standard, is completely idiomatic, and the "suggested" alternative from Clang was technically invalid. llvm-svn: 314838
* [Sema] Suppress warnings for C's zero initializerDaniel Marjamaki2017-09-291-0/+38
| | | | | | | | Patch by S. Gilles! Differential Revision: https://reviews.llvm.org/D28148 llvm-svn: 314499
* [clang] Add getUnsignedPointerDiffType methodAlexander Shaposhnikov2017-09-281-0/+30
| | | | | | | | | | | | | | | | | C11 standard refers to the unsigned counterpart of the type ptrdiff_t in the paragraph 7.21.6.1p7 where it defines the format specifier %tu. In Clang (in PrintfFormatString.cpp, lines 508-510) there is a FIXME for this case, in particular, Clang didn't diagnose %tu issues at all, i.e. it didn't emit any warnings on the code printf("%tu", 3.14). In this diff we add a method getUnsignedPointerDiffType for getting the corresponding type similarly to how it's already done in the other analogous cases (size_t, ssize_t, ptrdiff_t etc) and fix -Wformat diagnostics for %tu plus the emitted fix-it as well. Test plan: make check-all Differential revision: https://reviews.llvm.org/D38270 llvm-svn: 314470
OpenPOWER on IntegriCloud