Add opaque pointers

[xlambein]

Description

All changes apply to LLVM >= 15.0.

• Add a ptr_type method to Context to get an opaque pointer type.
• Deprecate the use of ptr_type on *Type.
• Add a is_opaque method to PointerType to check whether the pointer is opaque (which is always true unless opaque-by-default is disabled).
• Change the tests and examples to use the new ptr_type method on Context.

Note that I haven't found a way in the C API (at least as exposed by llvm_sys) to disable the opaque-by-default behaviour. Because of that, I'm unsure it even makes sense to have the is_opaque method. Because of this I haven't really documented it much, but I can add an example to the doc if needed.

Related Issue

421

How This Has Been Tested

• Tested on 14.0, 15.0 and 17.0.
• I've added a test for is_opaque, but in effect the function always returns true.

Breaking Changes

None yet. In the future we might want to remove the ptr_type method on *Type for LLVM 17 onward, since only opaque pointers are supported.

Checklist

• [x] I have read the Contributing Guide

[TheDan64]

Aren't ptrs always opaque in 16(?)+? (the version after whenever they were introduced?)

One of your tests seems to confirm this since context.i32_type().ptr_type(AddressSpace::default()).is_opaque() always passes in 15+ 🤔

[xlambein]

Aren't ptrs always opaque in 16(?)+? (the version after whenever they were introduced?)

One of your tests seems to confirm this since context.i32_type().ptr_type(AddressSpace::default()).is_opaque() always passes in 15+ 🤔

I think this section answers those questions: https://llvm.org/docs/OpaquePointers.html#temporarily-disabling-opaque-pointers

Basically, pointers are opaque by default starting in 15+, but this behaviour can be disabled in 15 & 16, at least in clang. I couldn't find a way to disable them in LLVM's C API, but tbf I didn't look very hard. Given that, I think I could remove the is_opaque method.

[TheDan64]

@xlambein could you please rebase this on master? Thanks

[nsumner]

Not sure if it is relevant to this specific PR, but I think getting the value type of GlobalValues also matters now with opaque pointers. I just started playing with Inkwell, though, so there may be other idioms I am missing.

e.g.

fn get_value_type<'ctx>(global: GlobalValue<'ctx>) -> AnyTypeEnum<'ctx> {
    unsafe {
        AnyTypeEnum::new(llvm_sys::core::LLVMGlobalGetValueType(
            global.as_value_ref(),
        ))
    }
}

[xlambein]

I'm on holiday until late this month, so I'll finish this PR then :-)

@nsumner That seems right, I'll take a closer look later and perhaps add it to the PR.

[xlambein]

Rebased and added get_value_type to the PR.

[xlambein]

Any news? Still waiting for approval.

[TheDan64]

Apologies for this taking a while, I am traveling this month and won't have much time to review until April

[TheDan64]

Not sure why the build is failing suddenly...

[TheDan64]

Ah, I tried updating the PR and it seems I broke something - please take a look and then we can get this merged

[xlambein]

@TheDan64 I've rebased and tested locally, seems to work again.

[TheDan64]

Looks like this needs to be adjusted to handle other versions

[xlambein]

I've fixed that issue :-)

[gavrilikhin-d]

@TheDan64 can you have a look?

[TheDan64]

This looks pretty good, but needs to be updated for llvm18

[xlambein]

@TheDan64 Rebased + added the necessary changes for LLVM 18. At the same time, there was a failing doctest for 18 in upstream/master that I fixed (in src/targets.rs), I assume because there isn't any CI for LLVM 18 yet.