Make some NullablePointer enums FFI-compatible with the base pointer type. #14121
Conversation
|
This may be a bigger problem that calls for a more structured solution. In particular, I think we are going to have this exact same problem again with |
|
r+ modulo nits. |
|
I've looked over the patch but haven't reviewed it in detail; it looks reasonable, although it would be nice if there were a way to avoid copying Also, it's been long enough since I touched this that I don't remember what state the FFI-safe-type lint pass is in with respect to allowing |
|
@jld I thought about adding another case to |
|
@luqmana actually, I think I might prefer to see another case: StructWrappedNullablePointer vs RawNullablePointer or something like that. One consequence is that you could not fail to forget a case. Given that the merge failed, I'd like to change my r+ to r- and request that change. :) |
|
@luqmana any idea what's the deal with those Travis CI failures? |
|
Giving r+ in any case, I guess we'll see if those are real or not. |
This slightly adjusts the NullablePointer representation for some enums in the case where the non-nullable variant has a single field (the ptr field) to be just that, the pointer. This is in contrast to the current behaviour where we'd wrap that single pointer in a LLVM struct. Fixes #11040 & #11303.
…ust-lang#14121) This is the lint described at rust-lang#136308 (comment) that recommends using HTML to nest links inside code. changelog: [`doc_link_code`]: warn when a link with code and a code span are back-to-back
This slightly adjusts the NullablePointer representation for some enums in the case where the non-nullable variant has a single field (the ptr field) to be just that, the pointer. This is in contrast to the current behaviour where we'd wrap that single pointer in a LLVM struct.
Fixes #11040 & #11303.