mppf added a comment. Thanks for the feedback!
> "Given a non-bitfield struct field, return its index within the elements of > the struct's converted type." Done > I think "getLLVMFieldNumber" is probably the right name for this. Great suggestion, done. > This interface does not seem to be sufficient to support bit-fields. Right, supporting bit fields would make it more complex & isn't something I need right now anyway. With rjmccal's suggested comment, it's clear that bit fields won't work with this function. (Given a non-bitfield struct field...) > You should also indicate *which* record layout (complete object type or base > subobject type) the field number is for. I don't think there's any guarantee > that the same indexes work in both. I added a comment about this - indicating that inherited fields are not supported by this function. My use case is just for C structs at the moment and I'm not actually sure what we'd need to do for the interface to support building GEPs for inherited fields. I'm sure it would complicate the API. I think we should leave that complexity to another function or a future function (when somebody actually needs it). > (Eg, if we move to an IR representation using something non-GEPable to > represent a source-level class type, we would remove this function as it > would be meaningless.) In that event, I'd just want to have a way to build the appropriate field access. (e.g. a function to build an appropriate GEP; or a function that adds appropriate instructions to an IRBuilder and returns a Value* that points to the field, say). I'm open to trying to go directly to such an interface but I'd need significant help in designing/implementing it. (The interface I've proposed here meets my needs and I don't think I know enough about clang to design/implement a better one without help). https://reviews.llvm.org/D38473 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
