1. 01 Feb, 2017 1 commit
    • Hans Wennborg's avatar
      Merging r293360: · ccd67298
      Hans Wennborg authored
      ------------------------------------------------------------------------
      r293360 | gbiv | 2017-01-27 18:19:40 -0800 (Fri, 27 Jan 2017) | 11 lines
      
      Change how we handle diagnose_if attributes.
      
      This patch changes how we handle argument-dependent `diagnose_if`
      attributes. In particular, we now check them in the same place that we
      check for things like passing NULL to Nonnull args, etc. This is
      basically better in every way than how we were handling them before. :)
      
      This fixes PR31638, PR31639, and PR31640.
      
      Differential Revision: https://reviews.llvm.org/D28889
      
      ------------------------------------------------------------------------
      Merging r293369:
      ------------------------------------------------------------------------
      r293369 | gbiv | 2017-01-27 20:16:32 -0800 (Fri, 27 Jan 2017) | 7 lines
      
      Attempt to unbreak buildbots.
      
      r293360 broke some ARM bots, because size_t on those targets is
      apparently `unsigned int`, not `unsigned long`. `sizeof(whatever)`
      should to give us a `size_t`, so we can just use the type of that
      instead.
      
      ------------------------------------------------------------------------
      
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_40@293784 91177308-0d34-0410-b5e6-96231b3b80d8
      ccd67298
  2. 12 Jan, 2017 1 commit
  3. 04 Jan, 2017 1 commit
  4. 23 Dec, 2016 1 commit
  5. 21 Dec, 2016 1 commit
  6. 20 Dec, 2016 3 commits
  7. 19 Dec, 2016 2 commits
  8. 15 Dec, 2016 1 commit
  9. 13 Dec, 2016 1 commit
    • Reid Kleckner's avatar
      __uuidof() and declspec(uuid("...")) should be allowed on enumeration types · 14f4b9d4
      Reid Kleckner authored
      Although not specifically mentioned in the documentation, MSVC accepts
      __uuidof(…) and declspec(uuid("…")) attributes on enumeration types in
      addition to structs/classes. This is meaningful, as such types *do* have
      associated UUIDs in ActiveX typelibs, and such attributes are included
      by default in the wrappers generated by their #import construct, so they
      are not particularly unusual.
      
      clang currently rejects the declspec with a –Wignored-attributes
      warning, and errors on __uuidof() with “cannot call operator __uuidof on
      a type with no GUID” (because it rejected the uuid attribute, and
      therefore finds no value). This is causing problems for us while trying
      to use clang-tidy on a codebase that makes heavy use of ActiveX.
      
      I believe I have found the relevant places to add this functionality,
      this patch adds this case to clang’s implementation of these MS
      extensions.  patch is against r285994 (or actually the git mirror
      80464680).
      
      Both include an update to test/Parser/MicrosoftExtensions.cpp to
      exercise the new functionality.
      
      This is my first time contributing to LLVM, so if I’ve missed anything
      else needed to prepare this for review just let me know!
      
      __uuidof: https://msdn.microsoft.com/en-us/library/zaah6a61.aspx
      declspec(uuid("…")): https://msdn.microsoft.com/en-us/library/3b6wkewa.aspx
       #import: https://msdn.microsoft.com/en-us/library/8etzzkb6.aspx
      
      Reviewers: aaron.ballman, majnemer, rnk
      
      Differential Revision: https://reviews.llvm.org/D26846
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@289567 91177308-0d34-0410-b5e6-96231b3b80d8
      14f4b9d4
  10. 09 Dec, 2016 1 commit
    • Richard Smith's avatar
      DR1295 and cleanup for P0135R1: Make our initialization code more directly · b40a34de
      Richard Smith authored
      mirror the description in the standard. Per DR1295, this means that binding a
      const / rvalue reference to a bit-field no longer "binds directly", and per
      P0135R1, this means that we materialize a temporary in reference binding
      after adjusting cv-qualifiers and before performing a derived-to-base cast.
      
      In C++11 onwards, this should have fixed the last case where we would
      materialize a temporary of the wrong type (with a subobject adjustment inside
      the MaterializeTemporaryExpr instead of outside), but we still have to deal
      with that possibility in C++98, unless we want to start using xvalues to
      represent materialized temporaries there too.
      
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@289250 91177308-0d34-0410-b5e6-96231b3b80d8
      b40a34de
  11. 06 Dec, 2016 1 commit
  12. 03 Dec, 2016 1 commit
  13. 01 Dec, 2016 1 commit
  14. 27 Nov, 2016 1 commit
  15. 23 Nov, 2016 1 commit
  16. 15 Nov, 2016 1 commit
  17. 12 Nov, 2016 1 commit
  18. 11 Nov, 2016 1 commit
    • Alexey Bataev's avatar
      Fix for PR28523: unexpected compilation error. · 57621b50
      Alexey Bataev authored
      Clang emits error message for the following code:
      ```
      template <class F> void parallel_loop(F &&f) { f(0); }
      
      int main() {
        int x;
        parallel_loop([&](auto y) {
          {
            x = y;
          };
        });
      }
      ```
      
      $ clang++ --std=gnu++14 clang_test.cc -o clang_test
      clang_test.cc:9:7: error: reference to local variable 'x' declared in enclosing function 'main'
            x = y;
                  ^
      clang_test.cc:2:48: note: in instantiation of function template specialization 'main()::(anonymous class)::operator()<int>' requested here
                  template <class F> void parallel_loop(F &&f) { f(0); }
                                                                 ^
      clang_test.cc:6:3: note: in instantiation of function template specialization 'parallel_loop<(lambda at clang_test.cc:6:17)>' requested here parallel_loop([&](auto y) {
                 ^
      clang_test.cc:5:7: note: 'x' declared here
            int x;
                ^
      1 error generated.
      
      Patch fixes this issue.
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@286584 91177308-0d34-0410-b5e6-96231b3b80d8
      57621b50
  19. 22 Oct, 2016 1 commit
    • Richard Smith's avatar
      [c++1z] P0012R1: Implement a few remaining pieces: downgrade diagnostic for · bb4ce7e2
      Richard Smith authored
      mismatched dynamic exception specifications in expressions from an error to a
      warning, since this is no longer ill-formed in C++1z.
      
      Allow reference binding of a reference-to-non-noexcept function to a noexcept
      function lvalue. As defect resolutions, also allow a conditional between
      noexcept and non-noexcept function lvalues to produce a non-noexcept function
      lvalue (rather than decaying to a function pointer), and allow function
      template argument deduction to deduce a reference to non-noexcept function when
      binding to a noexcept function type.
      
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@284905 91177308-0d34-0410-b5e6-96231b3b80d8
      bb4ce7e2
  20. 21 Oct, 2016 4 commits
    • Richard Smith's avatar
      DR583, DR1512: Implement a rewrite to C++'s 'composite pointer type' rules. · 4b6ad142
      Richard Smith authored
      This has two significant effects:
      
      1) Direct relational comparisons between null pointer constants (0 and nullopt)
         and pointers are now ill-formed. This was always the case for C, and it
         appears that C++ only ever permitted by accident. For instance, cases like
           nullptr < &a
         are now rejected.
      
      2) Comparisons and conditional operators between differently-cv-qualified
         pointer types now work, and produce a composite type that both source
         pointer types can convert to (when possible). For instance, comparison
         between 'int **' and 'const int **' is now valid, and uses an intermediate
         type of 'const int *const *'.
      
      Clang previously supported #2 as an extension.
      
      We do not accept the cases in #1 as an extension. I've tested a fair amount of
      code to check that this doesn't break it, but if it turns out that someone is
      relying on this, we can easily add it back as an extension.
      
      This is a re-commit of r284800.
      
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@284890 91177308-0d34-0410-b5e6-96231b3b80d8
      4b6ad142
    • Artem Belevich's avatar
      Declare H and H new/delete. · e7cf8220
      Artem Belevich authored
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@284879 91177308-0d34-0410-b5e6-96231b3b80d8
      e7cf8220
    • Renato Golin's avatar
      Revert "DR583, DR1512: Implement a rewrite to C++'s 'composite pointer type' rules." · 3fc87cc1
      Renato Golin authored
      This reverts commit r284800, as it failed all ARM/AArch64 bots.
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@284811 91177308-0d34-0410-b5e6-96231b3b80d8
      3fc87cc1
    • Richard Smith's avatar
      DR583, DR1512: Implement a rewrite to C++'s 'composite pointer type' rules. · c1d70e9b
      Richard Smith authored
      This has two significant effects:
      
      1) Direct relational comparisons between null pointer constants (0 and nullopt)
         and pointers are now ill-formed. This was always the case for C, and it
         appears that C++ only ever permitted by accident. For instance, cases like
           nullptr < &a
         are now rejected.
      
      2) Comparisons and conditional operators between differently-cv-qualified
         pointer types now work, and produce a composite type that both source
         pointer types can convert to (when possible). For instance, comparison
         between 'int **' and 'const int **' is now valid, and uses an intermediate
         type of 'const int *const *'.
      
      Clang previously supported #2 as an extension.
      
      We do not accept the cases in #1 as an extension. I've tested a fair amount of
      code to check that this doesn't break it, but if it turns out that someone is
      relying on this, we can easily add it back as an extension.
      
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@284800 91177308-0d34-0410-b5e6-96231b3b80d8
      c1d70e9b
  21. 20 Oct, 2016 5 commits
  22. 16 Oct, 2016 1 commit
  23. 13 Oct, 2016 1 commit
    • Justin Lebar's avatar
      [CUDA] Add Sema::CUDADiagBuilder and Sema::CUDADiagIf{Device,Host}Code(). · fff8e6c7
      Justin Lebar authored
      Summary:
      Together these let you easily create diagnostics that
      
       - are never emitted for host code
       - are always emitted for __device__ and __global__ functions, and
       - are emitted for __host__ __device__ functions iff these functions are
         codegen'ed.
      
      At the moment there are only three diagnostics that need this treatment,
      but I have more to add, and it's not sustainable to write code for emitting
      every such diagnostic twice, and from a special wrapper in SemaCUDA.cpp.
      
      While we're at it, don't emit the function name in
      err_cuda_device_exceptions: It's not necessary to print it, and making
      this work in the new framework in the face of a null value for
      dyn_cast<FunctionDecl>(CurContext) isn't worth the effort.
      
      Reviewers: rnk
      
      Subscribers: cfe-commits, tra
      
      Differential Revision: https://reviews.llvm.org/D25139
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@284143 91177308-0d34-0410-b5e6-96231b3b80d8
      fff8e6c7
  24. 11 Oct, 2016 1 commit
    • Richard Smith's avatar
      Aligned allocation versus CUDA: make deallocation function preference order · 5733999b
      Richard Smith authored
      match other CUDA preference orders, per discussion with jlebar. We now model
      this in an attempt to match overload resolution as closely as possible:
      
      - First, we throw out all non-callable (due to CUDA host/device mismatch)
        operator delete functions.
      - Then we apply sizedness / alignedness preferences based on whether the type
        is overaligned and whether the deallocation function is a member.
      - Finally, we use the CUDA callability preference as a tiebreaker.
      
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@283830 91177308-0d34-0410-b5e6-96231b3b80d8
      5733999b
  25. 10 Oct, 2016 3 commits
  26. 06 Oct, 2016 1 commit
  27. 05 Oct, 2016 1 commit
    • Richard Smith's avatar
      PR22924, PR22845, some of CWG1464: When checking the initializer for an array · 76767b5a
      Richard Smith authored
      new expression, distinguish between the case of a constant and non-constant
      initializer. In the former case, if the bound is erroneous (too many
      initializer elements, bound is negative, or allocated size overflows), reject,
      and take the bound into account when determining whether we need to
      default-construct any elements. In the remanining cases, move the logic to
      check for default-constructibility of trailing elements into the initialization
      code rather than inventing a bogus array bound, to cope with cases where the
      number of initialized elements is not the same as the number of initializer
      list elements (this can happen due to string literal initialization or brace
      elision).
      
      This also fixes rejects-valid and crash-on-valid errors when initializing a
      new'd array of character type from a braced string literal.
      
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@283406 91177308-0d34-0410-b5e6-96231b3b80d8
      76767b5a
  28. 30 Sep, 2016 1 commit