- User Since
- Feb 2 2016, 10:56 AM (171 w, 6 d)
Wed, May 15
Fri, May 10
Thu, May 9
Address review comments. Also remove the special case where we wouldn't check a destructor for an array in -fno-exceptions mode. This seems inconsistent with both how we're treating -fno-exceptions in general, and inconsistent with other cases of aggregate initialization (i.e. we still check struct members here).
Mon, May 6
Duncan pointed out eel.is/c++draft/class.init#class.base.init-13, which appears to claim that initialization ends with the execution of the constructor, excluding temporary destructors.
Fri, May 3
Thu, May 2
Wed, May 1
Tue, Apr 30
Add a try/catch block to the docs.
Address review comments.
LGTM, I think this makes sense.
Fri, Apr 26
No worries! It happens, I probably should have pinged this more aggressively.
By using no_destroy, you're saying that exit-time destructor doesn't matter because the OS will either reclaim the resources automatically, or its just doesn't matter since the process is going down. I don't think that implies that we can safely ignore the destructor in the middle of the program's execution.
JF, Michael, and I were talking about this offline, and we think that the right choice of semantics for the static local case is to call the destructors.
Thu, Apr 25
Looks like @rsmith fixed this in r359266.
Huh, okay. I guess there are two separate bugs that are conspiring to crash the compiler here: we shouldn't correct a TypoExpr more than once, and we shouldn't correct a TypoExpr less than once. I think fixing one of the two is fine. FYI I think you should be able to write a testcase if you RUN it with -disable-free.
Yeah, I tend to think we should just suppress this unconditionally in Objective-C.
but don't want to annotate each unused ObjC method parameters with __attribute__((unused)) or insert (void)unused_param into the body of the method to silence the warning since, unlike C/C++ functions, it's not possible to comment out the unused parameters of ObjC methods.
Apr 19 2019
Wait, why is NumTypos incorrect here? I think its because we don't handle the typo on the line: [self undeclaredMethod:undeclaredArg];, even the following asserts now. Seems like the right fix would be to track down why we aren't handling the typo in the message expr.
Apr 17 2019
LGTM too, thanks!
Apr 15 2019
Akira and I were just talking about an alternative approach to this: Keep a vector of pairs of BlockDecls and SourceLocations in the enclosing method's FunctionScopeInfo, and emit any unsuppressed diagnostics when popping the method. This would avoid having to traverse all the blocks in methods in ARC mode, at the cost of a small amount of memory.
Apr 11 2019
Apr 10 2019
Apr 4 2019
Apr 3 2019
Apr 2 2019
Apr 1 2019
Mar 29 2019
Mar 28 2019
Ah, looks like the problem is we're sending a dependent expression to the constant evaluator, we should just bail out in that case. I'll fix this tomorrow morning, thanks for tracking this down!
Mar 26 2019
Landed in r357040. (I forgot to write Differential revision:!)
Add an assert.
Mar 22 2019
Mar 21 2019
Mar 20 2019
Mar 19 2019
Mar 18 2019
I don't understand this code at all, but what about BlockDecl?
Mar 15 2019
Address review comments.
Mar 14 2019
Mar 13 2019
Address review comments. Thanks!
I reverted this in r356103:
LGTM, after one more comment in Features.def :)
Mar 12 2019
Mar 11 2019
Feb 28 2019
Feb 27 2019
Use atomicPHI->getParent() instead of tracking the block.
Use FileCheck in the test, NFC.
Feb 25 2019
Feb 15 2019
Feb 14 2019
LGTM too, I agree this should be NFC with the parent commit.