- User Since
- Jun 8 2016, 8:07 PM (162 w, 2 d)
Jun 18 2019
LGTM! Thank you for the fix.
Jun 17 2019
LGTM! Thank you for fixing it.
Jun 16 2019
May 30 2019
LGTM! Thank you for the fix
May 13 2019
May 3 2019
LGTM! Thank you for doing the fix.
What is the original source that synthesized allocas with count?
Mar 15 2019
Mar 7 2019
LGTM with a tiny suggestion
Jan 9 2019
Dec 26 2018
Creating copies for a scalar that is used in operator new and in the body of the function is a sound strategy.
Notice that if we replace int x parameter to Int x with the following int like class:
Dec 11 2018
small test tweak. Preparing to land
Dec 10 2018
Implemented review feedback (and fix the test that missed the bug discovered by CR)
Dec 5 2018
Dec 3 2018
Dec 2 2018
Dec 1 2018
Nov 30 2018
Nov 13 2018
Nov 3 2018
Oct 1 2018
LGTM! Thank you for doing this.
Aug 29 2018
With a few suggestions.
Jul 3 2018
Jun 23 2018
LGTM with some suggestions.
May 28 2018
May 10 2018
May 3 2018
May 2 2018
Looks good. Make sure to run the tests in release and debug mode.
On my box, these three test failed in release mode.
May 1 2018
Apr 26 2018
Thank you for doing this, Lewis.
Apr 25 2018
Thank you for doing this. It looks very elegant, but, it is a little bit wrong. It creates two different initial_suspend objects.
Run this example:
Apr 13 2018
Apr 4 2018
- s/_LIBCPP_ALWAYS_INLINE/_LIBCPP_INLINE_VISIBILITY throughout <experimental/coroutine>
- Added _LIBCPP_INLINE_VISIBILITY to noop_coroutine constructor
- static_cast instead of reintrepret_cast in promise()
- 2 spaces indent in added code (the rest of the file stayed as is)
- added static_assert to check for done-ness and capacity
- constexpr => _LIBCPP_CONSTEXPR
- noexcept => _NOEXCEPT
Apr 3 2018
This got fixed with:
incorporated review feedback
Put out an updated version of this patch in
@EricWF , gentle ping. Super tini-tiny change. Last piece missing to be post-Jax 2018 compilant
Apr 2 2018
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@328993 91177308-0d34-0410-b5e6-96231b3b80d8
Mar 31 2018
added a test that verifies lowering of llvm.coro.noop
Mar 30 2018
I believe that this check is too aggressive. It prevents http://godbolt.org/g/26viuZ from optimizing as well.
I think a distinction should be made for exceptional paths and happy path.
We need to make sure that we call coro.destroy on all happy paths.
LGTM with some stylistic suggestions