User Details
- User Since
- Jan 21 2013, 11:58 AM (530 w, 6 d)
Feb 18 2023
Sep 10 2021
Jul 29 2021
LGTM
Feb 8 2021
LGTM. I've been maintaining OCaml bindings for a while, but I never got the time to update the tutorial. (Ironically, that tutorial was what got me into LLVM *and* OCaml...) It is regrettable that it will be removed but I don't see another solution.
Nov 16 2020
Oct 22 2020
Aug 28 2020
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
LGTM
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.
LGTM
Dec 27 2019
LGTM, thanks
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
@jberdine I personally highly prefer the approach in D60902. In general, I believe that the right direction for the OCaml bindings is to evolve towards rich and type-safe accessors.
@CodaFi Could you please comment on the current state of the patch?
Done (rG373903).
Sep 21 2019
LGTM
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
LGTM
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
LGTM
Jul 23 2019
LGTM
LGTM
May 25 2019
LGTM. Maybe a comment about expected lifetime of Context would be useful, but it seems fairly obvious.
May 18 2019
LGTM
May 5 2019
Apr 24 2019
LGTM
LGTM
Apr 21 2019
LGTM
Apr 16 2019
LGTM
Apr 15 2019
LGTM
Apr 9 2019
LGTM
LGTM
LGTM
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
LGTM
Apr 6 2019
Apr 5 2019
LGTM
LGTM
Sure.
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
LGTM
Mar 11 2019
LGTM
Feb 20 2019
LGTM
Feb 17 2019
Feb 16 2019
LGTM