summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema
Commit message (Collapse)AuthorAgeFilesLines
...
* Emit ASM input in a constant contextBill Wendling2018-12-181-8/+8
| | | | | | | | | | | | | | | | | Summary: Some ASM input constraints (e.g., "i" and "n") require immediate values. At O0, very few code transformations are performed. So if we cannot resolve to an immediate when emitting the ASM input we shouldn't delay its processing. Reviewers: rsmith, efriedma Reviewed By: efriedma Subscribers: rehana, efriedma, craig.topper, jyknight, cfe-commits Differential Revision: https://reviews.llvm.org/D55616 llvm-svn: 349561
* [OPENMP] parsing and sema support for 'close' map-type-modifierKelvin Li2018-12-182-17/+42
| | | | | | | | | | | | A map clause with the close map-type-modifier is a hint to prefer that the variables are mapped using a copy into faster memory. Patch by Ahsan Saghir (saghir) Differential Revision: https://reviews.llvm.org/D55719 llvm-svn: 349551
* Emit -Wformat properly for bit-field promotions.Aaron Ballman2018-12-181-4/+28
| | | | | | | | Only explicitly look through integer and floating-point promotion where the result type is actually a promotion, which is not always the case for bit-fields in C. Patch by Bevin Hansson. llvm-svn: 349497
* Automatic variable initializationJF Bastien2018-12-181-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Add an option to initialize automatic variables with either a pattern or with zeroes. The default is still that automatic variables are uninitialized. Also add attributes to request uninitialized on a per-variable basis, mainly to disable initialization of large stack arrays when deemed too expensive. This isn't meant to change the semantics of C and C++. Rather, it's meant to be a last-resort when programmers inadvertently have some undefined behavior in their code. This patch aims to make undefined behavior hurt less, which security-minded people will be very happy about. Notably, this means that there's no inadvertent information leak when: - The compiler re-uses stack slots, and a value is used uninitialized. - The compiler re-uses a register, and a value is used uninitialized. - Stack structs / arrays / unions with padding are copied. This patch only addresses stack and register information leaks. There's many more infoleaks that we could address, and much more undefined behavior that could be tamed. Let's keep this patch focused, and I'm happy to address related issues elsewhere. To keep the patch simple, only some `undef` is removed for now, see `replaceUndef`. The padding-related infoleaks are therefore not all gone yet. This will be addressed in a follow-up, mainly because addressing padding-related leaks should be a stand-alone option which is implied by variable initialization. There are three options when it comes to automatic variable initialization: 0. Uninitialized This is C and C++'s default. It's not changing. Depending on code generation, a programmer who runs into undefined behavior by using an uninialized automatic variable may observe any previous value (including program secrets), or any value which the compiler saw fit to materialize on the stack or in a register (this could be to synthesize an immediate, to refer to code or data locations, to generate cookies, etc). 1. Pattern initialization This is the recommended initialization approach. Pattern initialization's goal is to initialize automatic variables with values which will likely transform logic bugs into crashes down the line, are easily recognizable in a crash dump, without being values which programmers can rely on for useful program semantics. At the same time, pattern initialization tries to generate code which will optimize well. You'll find the following details in `patternFor`: - Integers are initialized with repeated 0xAA bytes (infinite scream). - Vectors of integers are also initialized with infinite scream. - Pointers are initialized with infinite scream on 64-bit platforms because it's an unmappable pointer value on architectures I'm aware of. Pointers are initialize to 0x000000AA (small scream) on 32-bit platforms because 32-bit platforms don't consistently offer unmappable pages. When they do it's usually the zero page. As people try this out, I expect that we'll want to allow different platforms to customize this, let's do so later. - Vectors of pointers are initialized the same way pointers are. - Floating point values and vectors are initialized with a negative quiet NaN with repeated 0xFF payload (e.g. 0xffffffff and 0xffffffffffffffff). NaNs are nice (here, anways) because they propagate on arithmetic, making it more likely that entire computations become NaN when a single uninitialized value sneaks in. - Arrays are initialized to their homogeneous elements' initialization value, repeated. Stack-based Variable-Length Arrays (VLAs) are runtime-initialized to the allocated size (no effort is made for negative size, but zero-sized VLAs are untouched even if technically undefined). - Structs are initialized to their heterogeneous element's initialization values. Zero-size structs are initialized as 0xAA since they're allocated a single byte. - Unions are initialized using the initialization for the largest member of the union. Expect the values used for pattern initialization to change over time, as we refine heuristics (both for performance and security). The goal is truly to avoid injecting semantics into undefined behavior, and we should be comfortable changing these values when there's a worthwhile point in doing so. Why so much infinite scream? Repeated byte patterns tend to be easy to synthesize on most architectures, and otherwise memset is usually very efficient. For values which aren't entirely repeated byte patterns, LLVM will often generate code which does memset + a few stores. 2. Zero initialization Zero initialize all values. This has the unfortunate side-effect of providing semantics to otherwise undefined behavior, programs therefore might start to rely on this behavior, and that's sad. However, some programmers believe that pattern initialization is too expensive for them, and data might show that they're right. The only way to make these programmers wrong is to offer zero-initialization as an option, figure out where they are right, and optimize the compiler into submission. Until the compiler provides acceptable performance for all security-minded code, zero initialization is a useful (if blunt) tool. I've been asked for a fourth initialization option: user-provided byte value. This might be useful, and can easily be added later. Why is an out-of band initialization mecanism desired? We could instead use -Wuninitialized! Indeed we could, but then we're forcing the programmer to provide semantics for something which doesn't actually have any (it's uninitialized!). It's then unclear whether `int derp = 0;` lends meaning to `0`, or whether it's just there to shut that warning up. It's also way easier to use a compiler flag than it is to manually and intelligently initialize all values in a program. Why not just rely on static analysis? Because it cannot reason about all dynamic code paths effectively, and it has false positives. It's a great tool, could get even better, but it's simply incapable of catching all uses of uninitialized values. Why not just rely on memory sanitizer? Because it's not universally available, has a 3x performance cost, and shouldn't be deployed in production. Again, it's a great tool, it'll find the dynamic uses of uninitialized variables that your test coverage hits, but it won't find the ones that you encounter in production. What's the performance like? Not too bad! Previous publications [0] have cited 2.7 to 4.5% averages. We've commmitted a few patches over the last few months to address specific regressions, both in code size and performance. In all cases, the optimizations are generally useful, but variable initialization benefits from them a lot more than regular code does. We've got a handful of other optimizations in mind, but the code is in good enough shape and has found enough latent issues that it's a good time to get the change reviewed, checked in, and have others kick the tires. We'll continue reducing overheads as we try this out on diverse codebases. Is it a good idea? Security-minded folks think so, and apparently so does the Microsoft Visual Studio team [1] who say "Between 2017 and mid 2018, this feature would have killed 49 MSRC cases that involved uninitialized struct data leaking across a trust boundary. It would have also mitigated a number of bugs involving uninitialized struct data being used directly.". They seem to use pure zero initialization, and claim to have taken the overheads down to within noise. Don't just trust Microsoft though, here's another relevant person asking for this [2]. It's been proposed for GCC [3] and LLVM [4] before. What are the caveats? A few! - Variables declared in unreachable code, and used later, aren't initialized. This goto, Duff's device, other objectionable uses of switch. This should instead be a hard-error in any serious codebase. - Volatile stack variables are still weird. That's pre-existing, it's really the language's fault and this patch keeps it weird. We should deprecate volatile [5]. - As noted above, padding isn't fully handled yet. I don't think these caveats make the patch untenable because they can be addressed separately. Should this be on by default? Maybe, in some circumstances. It's a conversation we can have when we've tried it out sufficiently, and we're confident that we've eliminated enough of the overheads that most codebases would want to opt-in. Let's keep our precious undefined behavior until that point in time. How do I use it: 1. On the command-line: -ftrivial-auto-var-init=uninitialized (the default) -ftrivial-auto-var-init=pattern -ftrivial-auto-var-init=zero -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang 2. Using an attribute: int dont_initialize_me __attribute((uninitialized)); [0]: https://users.elis.ugent.be/~jsartor/researchDocs/OOPSLA2011Zero-submit.pdf [1]: https://twitter.com/JosephBialek/status/1062774315098112001 [2]: https://outflux.net/slides/2018/lss/danger.pdf [3]: https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00615.html [4]: https://github.com/AndroidHardeningArchive/platform_external_clang/commit/776a0955ef6686d23a82d2e6a3cbd4a6a882c31c [5]: http://wg21.link/p1152 I've also posted an RFC to cfe-dev: http://lists.llvm.org/pipermail/cfe-dev/2018-November/060172.html <rdar://problem/39131435> Reviewers: pcc, kcc, rsmith Subscribers: JDevlieghere, jkorous, dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D54604 llvm-svn: 349442
* Fix ms-layout_version declspec test and add missing new testReid Kleckner2018-12-171-6/+6
| | | | | | | | | | Now that MSVC compatibility versions are stored as a four digit number (1912) instead of a two digit number (19), we need to adjust how we handle this attribute. Also add a new test that was intended to be part of r349414. llvm-svn: 349415
* Update Microsoft name mangling scheme for exception specifiers in the type ↵Reid Kleckner2018-12-171-0/+5
| | | | | | | | | | | | | | | | | | | | | system Summary: The msvc exception specifier for noexcept function types has changed from the prior default of "Z" to "_E" if the function cannot throw when compiling with /std:C++17. Patch by Zachary Henkel! Reviewers: zturner, rnk Reviewed By: rnk Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D55685 llvm-svn: 349414
* Fix "enumeral mismatch in conditional expression" gcc7 warning. NFCI.Simon Pilgrim2018-12-171-3/+4
| | | | llvm-svn: 349343
* Fix "enumeral mismatch in conditional expression" gcc7 warnings. NFCI.Simon Pilgrim2018-12-172-20/+21
| | | | llvm-svn: 349342
* [MinGW] Produce a vtable and RTTI for dllexported classes without a key functionMartin Storsjo2018-12-151-0/+3
| | | | | | | | | | | | | | This matches what GCC does in these situations. This fixes compiling Qt in debug mode. In release mode, references to the vtable of this particular class ends up optimized away, but in debug mode, the compiler creates references to the vtable, which is expected to be dllexported from a different DLL. Make sure the dllexported version actually ends up emitted. Differential Revision: https://reviews.llvm.org/D55698 llvm-svn: 349256
* Revert "Add extension to always default-initialize nullptr_t."Erich Keane2018-12-141-7/+0
| | | | | | | | | This reverts commit 46efdf2ccc2a80aefebf8433dbf9c7c959f6e629. Richard Smith commented just after I submitted this that this is the wrong solution. Reverting so that I can fix differently. llvm-svn: 349206
* Add extension to always default-initialize nullptr_t.Erich Keane2018-12-141-0/+7
| | | | | | | | | | | | | | | | | Core issue 1013 suggests that having an uninitialied std::nullptr_t be UB is a bit foolish, since there is only a single valid value. This DR reports that DR616 fixes it, which does so by making lvalue-to-rvalue conversions from nullptr_t be equal to nullptr. However, just implementing that results in warnings/etc in many places. In order to fix all situations where nullptr_t would seem uninitialized, this patch instead (as an otherwise transparent extension) default initializes uninitialized VarDecls of nullptr_t. Differential Revision: https://reviews.llvm.org/D53713 Change-Id: I84d72a9290054fa55341e8cbdac43c8e7f25b885 llvm-svn: 349201
* [Clang] Add __builtin_launderEric Fiselier2018-12-141-0/+62
| | | | | | | | | | | | | | | | | Summary: This patch adds `__builtin_launder`, which is required to implement `std::launder`. Additionally GCC provides `__builtin_launder`, so thing brings Clang in-line with GCC. I'm not exactly sure what magic `__builtin_launder` requires, but based on previous discussions this patch applies a `@llvm.invariant.group.barrier`. As noted in previous discussions, this may not be enough to correctly handle vtables. Reviewers: rnk, majnemer, rsmith Reviewed By: rsmith Subscribers: kristina, Romain-Geissler-1A, erichkeane, amharc, jroelofs, cfe-commits, Prazek Differential Revision: https://reviews.llvm.org/D40218 llvm-svn: 349195
* Revert "Make -Wstring-plus-int warns even if when the result is not out of ↵Adam Nemet2018-12-141-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | bounds" This reverts commit r349054. It's causing: FAILED: tools/clang/bindings/python/tests/CMakeFiles/check-clang-python FAIL: test_diagnostic_range (tests.cindex.test_diagnostics.TestDiagnostics) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/tools/clang/bindings/python/tests/cindex/test_diagnostics.py", line 55, in test_diagnostic_range self.assertEqual(len(tu.diagnostics), 1) AssertionError: 2 != 1 ====================================================================== FAIL: test_diagnostic_warning (tests.cindex.test_diagnostics.TestDiagnostics) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/tools/clang/bindings/python/tests/cindex/test_diagnostics.py", line 18, in test_diagnostic_warning self.assertEqual(len(tu.diagnostics), 2) AssertionError: 1 != 2 llvm-svn: 349117
* [CodeComplete] Temporarily disable failing assertionIlya Biryukov2018-12-131-1/+2
| | | | | | | | | Found the case in the clang codebase where the assertion fires. To avoid crashing assertion-enabled builds before I re-add the missing operation. Will restore the assertion alongside the upcoming fix. llvm-svn: 349061
* Make -Wstring-plus-int warns even if when the result is not out of boundsSylvestre Ledru2018-12-131-10/+0
| | | | | | | | | | | | | | Summary: Patch by Arnaud Bienner Reviewers: sylvestre.ledru, thakis Reviewed By: thakis Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D55382 llvm-svn: 349054
* [CodeComplete] Fill preferred type on binary expressionsIlya Biryukov2018-12-131-3/+80
| | | | | | | | | | | | Reviewers: kadircet Reviewed By: kadircet Subscribers: arphaman, cfe-commits Differential Revision: https://reviews.llvm.org/D55648 llvm-svn: 349053
* [CodeComplete] Set preferred type to bool on conditionsIlya Biryukov2018-12-132-4/+9
| | | | | | | | | | | | Reviewers: kadircet Reviewed By: kadircet Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D55431 llvm-svn: 349050
* [OpenCL] Add generic AS to 'this' pointerMikael Nilsson2018-12-1313-63/+98
| | | | | | | | | | | | | Address spaces are cast into generic before invoking the constructor. Added support for a trailing Qualifiers object in FunctionProtoType. Note: This recommits the previously reverted patch, but now it is commited together with a fix for lldb. Differential Revision: https://reviews.llvm.org/D54862 llvm-svn: 349019
* [AST] Store "UsesADL" information in CallExpr.Eric Fiselier2018-12-122-42/+44
| | | | | | | | | | | | | | | | | | | | | Summary: Currently the Clang AST doesn't store information about how the callee of a CallExpr was found. Specifically if it was found using ADL. However, this information is invaluable to tooling. Consider a tool which renames usages of a function. If the originally CallExpr was formed using ADL, then the tooling may need to additionally qualify the replacement. Without information about how the callee was found, the tooling is left scratching it's head. Additionally, we want to be able to match ADL calls as quickly as possible, which means avoiding computing the answer on the fly. This patch changes `CallExpr` to store whether it's callee was found using ADL. It does not change the size of any AST nodes. Reviewers: fowles, rsmith, klimek, shafik Reviewed By: rsmith Subscribers: aaron.ballman, riccibruno, calabrese, titus, cfe-commits Differential Revision: https://reviews.llvm.org/D55534 llvm-svn: 348977
* Remove TODO leftover from my devleopment branchErich Keane2018-12-121-1/+0
| | | | | | | Accidentially checked in a TODO line from r348899. This removes it. Change-Id: I74b59c0ecfe147af8a08dd7fd10893a4ca351d6d llvm-svn: 348932
* Revert "[OpenCL] Add generic AS to 'this' pointer"Mikael Nilsson2018-12-1213-98/+63
| | | | | | Reverting because the patch broke lldb. llvm-svn: 348931
* [OpenCL] Add generic AS to 'this' pointerMikael Nilsson2018-12-1213-63/+98
| | | | | | | | | | Address spaces are cast into generic before invoking the constructor. Added support for a trailing Qualifiers object in FunctionProtoType. Differential Revision: https://reviews.llvm.org/D54862 llvm-svn: 348927
* Replace Const-Member checking with non-recursive version.Erich Keane2018-12-111-20/+29
| | | | | | | | | | | | | | As reported in PR39946, these two implementations cause stack overflows to occur when a type recursively contains itself. While this only happens when an incomplete version of itself is used by membership (and thus an otherwise invalid program), the crashes might be surprising. The solution here is to replace the recursive implementation with one that uses a std::vector as a queue. Old values are kept around to prevent re-checking already checked types. Change-Id: I582bb27147104763d7daefcfee39d91f408b9fa8 llvm-svn: 348899
* Revert r348889; it fails some tests.Aaron Ballman2018-12-111-22/+4
| | | | | | http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/40784 llvm-svn: 348892
* Emit -Wformat properly for bit-field promotions.Aaron Ballman2018-12-111-4/+22
| | | | | | Only explicitly look through integer and floating-point promotion where the result type is actually a promotion, which is not always the case for bit-fields in C. llvm-svn: 348889
* Pass PartialOverloading argument to the correct corresponding parameterEric Fiselier2018-12-111-5/+7
| | | | llvm-svn: 348864
* Reland r348741 "[Sema] Further improvements to to static_assert diagnostics."Clement Courbet2018-12-112-34/+40
| | | | | | Fix a dangling reference to temporary, never return nullptr. llvm-svn: 348834
* Revert r348830 "[Sema]improve static_assert(!expr)"Clement Courbet2018-12-111-14/+0
| | | | | | Submitted the wrong change. llvm-svn: 348831
* [Sema]improve static_assert(!expr)Clement Courbet2018-12-111-0/+14
| | | | llvm-svn: 348830
* [constexpr][c++2a] Try-catch blocks in constexpr functionsBruno Cardoso Lopes2018-12-101-14/+49
| | | | | | | | | | | | | | | | | | | | | | Implement support for try-catch blocks in constexpr functions, as proposed in http://wg21.link/P1002 and voted in San Diego for c++20. The idea is that we can still never throw inside constexpr, so the catch block is never entered. A try-catch block like this: try { f(); } catch (...) { } is then morally equivalent to just { f(); } Same idea should apply for function/constructor try blocks. rdar://problem/45530773 Differential Revision: https://reviews.llvm.org/D55097 llvm-svn: 348789
* Use zip_longest for iterator range comparisons. NFC.Michael Kruse2018-12-101-10/+13
| | | | | | | | | | | | | | | | | | | Use zip_longest in two locations that compare iterator ranges. zip_longest allows the iteration using a range-based for-loop and to be symmetric over both ranges instead of prioritizing one over the other. In that latter case code have to handle the case that the first is longer than the second, the second is longer than the first, and both are of the same length, which must partially be checked after the loop. With zip_longest, this becomes an element comparison within the loop like the comparison of the elements themselves. The symmetry makes it clearer that neither the first and second iterators are handled differently. The iterators are not event used directly anymore, just the ranges. Differential Revision: https://reviews.llvm.org/D55468 llvm-svn: 348762
* Misc typos fixes in ./lib folderRaphael Isemann2018-12-107-12/+12
| | | | | | | | | | | | | | Summary: Found via `codespell -q 3 -I ../clang-whitelist.txt -L uint,importd,crasher,gonna,cant,ue,ons,orign,ned` Reviewers: teemperor Reviewed By: teemperor Subscribers: teemperor, jholewinski, jvesely, nhaehnle, whisperity, jfb, cfe-commits Differential Revision: https://reviews.llvm.org/D55475 llvm-svn: 348755
* Revert r348741 "[Sema] Further improvements to to static_assert diagnostics."Clement Courbet2018-12-102-42/+38
| | | | | | Seems to break build bots. llvm-svn: 348742
* [Sema] Further improvements to to static_assert diagnostics.Clement Courbet2018-12-102-38/+42
| | | | | | | | | | | | | | Summary: We're now handling cases like `static_assert(!expr)` and static_assert(!(expr))`. Reviewers: aaron.ballman, Quuxplusone Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D55270 llvm-svn: 348741
* [CodeComplete] Fix assertion failureIlya Biryukov2018-12-071-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: ...that fires when running completion inside an argument of UnresolvedMemberExpr (see the added test). The assertion that fires is from Sema::TryObjectArgumentInitialization: assert(FromClassification.isLValue()); This happens because Sema::AddFunctionCandidates does not account for object types which are pointers. It ends up classifying them incorrectly. All usages of the function outside code completion are used to run overload resolution for operators. In those cases the object type being passed is always a non-pointer type, so it's not surprising the function did not expect a pointer in the object argument. However, code completion reuses the same function and calls it with the object argument coming from UnresolvedMemberExpr, which can be a pointer if the member expr is an arrow ('->') access. Extending AddFunctionCandidates to allow pointer object types does not seem too crazy since all the functions down the call chain can properly handle pointer object types if we properly classify the object argument as an l-value, i.e. the classification of the implicitly dereferenced pointer. Reviewers: kadircet Reviewed By: kadircet Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D55331 llvm-svn: 348590
* [attributes] Add an attribute os_consumes_this, with similar semantics to ↵George Karpenkov2018-12-061-0/+3
| | | | | | | | | | | ns_consumes_self The attribute specifies that the call of the C++ method consumes a reference to "this". Differential Revision: https://reviews.llvm.org/D55155 llvm-svn: 348532
* Diagnose friend function template redefinitions.Serge Pavlov2018-12-062-1/+26
| | | | | | | | | | | | | | Friend function template defined in a class template becomes available if the enclosing class template is instantiated. Until the function template is used, it does not have a body, but still is considered a definition for the purpose of redeclaration checks. This change modifies redefinition check so that it can find the friend function template definitions in instantiated classes. Differential Revision: http://reviews.llvm.org/D21508 llvm-svn: 348473
* [Sema/Attribute] Check for noderef attributeLeonard Chan2018-12-064-7/+199
| | | | | | | | | | This patch adds the noderef attribute in clang and checks for dereferences of types that have this attribute. This attribute is currently used by sparse and would like to be ported to clang. Differential Revision: https://reviews.llvm.org/D49511 llvm-svn: 348442
* [Sema] Push and Pop Expression Evaluation Context Records at the start and ↵Leonard Chan2018-12-063-5/+30
| | | | | | | | | | | | end of function definitions This patch creates a new context for every function definition we enter. Currently we do not push and pop on these, usually working off of the global context record added in the Sema constructor, which never gets popped. Differential Revision: https://reviews.llvm.org/D54014 llvm-svn: 348434
* [Hexagon] Add intrinsics for Hexagon V66Krzysztof Parzyszek2018-12-051-735/+747
| | | | llvm-svn: 348419
* Do not check for parameters shadowing fields in function declarations.Aaron Ballman2018-12-052-7/+12
| | | | | | We would issue a false-positive diagnostic for parameters in function declarations shadowing fields; we now only issue the diagnostic on a function definition instead. llvm-svn: 348400
* [CodeComplete] Fix a crash in access checks of inner classesIlya Biryukov2018-12-052-12/+31
| | | | | | | | | | | | | | Summary: The crash was introduced in r348135. Reviewers: kadircet Reviewed By: kadircet Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D55260 llvm-svn: 348387
* [OpenCL] Diagnose conflicting address spaces in templates.Anastasia Stulova2018-12-052-16/+29
| | | | | | | | | | | | | Added new diagnostic when templates are instantiated with different address space from the one provided in its definition. This also prevents deducing generic address space in pointer type of templates to allow giving them concrete address space during instantiation. Differential Revision: https://reviews.llvm.org/D55127 llvm-svn: 348382
* Fix crash if an in-class explicit function specialization has explicitRichard Smith2018-12-041-10/+12
| | | | | | template arguments referring to template paramaeters. llvm-svn: 348313
* [WIP][Sema] Improve static_assert diagnostics for type traits.Clement Courbet2018-12-041-1/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In our codebase, `static_assert(std::some_type_trait<Ts...>::value, "msg")` (where `some_type_trait` is an std type_trait and `Ts...` is the appropriate template parameters) account for 11.2% of the `static_assert`s. In these cases, the `Ts` are typically not spelled out explicitly, e.g. `static_assert(std::is_same<SomeT::TypeT, typename SomeDependentT::value_type>::value, "message");` The diagnostic when the assert fails is typically not very useful, e.g. `static_assert failed due to requirement 'std::is_same<SomeT::TypeT, typename SomeDependentT::value_type>::value' "message"` This change makes the diagnostic spell out the types explicitly , e.g. `static_assert failed due to requirement 'std::is_same<int, float>::value' "message"` See tests for more examples. After this is submitted, I intend to handle `static_assert(!std::some_type_trait<Ts...>::value, "msg")`, which is another 6.6% of static_asserts. Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D54903 llvm-svn: 348239
* [Sema] Provide -fvisibility-global-new-delete-hidden optionPetr Hosek2018-12-041-3/+4
| | | | | | | | | | | | | | | | | | | | | | | When the global new and delete operators aren't declared, Clang provides and implicit declaration, but this declaration currently always uses the default visibility. This is a problem when the C++ library itself is being built with non-default visibility because the implicit declaration will force the new and delete operators to have the default visibility unlike the rest of the library. The existing workaround is to use assembly to enforce the visiblity: https://fuchsia.googlesource.com/zircon/+/master/system/ulib/zxcpp/new.cpp#108 but that solution is not always available, e.g. in the case of of libFuzzer which is using an internal version of libc++ that's also built with -fvisibility=hidden where the existing behavior is causing issues. This change introduces a new option -fvisibility-global-new-delete-hidden which makes the implicit declaration of the global new and delete operators hidden. Differential Revision: https://reviews.llvm.org/D53787 llvm-svn: 348234
* Fix -Wmismatched-tags to not warn on redeclarations of structs in systemRichard Smith2018-12-041-46/+76
| | | | | | | | | | | | | | | | | | | | | | | | headers. Previously, we would only check whether the new declaration is in a system header, but that requires the user to be able to correctly guess whether a declaration in a system header is declared as a struct or a class when specializing standard library traits templates. We now entirely ignore declarations for which the warning was disabled when determining whether to warn on a tag mismatch. Also extend the diagnostic message to clarify that a) code containing such a tag mismatch is in fact valid and correct, and b) the (non-coding-style) reason to emit such a warning is that the Microsoft C++ ABI is broken and includes the tag kind in decorated names, as it seems a lot of users are confused by our diagnostic here (either not understanding why we produce it, or believing that it represents an actual language rule). llvm-svn: 348233
* [AST][Sema] Remove CallExpr::setNumArgsBruno Ricci2018-12-032-41/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CallExpr::setNumArgs is the only thing that prevents storing the arguments in a trailing array. There is only 3 places in Sema where setNumArgs is called. D54900 dealt with one of them. This patch remove the other two calls to setNumArgs in ConvertArgumentsForCall. To do this we do the following changes: 1.) Replace the first call to setNumArgs by an assertion since we are moving the responsability to allocate enough space for the arguments from Sema::ConvertArgumentsForCall to its callers (which are Sema::BuildCallToMemberFunction, and Sema::BuildResolvedCallExpr). 2.) Add a new member function CallExpr::shrinkNumArgs, which can only be used to drop arguments and then replace the second call to setNumArgs by shrinkNumArgs. 3.) Add a new defaulted parameter MinNumArgs to CallExpr and its derived classes which specifies a minimum number of argument slots to allocate. The actual number of arguments slots allocated will be max(number of args, MinNumArgs) with the extra args nulled. Note that after the creation of the call expression all of the arguments will be non-null. It is just during the creation of the call expression that some of the last arguments can be temporarily null, until filled by default arguments. 4.) Update Sema::BuildCallToMemberFunction by passing the number of parameters in the function prototype to the constructor of CXXMemberCallExpr. Here the change is pretty straightforward. 5.) Update Sema::BuildResolvedCallExpr. Here the change is more complicated since the type-checking for the function type was done after the creation of the call expression. We need to move this before the creation of the call expression, and then pass the number of parameters in the function prototype (if any) to the constructor of the call expression. 6.) Update the deserialization of CallExpr and its derived classes. Differential Revision: https://reviews.llvm.org/D54902 Reviewed By: aaron.ballman llvm-svn: 348145
* [OpenCL][Sema] Improving formattingMarco Antognini2018-12-031-3/+2
| | | | | | | Reformat comment added in r348120 following review https://reviews.llvm.org/D55136. llvm-svn: 348139
* [CodeComplete] Cleanup access checking in code completionIlya Biryukov2018-12-033-40/+63
| | | | | | | | | | | | | | Summary: Also fixes a crash (see the added 'accessibility-crash.cpp' test). Reviewers: ioeric, kadircet Reviewed By: kadircet Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D55124 llvm-svn: 348135
OpenPOWER on IntegriCloud