cg_llvm: Remove inherent methods from several LLVM FFI types #147327
Conversation
Using a helper trait allows the conversions to remain in `rustc_codegen_llvm`, even if the FFI types are moved to a different crate.
This patch also moves `Regions` to a different module, since that type can stay put when the FFI bindings move to another crate.
rustbot
added
A-LLVM
|
r? @nnethercote rustbot has assigned @nnethercote. Use |
|
This will have import conflicts with #147322; I'll deal with them as they arise. |
| /// Determines the appropriate [`llvm::CallConv`] to use for a given function | ||
| /// ABI, for the current target. | ||
| pub(crate) fn to_llvm_calling_convention(sess: &Session, abi: CanonAbi) -> llvm::CallConv { |
There was a problem hiding this comment.
Ah yeah, this can't use FromGeneric because it doesn't fit the signature.
There was a problem hiding this comment.
Interestingly, it would have the same signature if CanonAbi preserved a distinction between Nvidia and AMD.
I made a draft patch to do that, but ultimately decided it was out of scope for this PR.
|
@bors r+ rollup |
bors
added
S-waiting-on-bors
|
|
Rollup of 4 pull requests Successful merges: - #147327 (cg_llvm: Remove inherent methods from several LLVM FFI types) - #147332 (Set opt-level flag for installing tool only on CI) - #147374 (bootstrap: don't build book redirect pages during dry-run/test) - #147376 (bootstrap: relax `compiler-rt` root assertion) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of #147327 - Zalathar:inherent, r=workingjubilee cg_llvm: Remove inherent methods from several LLVM FFI types This is mainly motivated by #142897, which proposes to move the LLVM FFI bindings out of `rustc_codegen_llvm` and into `rustc_llvm`, which is arguably the more correct place for them from a linking perspective. --- In order to perform that migration, all of the types used in FFI signatures also need to be moved. However, several of those types have inherent methods that convert from backend-independent types to LLVM FFI types. Moving the inherent methods as-is would require adding a lot of otherwise-unnecessary dependencies to `rustc_llvm`. And we can't leave them behind as-is, because inherent methods can't be defined in another crate. Therefore, this PR replaces several of those inherent methods with either extension trait methods or free functions.
|
I don’t love In the end, I settled on preserving the existing name, mainly so that I could stop thinking about it and move on with this PR. |
This is mainly motivated by #142897, which proposes to move the LLVM FFI bindings out of
rustc_codegen_llvmand intorustc_llvm, which is arguably the more correct place for them from a linking perspective.In order to perform that migration, all of the types used in FFI signatures also need to be moved. However, several of those types have inherent methods that convert from backend-independent types to LLVM FFI types.
Moving the inherent methods as-is would require adding a lot of otherwise-unnecessary dependencies to
rustc_llvm. And we can't leave them behind as-is, because inherent methods can't be defined in another crate.Therefore, this PR replaces several of those inherent methods with either extension trait methods or free functions.