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. 23 Jan, 2017 1 commit
  3. 09 Jan, 2017 3 commits
  4. 07 Jan, 2017 1 commit
    • Richard Smith's avatar
      PR23135: Don't instantiate constexpr functions referenced in unevaluated operands where possible. · 8ea4b564
      Richard Smith authored
      This implements something like the current direction of DR1581: we use a narrow
      syntactic check to determine the set of places where a constant expression
      could be evaluated, and only instantiate a constexpr function or variable if
      it's referenced in one of those contexts, or is odr-used.
      
      It's not yet clear whether this is the right set of syntactic locations; we
      currently consider all contexts within templates that would result in odr-uses
      after instantiation, and contexts within list-initialization (narrowing
      conversions take another victim...), as requiring instantiation. We could in
      principle restrict the former cases more (only const integral / reference
      variable initializers, and contexts in which a constant expression is required,
      perhaps). However, this is sufficient to allow us to accept libstdc++ code,
      which relies on GCC's behavior (which appears to be somewhat similar to this
      approach).
      
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291318 91177308-0d34-0410-b5e6-96231b3b80d8
      8ea4b564
  5. 06 Jan, 2017 1 commit
    • Richard Smith's avatar
      Revisit PR10177: don't instantiate a variable if it's only referenced in a · 26313ca6
      Richard Smith authored
      dependent context and can't be used in a constant expression.
      
      Per C++ [temp.inst]p2, "the instantiation of a static data member does not
      occur unless the static data member is used in a way that requires the
      definition to exist".
      
      This doesn't /quite/ match that, as we still instantiate static data members
      that are usable in constant expressions even if the use doesn't require a
      definition. A followup patch will fix that for both variables and functions.
      
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291295 91177308-0d34-0410-b5e6-96231b3b80d8
      26313ca6
  6. 04 Jan, 2017 1 commit
  7. 23 Dec, 2016 1 commit
  8. 20 Dec, 2016 2 commits
  9. 18 Dec, 2016 1 commit
  10. 16 Dec, 2016 2 commits
  11. 14 Dec, 2016 1 commit
  12. 13 Dec, 2016 1 commit
  13. 05 Dec, 2016 1 commit
    • Richard Smith's avatar
      DR1213: element access on an array xvalue or prvalue produces an xvalue. In the · 88800602
      Richard Smith authored
      latter case, a temporary array object is materialized, and can be
      lifetime-extended by binding a reference to the member access. Likewise, in an
      array-to-pointer decay, an rvalue array is materialized before being converted
      into a pointer.
      
      This caused IR generation to stop treating file-scope array compound literals
      as having static storage duration in some cases in C++; that has been rectified
      by modeling such a compound literal as an lvalue. This also improves clang's
      compatibility with GCC for those cases.
      
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@288654 91177308-0d34-0410-b5e6-96231b3b80d8
      88800602
  14. 03 Dec, 2016 1 commit
  15. 02 Dec, 2016 2 commits
  16. 23 Nov, 2016 1 commit
  17. 19 Nov, 2016 1 commit
  18. 14 Nov, 2016 2 commits
  19. 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
  20. 03 Nov, 2016 1 commit
  21. 31 Oct, 2016 1 commit
    • John McCall's avatar
      A compound literal within a global lambda or block is still within · 2a210ccd
      John McCall authored
      the body of a function for the purposes of computing its storage
      duration and deciding whether its initializer must be constant.
      
      There are a number of problems in our current treatment of compound
      literals.  C specifies that a compound literal yields an l-value
      referring to an object with either static or automatic storage
      duration, depending on where it was written; in the latter case,
      the literal object has a lifetime tied to the enclosing scope (much
      like an ObjC block), not the enclosing full-expression.  To get these
      semantics fully correct in our current design, we would need to
      collect compound literals on the ExprWithCleanups, just like we do
      with ObjC blocks; we would probably also want to identify literals
      like we do with materialized temporaries.  But it gets stranger;
      GCC adds compound literals to C++ as an extension, but makes them
      r-values, which are generally assumed to have temporary storage
      duration.  Ignoring destructor ordering, the difference only matters
      if the object's address escapes the full-expression, which for an
      r-value can only happen with reference binding (which extends
      temporaries) or array-to-pointer decay (which does not).  GCC then
      attempts to lock down on array-to-pointer decay in ad hoc ways.
      Arguably a far superior language solution for C++ (and perhaps even
      array r-values in C, which can occur in other ways) would be to
      propagate lifetime extension through array-to-pointer decay, so
      that initializing a pointer object to a decayed r-value array
      extends the lifetime of the complete object containing the array.
      But this would be a major change in semantics which arguably ought
      to be blessed by the committee(s).
      
      Anyway, I'm not fixing any of that in this patch; I did try, but
      it got out of hand.
      
      Fixes rdar://28949016.
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@285643 91177308-0d34-0410-b5e6-96231b3b80d8
      2a210ccd
  22. 27 Oct, 2016 1 commit
  23. 25 Oct, 2016 1 commit
  24. 24 Oct, 2016 1 commit
  25. 21 Oct, 2016 3 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
    • 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
  26. 19 Oct, 2016 1 commit
  27. 18 Oct, 2016 2 commits
  28. 16 Oct, 2016 1 commit
  29. 14 Oct, 2016 2 commits
  30. 08 Oct, 2016 1 commit
    • Justin Lebar's avatar
      [CUDA] Do a better job at detecting wrong-side calls. · 14cbb5ee
      Justin Lebar authored
      Summary:
      Move CheckCUDACall from ActOnCallExpr and BuildDeclRefExpr to
      DiagnoseUseOfDecl.  This lets us catch some edge cases we were missing,
      specifically around class operators.
      
      This necessitates a few other changes:
      
       - Avoid emitting duplicate deferred diags in CheckCUDACall.
      
         Previously we'd carefully placed our call to CheckCUDACall such that
         it would only ever run once for a particular callsite.  But now this
         isn't the case.
      
       - Emit deferred diagnostics from a template
         specialization/instantiation's primary template, in addition to from
         the specialization/instantiation itself.  DiagnoseUseOfDecl ends up
         putting the deferred diagnostics on the template, rather than the
         specialization, so we need to check both.
      
      Reviewers: rsmith
      
      Subscribers: cfe-commits, tra
      
      Differential Revision: https://reviews.llvm.org/D24573
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@283637 91177308-0d34-0410-b5e6-96231b3b80d8
      14cbb5ee