Note: this also adds a new C API and soft-deprecates the old C API.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
llvm/lib/IR/Core.cpp | ||
---|---|---|
3600 ↗ | (On Diff #181152) | Please add NameLen as this is the convention for all new C APIs. |
llvm/lib/IR/Core.cpp | ||
---|---|---|
3600 ↗ | (On Diff #181152) | Actually, now that I think about it, making sure that every Name argument has a NameLen accompanying would involve deprecating hundreds of functions and will probably never get done. Maybe it's OK to not have NameLen in IRBuilder bindings. @deadalnix @echristo your opinion on this? |
llvm/lib/IR/Core.cpp | ||
---|---|---|
3600 ↗ | (On Diff #181152) | Why do we have this convention now? I missed that discussion. I actually think we should consistently NOT have a NameLen argument for these APIs creating internal IR names. There's no reason to ever need a zero byte in them -- the names are entirely optional anyways! And having inconsistent APIs is just annoying here. I see that a couple new functions were _just_ added with a NameLen argument (LLVMBuildIntCast2, LLVMCreateBasicBlockInContext) -- and for both of those, I think that argument should be _removed_ from both, ASAP (especially before the branch, which is this week). |
llvm/lib/IR/Core.cpp | ||
---|---|---|
3600 ↗ | (On Diff #181152) | The discussion happened a while ago (maybe a year?). The point of convention is to make use of LLVM-C through FFI easier, since this is, to my best knowledge, the majority of use of LLVM-C.
I agree. Applying it to IR names was an oversight. Absolutely nothing is gained by IR names with embedded zeroes. |
llvm/lib/IR/Core.cpp | ||
---|---|---|
3600 ↗ | (On Diff #181152) | OK, I'll send a separate patch to remove NameLen from those two APIs. Are you OK with this patch as it stands, then? |
llvm/lib/IR/Core.cpp | ||
---|---|---|
3600 ↗ | (On Diff #181152) |
Thank you!
Yes, this and the other one are fine. |
llvm/lib/IR/Core.cpp | ||
---|---|---|
3600 ↗ | (On Diff #181152) |
llvm/lib/IR/Core.cpp | ||
---|---|---|
3600 ↗ | (On Diff #181152) | I have not missed them. I just didn't use "Accept" in phab since it appears to treat an accept from any single reviewer as a global accept, and it feels misleading for these patches. The C API changes look good to me in all four now. |