Skip to content
Snippets Groups Projects
Select Git revision
  • master default protected
1 result
Search by author
  • Any Author
  • Dr. Jorrit Fahlke Dr. Jorrit Fahlke jfahl_01
  • Jan Hönig hoenig
  • Marcel Dominique Koch marckoch
  • Martin Bauer bauermar
  • Michael Haidl m_haid02
  • Prof. Dr. Christian Engwer Prof. Dr. Christian Engwer cengw_01
  • René Heß hessr
  • Vladyslav Kucher kucher
8 authors
  1. Jun 13, 2016
  3. May 06, 2016
  5. May 05, 2016
  7. Apr 20, 2016
  9. Apr 11, 2016
    • Reid Kleckner's avatar
      Update getting started docs · 500f7868
      Reid Kleckner authored 
      compiler-rt is optional. We often get email from users with compiler-rt
build errors who don't actually need compiler-rt. Marking it optional
should help them avoid those potential problems.

While I'm here, update a reference to the build directory and remove an
obsolete reference to llvm-gcc. Nobody today is under the impression
that Clang depends on GCC.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@265963 91177308-0d34-0410-b5e6-96231b3b80d8
      500f7868
  11. Mar 28, 2016
  13. Mar 23, 2016
  15. Mar 21, 2016
    • Faisal Vali's avatar
      [Cxx1z] Implement Lambda Capture of *this by Value as [=,*this] (P0018R3) · 60783472
      Faisal Vali authored 
      Implement lambda capture of *this by copy.
For e.g.:
struct A {

  int d = 10;
  auto foo() { return [*this] (auto a) mutable { d+=a; return d; }; }

};

auto L = A{}.foo(); // A{}'s lifetime is gone.

// Below is still ok, because *this was captured by value.
assert(L(10) == 20);
assert(L(100) == 120);

If the capture was implicit, or [this] (i.e. *this was captured by reference), this code would be otherwise undefined.

Implementation Strategy:
  - amend the parser to accept *this in the lambda introducer
  - add a new king of capture LCK_StarThis
  - teach Sema::CheckCXXThisCapture to handle by copy captures of the
    enclosing object (i.e. *this)
  - when CheckCXXThisCapture does capture by copy, the corresponding 
    initializer expression for the closure's data member 
    direct-initializes it thus making a copy of '*this'.
  - in codegen, when assigning to CXXThisValue, if *this was captured by 
    copy, make sure it points to the corresponding field member, and
    not, unlike when captured by reference, what the field member points
    to.
  - mark feature as implemented in svn

Much gratitude to Richard Smith for his carefully illuminating reviews!   


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@263921 91177308-0d34-0410-b5e6-96231b3b80d8
      60783472
  17. Mar 20, 2016
  19. Mar 09, 2016
  21. Mar 08, 2016
  23. Mar 07, 2016
  25. Mar 04, 2016
  27. Feb 19, 2016
  29. Feb 18, 2016
  31. Feb 10, 2016
  33. Feb 09, 2016
  35. Feb 06, 2016
  37. Feb 01, 2016
  39. Jan 30, 2016
  41. Jan 13, 2016
  43. Dec 16, 2015
  45. Dec 10, 2015
  47. Nov 26, 2015
  49. Nov 25, 2015
  51. Nov 12, 2015
    • Richard Smith's avatar
      DR407: Rationalize how we handle tags being hidden by typedefs. Even with · 1f75bce8
      Richard Smith authored 
      DR407, the C++ standard doesn't really say how this should work. Here's what we
do (which is consistent with DR407 as far as I can tell):

 * When performing name lookup for an elaborated-type-specifier, a tag
   declaration hides a typedef declaration that names the same type.
 * When performing any other kind of lookup, a typedef declaration hides
   a tag declaration that names the same type.

In any other case where lookup finds both a typedef and a tag (that is, when
they name different types), the lookup will be ambiguous. If lookup finds a
tag and a typedef that name the same type, and finds anything else, the lookup
will always be ambiguous (even if the other entity would hide the tag, it does
not also hide the typedef).


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252959 91177308-0d34-0410-b5e6-96231b3b80d8
      1f75bce8
  53. Nov 11, 2015
    • Richard Smith's avatar
      N3922: direct-list-initialization of an auto-typed variable no longer deduces a · 1fd6dc6f
      Richard Smith authored 
      std::initializer_list<T> type. Instead, the list must contain a single element
and the type is deduced from that.

In Clang 3.7, we warned by default on all the cases that would change meaning
due to this change. In Clang 3.8, we will support only the new rules -- per
the request in N3922, this change is applied as a Defect Report against earlier
versions of the C++ standard.

This change is not entirely trivial, because for lambda init-captures we
previously did not track the difference between direct-list-initialization and
copy-list-initialization. The difference was not previously observable, because
the two forms of initialization always did the same thing (the elements of the
initializer list were always copy-initialized regardless of the initialization
style used for the init-capture).


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252688 91177308-0d34-0410-b5e6-96231b3b80d8
      1fd6dc6f