Sep 3 2020
Aug 18 2020
Rather than adding a new option, could we generalize LLVM_DISABLE_CRASH_REPORT to work on all platforms & wire that up to not --crash as you've done, without adding another name for this functionality?
Actually it looks like if we removed the Apple-specific filtering of ENABLE_CRASH_OVERRIDE, then the handling in Signals.inc which also supports the runtime API parameter "DisableCrashReporting" would also do what I was proposing for unit tests (disabling crash reporting on gtest) - which has been the default on MacOS builds for 5 years now? I'm not sure I feel perfectly good about disabling crash reporting for all unit test failures, rather than only disabling it around death tests - but I think it's probably good to make the perf tradeoffs the same on different platforms, and that this has been the default for 5 years for a good chunk of the LLVM developers (those on mac) it's probably good enough to ship.
Seems reasonable to me too.
Aug 17 2020
Mar 4 2020
Feb 10 2020
This shouldn't affect the final binary size as the linker is going to probably recreate the relocations and symbol table anyway, but seems fine to align this more in the object files.
Dec 16 2019
Nov 15 2019
Oct 29 2019
Sep 19 2019
Sep 3 2019
Aug 22 2019
Aug 7 2019
Looks like the tests are extremely comprehensive. LGTM.
Jun 5 2019
May 30 2019
I'm trusting the binary blobs are good. Phab doesn't have a built in mach-o parser :)
May 17 2019
Looks good. That’s nice to see more lines removed than added :)
Apr 24 2019
Wow. That must be a huge test case for this to be a problem!
Apr 19 2019
Mar 20 2019
Mar 9 2019
Mar 7 2019
Mar 6 2019
Feb 22 2019
Feb 11 2019
Looks like we can have print_protocol_list64_t also call the new print_protocol_64_t, but that can be done in a later NFC commit.
Jan 30 2019
LGTM. Thanks for fixing this!
Jan 22 2019
Jan 2 2019
Thanks for the review. Submitted as r350284.
Dec 21 2018
Thanks for all the feedback so far. Is there anything else you'd like me to change before I can land this?
Dec 20 2018
The ObjFW runtime itself does not contain anything about release, retain or autorelease - these are all part of ObjFW (as in the framework). As ObjFW also supports the Apple runtime, as well as mixing with Foundation code, it so far only provides objc_retain and objc_release when they are missing, to make ARC work. They just call into the corresponding methods on the object and do nothing else.
How will this change work from the Apple runtime? Will objc_retain/objc_release call the retain/release on the object if it implements its own? Should I drop my own retain/release implementation from my root object if I am compiling against the Apple runtime?
Yes, the idea is that the specialized runtime functions are fast paths for the common case, but they still fall back if the object has overridden them.
I am guessing not just overridden, but also a root class providing one? IOW, the fast path is used when the class does not have the retain or release method at all? In that case, LGTM as is.
Dec 19 2018
So, once upon a time this was a problem because we were rewriting the method calls in the runtime itself. Can you explain how that's not a problem now? Do we just expect the runtime to be compiled with the right switch?
Dec 18 2018
Dec 17 2018
You're making intrinsics with weak_external linkage? I feel like that's going to be unnecessarily awkward in the future, but okay.
Dec 7 2018
Added test for integer argument and updated code to only accept pointer types to allocWithZone.
I added the other objc* intrinsics used by ARC in r348646.
Thanks for the review. Have fixed the comments as suggested.
Dec 6 2018
Dec 5 2018
Discovered that objc_storeStrong is actually wrong in the documentation. Changing it from returning id to returning void. Will also update the docs.
Dec 4 2018
Dec 3 2018
Updated to add a comment to Intrinsics.td, remove the ReturnedValue<> and added all of the ARC methods from https://clang.llvm.org/docs/AutomaticReferenceCounting.html#runtime-support
Jul 2 2018
Sorry for the delay. LGTM.
May 31 2018
Nice catch. This LGTM.
Apr 23 2018
I don't think this is quite right. I know at least make-based incremental builds wouldn't deal well with this.
This is actually not a novel problem w.r.t. this patch. The exact same situation comes up with Makefile-included .d files and when one of the referenced headers is removed.
This is typically solved somewhere in the build system, for example Make has -include, and Ninja and llbuild have explicit support for this situation.
Of course, yes, I was wrong. Thanks for the correction.
I agree we might want to tread cautiously on how we change the .d output, but in this case I think it might be safe.
If we decide this isn't safe, then we may want to consider a new flag which tracks *all* anti-dependencies (file's for which Clang checked existence but did not exist), and include that here. The major concern with that approach is it is a much larger list, and while it would support being substantially more correct, it is also well beyond what people currently expect out of the build system + compiler generated deps approaches.
Even though this is likely safe, it seems really noisy. Consider the case where someone has __has_include(<missing>) -- we'll get an entry for every -I, -F, -isystem, and -iframework. If we're going to add that noise, I prefer a separate flag that covers all anti-dependencies.
Mar 9 2018
This all looks reasonable. Its a nice localized change to this pass. LGTM.
May 10 2017
Good catch! LGTM.
May 3 2017
This is a great improvement over what we had. LGTM.
Apr 10 2017
Sorry for forgetting to review this.
Mar 20 2017
I scrolled through fairly quickly, but everything looked fine. Looks like basically renaming and fixing formatting along the way.
Mar 13 2017
Mar 8 2017
Thanks, Pete! Will land soon, then.
I think we could support SpecificBumpPtrAllocator but it would require walking the objects by 'sizeof(T) + RedZoneSize'. RedZoneSize itself would also have to be set to make sure we continue to have appropriate alignment. Not something you need to do now, but could be interesting in future.
FWIW, this doesn't work as is because SpecificBumpPtrAllocator lets you allocate *arrays* of objects as well as single objects, and the arrays obviously can't have red zones between elements.
Good point. Never thought of that. Wouldn't be surprised if there's a whole bunch of users who never use arrays and could benefit, but still something to think about more.
Very cool. Justin and I looked at ASan on BumpPtrAllocator a while ago and I think this would have been useful then too. I think the reason you didn't find issues is that he fixed many of them already.
Sep 30 2016
Whats the behavior here in terms of implicit conversions and overloading?