- User Since
- Jan 21 2013, 11:58 AM (399 w, 3 d)
Fri, Aug 28
Looks overall reasonable to me, but it's been years since I touched that code or used an environment involving it, so someone else would have to sign off on it.
Jul 1 2020
Thank you for making this change. IIRC I introduced -fuse-ld= out of frustration with the inability to change the linker path in any way other than with a shell script on PATH. It was not a good design.
Apr 11 2020
I am no longer maintaining the C API.
Apr 10 2020
Mar 10 2020
@aykevl No. I'm no longer maintaining any LLVM bindings. I suggest you step up and discuss becoming a maintainer of the Go bindings on the mailing list.
Feb 25 2020
Jan 4 2020
Looks good now.
Dec 27 2019
Dec 15 2019
Nov 27 2019
@kren1 Do you have any objections to my suggestion of adding LLVMLinkInModule2? I think that's the only remaining issue to address.
Oct 11 2019
Would it be too strange to include such patches here?
LGTM. I did not get a notification for this before for some reason.
@whitequark, with this diff's approach of creating a hierarchy of types to mirror the LLVM-C DI types, is it acceptable to add the types and functions incrementally? That is, could we land this diff and add other types and functions later?
Oct 7 2019
@CodaFi Could you please comment on the current state of the patch?
Sep 21 2019
Sep 16 2019
Sep 2 2019
I won't be able to review this (or other patches) until at least mid-September.
Aug 17 2019
Aug 14 2019
Aug 13 2019
I think the proper fix is to LLVMCreateTypeAttribute (and LLVMCreateIntAttribute)
Can you post a link to the change that's causing the problem here? Your patch looks good but I'd like to understand it a bit better.
Jul 27 2019
Jul 24 2019
Jul 23 2019
May 25 2019
LGTM. Maybe a comment about expected lifetime of Context would be useful, but it seems fairly obvious.
May 18 2019
May 5 2019
Apr 24 2019
Apr 21 2019
Apr 16 2019
Apr 15 2019
Apr 9 2019
I agree with @CodaFi, it's better to build on LLVMDILocation* functions here, if for no other reason that they are more robust (and not deprecated).
So, these are going to be deprecated in D60484, but I see no harm in merging this patch, as it's a straightforward bugfix.
Yup, good catch! I'll make sure to check for this in the future as well.
Apr 8 2019
Apr 6 2019
Apr 5 2019
Agreed; I think it should still have Existing in the name if it takes a reference to a block, to distinguish from the existing set of (somewhat poorly named) functions.
SGTM, just one question about ownership.
Can you provide a bit more context for this change? It looks good, I just want to understand the plan here in more detail.
I think the names are confusing. Why not something like LLVMInsertExistingBasicBlock and LLVMAppendExistingBasicBlock?
Apr 4 2019
@aykevl I think you can ask for commit access, you've had more than a few patches merged.
Mar 25 2019
Mar 11 2019
Feb 20 2019
Feb 17 2019
Feb 16 2019
Feb 12 2019
Feb 11 2019
Added diff context
Added a test, based on the one provided by @george-hopkins but modified to pass on master.
Seems fine, with or without the length change. Hopefully this can get into 8.0.
Jan 25 2019
LGTM. Sorry for the delay