Y’all can revert it. I’ll resubmit the patch with updated tests tomorrow.
Aug 14 2019
Aug 10 2019
Jul 26 2019
Jul 24 2019
Jul 23 2019
Jul 22 2019
Jun 14 2019
We spoke out of band about the troubles I’m having verifying this locally, but the patch looks good and my limitations shouldn’t hold it back any longer.
May 25 2019
Document the lifetime of the context parameter
Apr 24 2019
Apr 22 2019
Apr 17 2019
Apr 16 2019
@jberdine Any further comments?
@whitequark Could I get your stamp of approval as well?
This patch doesn't apply cleanly to my checkout, so I'm going to fold it into D60725.
Apr 15 2019
@jberdine This patch handles the global variable side of things. You should be able to replace those accessors in Core with a call to LLVMGlobalCopyAllMetadata. You can filter for !dbg and dig out the global variable expression. From there, you locate from global variable expression to global variable with LLVMDIGlobalVariableExpressionGetVariable and from global variable to line with LLVMDIVariableGetLine.
A DISubprogram is a kind of DIScope so you can use LLVMDIScopeGetFile and the rest of the accessors to poke at their metadata. For Global Variables, the idea should be to add corresponding accessors for the scope, file, name, source, and directory since these nodes do not store DILocations. It seems like the latter is pressing, so I'll make a patch for it in a bit.
Apr 10 2019
Add an accessor for the "inlined at" location
All this is reminding me I need to go back through and remove this header. The Go bindings do not need special treatment, and any new bindings they have need to be merged into LLVM-C
*sigh*, I'll resubmit this and nuke the ones in the Go bindings then.
Apr 9 2019
Retarget from DIScope to DIFile since we can retrieve the file object for a scope now.
@jberdine Are these bindings missing anything for your current use-case? I want to make sure you're covered before I deprecate them.
Add documentation to LLVMSetInstDebugLocation
@whitequark Could you give it one more look. Had to fix a corner-case.
+@phosek Who seems to be the last significant contributor to this file.
The ELF section and symbol iterators can produce error values which turn into NULL underlying data in the iterators. Propagate this out as a NULL returned iterator.
Correctly handle the NULL location
Correct a typo in the header
My concern is that we’re building parallel API hierarchies here. The old hat way of wrapping metadata nodes in a value and casting out to an LLVMValueRef makes no sense if we have APIs to manipulate metadata more directly.
Apr 8 2019
Apr 7 2019
Apr 6 2019
Apr 5 2019
Rename LLVMBinaryGetMemoryBuffer to LLVMBinaryCopyMemoryBuffer to better convey ownership semantics. Update the docs.
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