Skip to content
  1. Sep 05, 2019
  3. Sep 04, 2019
  5. Sep 03, 2019
  7. Sep 02, 2019
  9. Aug 31, 2019
    • David Bolvansky's avatar
      [clang] Devirtualization for classes with destructors marked as 'final' · 20b2708c
      David Bolvansky authored 
      A class with a destructor marked final cannot be derived from, so it should afford the same devirtualization opportunities as marking the entire class final.

Patch by logan-5 (Logan Smith)
Reviewed by rsmith

Differential Revision: https://reviews.llvm.org/D66621

llvm-svn: 370597
      20b2708c
    • David Bolvansky's avatar
      [clang] Warning for non-final classes with final destructors · d533f69a
      David Bolvansky authored 
      Marking a class' destructor final prevents the class from being inherited from. However, it is a subtle and awkward way to express that at best, and unintended at worst. It may also generate worse code (in other compilers) than marking the class itself final. For these reasons, this revision adds a warning for nonfinal classes with final destructors, with a note to suggest marking the class final to silence the warning.

See https://reviews.llvm.org/D66621 for more background.

Patch by logan-5 (Logan Smith)

Differential Revision: https://reviews.llvm.org/D66711

llvm-svn: 370594
      d533f69a
    • Nandor Licker's avatar
      Revert [Clang Interpreter] Initial patch for the constexpr interpreter · a6bef738
      Nandor Licker authored 
      This reverts r370584 (git commit afcb3de1)

llvm-svn: 370588
      a6bef738
    • Nandor Licker's avatar
      [Clang Interpreter] Initial patch for the constexpr interpreter · afcb3de1
      Nandor Licker authored 
      Summary:
This patch introduces the skeleton of the constexpr interpreter,
capable of evaluating a simple constexpr functions consisting of
if statements. The interpreter is described in more detail in the
RFC. Further patches will add more features.

Reviewers: Bigcheese, jfb, rsmith

Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D64146

llvm-svn: 370584
      afcb3de1
    • Alex Lorenz's avatar
      Introduce a DirectoryEntryRef that stores both a reference and an · 0377ca64
      Alex Lorenz authored 
      accessed name to the directory entry

This commit introduces a parallel API that returns a DirectoryEntryRef
to the FileManager, similar to the parallel FileEntryRef API. All
uses will have to be update in follow-up patches. The immediate use of the new API in this
patch fixes the issue where a file manager was reused in clang-scan-deps,
but reported an different file path whenever a framework lookup was done through a symlink.

Differential Revision: https://reviews.llvm.org/D67026

llvm-svn: 370562
      0377ca64
    • Richard Smith's avatar
      [c++20] Add support for designated direct-list-initialization syntax. · ff9bf925
      Richard Smith authored 
      This completes the implementation of P0329R4.

llvm-svn: 370558
      ff9bf925
    • Thomas Lively's avatar
      [WebAssembly] Add SIMD QFMA/QFMS · d0d93170
      Thomas Lively authored 
      Summary:
Adds clang builtins and LLVM intrinsics for these experimental
instructions. They are not implemented in engines yet, but that is ok
because the user must opt into using them by calling the builtins.

Reviewers: aheejin, dschuff

Reviewed By: aheejin

Subscribers: sbc100, jgravelle-google, hiraditya, sunfish, cfe-commits, llvm-commits

Tags: #clang, #llvm

Differential Revision: https://reviews.llvm.org/D67020

llvm-svn: 370556
      d0d93170
    • Richard Smith's avatar
      [c++20] Disallow template argument deduction from a braced-init-list · 08275417
      Richard Smith authored 
      containing designators. The C++20 wording doesn't actually say what
happens in this case, but treating this as a non-deduced context seems
like the most natural behavior.

(We might want to consider deducing through array designators as an
extension in the future, but will need to be careful to deduce the array
bound properly if we do so. That's not permitted herein.)

llvm-svn: 370555
      08275417
    • Richard Smith's avatar
      [c++20] Implement semantic restrictions for C++20 designated · 5030928d
      Richard Smith authored 
      initializers.

This has some interesting interactions with our existing extensions to
support C99 designated initializers as an extension in C++. Those are
resolved as follows:

 * We continue to permit the full breadth of C99 designated initializers
   in C++, with the exception that we disallow a partial overwrite of an
   initializer with a non-trivially-destructible type. (Full overwrite
   is OK, because we won't run the first initializer at all.)

 * The C99 extensions are disallowed in SFINAE contexts and during
   overload resolution, where they could change the meaning of valid
   programs.

 * C++20 disallows reordering of initializers. We only check for that for
   the simple cases that the C++20 rules permit (designators of the form
   '.field_name =' and continue to allow reordering in other cases).
   It would be nice to improve this behavior in future.

 * All C99 designated initializer extensions produce a warning by
   default in C++20 mode. People are going to learn the C++ rules based
   on what Clang diagnoses, so it's important we diagnose these properly
   by default.

 * In C++ <= 17, we apply the C++20 rules rather than the C99 rules, and
   so still diagnose C99 extensions as described above. We continue to
   accept designated C++20-compatible initializers in C++ <= 17 silently
   by default (but naturally still reject under -pedantic-errors).

This is not a complete implementation of P0329R4. In particular, that
paper introduces new non-C99-compatible syntax { .field { init } }, and
we do not support that yet.

This is based on a previous patch by Don Hinton, though I've made
substantial changes when addressing the above interactions.

Differential Revision: https://reviews.llvm.org/D59754

llvm-svn: 370544
      5030928d
  11. Aug 30, 2019