Apr 5 2019
A (verbose) compromise: LLVMInsertExistingBasicBlockAfterInsertBlock?
I think the names are confusing. Why not something like LLVMInsertExistingBasicBlock and LLVMAppendExistingBasicBlock?
The ObjectFile APIs seem to have rotted a bit. There's a bunch of pitfalls when working with the thing like the fact that it goes out of its way to move the input buffer despite the create APIs taking non-owning references to the buffer in C++, accessors that no longer do anything useful (LLVMGetRelocationValueString) and inconsistent error handling routines (some functions return NULL, LLVMGetSymbolName and LLVMGetSymbolName reports a fatal error). On top of that, it's not actually a general interface to ObjectFile - it can't handle Mach-O Universal binaries as inputs for one.
Remove support for Efficiency Sanitizer
Looks like ESan is dead https://reviews.llvm.org/rL355862. I'll update this patch.
@whitequark Could I get your sign off on this too?
Mar 25 2019
Mar 22 2019
Mar 21 2019
Mar 15 2019
Feb 27 2019
Feb 25 2019
Feb 17 2019
I keep a running list of the APIs we have wrapped if that helps. I would love a hand getting us all the way there https://github.com/llvm-swift/LLVMSwift/issues/131
Feb 16 2019
I concur. Looks good.
Feb 13 2019
Feb 12 2019
Feb 5 2019
Jan 25 2019
@whitequark No worries. Always glad to have your review on these things since they can be hairy at times.
Jan 20 2019
Jan 7 2019
Jan 3 2019
Jan 2 2019
Jan 1 2019
Dec 31 2018
Nov 8 2018
@whitequark I meant to comment here, I'm not sure how I wound up on that other issue. Reposting for visibility:
Nov 5 2018
Apologies for not bringing this up in the earlier patch, but is there a reason this isn't using/building on the existing DI C bindings we have?
Oct 29 2018
Oct 23 2018
The infrastructure to test this isn't yet in place. I will merge accessors for MemSetBase and MemTransferBase in a later patch then special-case the echo test to call out to these build functions with those arguments. It's not a particularly attractive plan, but it should work fine.
Oct 22 2018
Oct 1 2018
Sep 29 2018
Sep 28 2018
Abandoning this revision to keep it out of the review queue.
Sep 10 2018
The regression tests are only against the text of the driver's cc1 commands. It's not actually testing if we can compile.
@kristina They're having linker troubles because this driver is hardcoding an incorrect linker flag for libbuiltin on the arm-baremetal triple. D33259 introduced this behavior by smashing together the -lclang_rt.builtins-$ARCH flag with the proper resource-directory-relative absolute path <RESOURCE_DIR>/lib/libclang_rt.builtins-$ARCH.a which resulted in the incorrect flag -libclang_rt.builtins-$ARCH.a. With that path, the linker is going to try to look for "libclang_rt.builtins-$ARCH.a.a" in the link libraries search paths. The driver should be forming an exact path to this library relative to the resource directory. If users wish to override this behavior, they need to pass -nostdlib or -nodefaultlibs
Aug 31 2018
Aug 30 2018
How is a user of this API supposed to map the unsigned Kind values to something meaningful? We don't have an enum LLVMMetadataKind, do we?
@whitequark Could I get another once-over on the C API here?
Aug 27 2018
Aug 25 2018
Spoke with @aprantl in person about this, and we came to the conclusion that named metadata nodes are different enough that the original TODO doesn't make any sense. For one, it would mean that you could use named metadata nodes to create more kinds of cycles. It would also mean the verifier would have to be extended to reject any usage of named metadata nodes as operand metadata.