PhysicalMapping cannot be dereferenced.

I'm using the acpi crate to parse MADT but it looks like the PhysicalMapping cannot be dereferenced?

use ::acpi::sdt::madt::Madt;
use ::acpi::AcpiTables;

let tables = unsafe { AcpiTables::from_rsdp(AcpiHandler, rsdp.as_ptr().addr()) }
        .unwrap_or_else(|x| panic!("Failed to parse RSDP table: {:?}", x));

let mut madt = tables.find_table::<Madt>().expect("Failed to find MADT");

madt.entries().for_each(|entry| {}); // no method named `entries` found for struct `PhysicalMapping<H, T>` in the current scope

When I try to use .deref() manually, this is the error:

use ::acpi::sdt::madt::Madt;
use ::acpi::AcpiTables;

madt.deref().entries().for_each(|entry| {});

// the method `deref` exists for struct `PhysicalMapping<AcpiHandler, Madt>`, but its trait bounds were not satisfied [E0599]
// method cannot be called on `PhysicalMapping<AcpiHandler, Madt>` due to unsatisfied trait bounds
// Note: the following trait bounds were not satisfied:
// `Madt: Unpin`
// which is required by `PhysicalMapping<AcpiHandler, Madt>: Deref`

I tried using pin! to pin the madt since entries take reference to self via Pin. And result is still same.
It doesn't work for other fields as well.

Could it be because I disabled default features? By the way, crate still requires a global allocator even though all default features are disabled. And yes, my project requires me to not use any dynamic allocations. So currently there's a null allocator as a global allocator.

[martin-hughes]

I think if you replace madt.entries() with madt.get().entries() your first example should compile.

The expression tables.find_table::<Madt> might be a bit confusing, the return type isn't Madt but it's PhysicalMapping - and you use get to return a reference to the mapped object.

The docs could probably be quite a lot clearer - I'm sure @IsaacWoods would appreciate the PR if you fancy it?

OTOH this sounds like a straight bug:

By the way, crate still requires a global allocator even though all default features are disabled.

Are you able to post any compilation error messages when you have no Allocator?

I think if you replace madt.entries() with madt.get().entries() your first example should compile.

The expression tables.find_table::<Madt> might be a bit confusing, the return type isn't Madt but it's PhysicalMapping - and you use get to return a reference to the mapped object.

The docs could probably be quite a lot clearer - I'm sure @IsaacWoods would appreciate the PR if you fancy it?

OTOH this sounds like a straight bug:

By the way, crate still requires a global allocator even though all default features are disabled.

Are you able to post any compilation error messages when you have no Allocator?

Yes. This is the error

error: no global memory allocator found but one is required; link to std or add `#[global_allocator]` to a static item that implements the GlobalAlloc trait

If I recall correctly, the docs wasn't clear and there aren't any examples in this repo anyway.

[IsaacWoods]

The docs could probably be quite a lot clearer

Would be happy to accept a PR. FWIW, this is fairly standard (but perhaps advanced) Rust when dealing with smart-pointer-esque types that may hold !Unpin types - allowing Derefing to a non-pinned reference allows moves that are unsound, as far as I understand it. For ergonomics, we impl Deref for all other types, but you are required to use PhysicalMapping::get to get a pinned reference in the case of !Unpin

By the way, crate still requires a global allocator even though all default features are disabled.

This is definitely a bug. It's a little strange as I've definitely tested this working relatively recently, but we do not have regression testing of this (would need a little crate without an allocator I guess?). I can't see on quick parse what could've regressed here - any ideas @martin-hughes?

There you go. #312

[martin-hughes]

any ideas @martin-hughes?

No, nothing springs immediately to mind. In fact, @staarblitz, could you elaborate more?

Yes. This is the error

Is there no mention of the symbol attempting to use the Global allocator?

If I try to build the following then it compiles without error, so I'm not sure what is requiring the Global allocator.

@IsaacWoods would you take a PR with an update to the Github action that does a test compile of something like this?

cargo.toml

[package]
name = "baremetal_rust"
version = "0.1.0"
edition = "2021"

[profile.dev]
panic = "abort"

[profile.release]
panic = "abort"

[dependencies]
# Equivalent to the current HEAD of the main `acpi` repo but with less Git faff:
acpi = { package = "mh-acpi", version = "0.0.1", default-features = false }
pci_types = "0.10.1"

main.rs

#![no_std]
#![no_main]

use core::arch::asm;
use core::panic::PanicInfo;

// Not shown in this issue, but taken from the `aml_test_utils` version.
mod null_handler;
use null_handler::NullHandler;

fn sys_exit(status: i32) -> ! {
    unsafe {
        asm!(
            "syscall",
            in("rax") 60,
            in("rdi") status,
            options(noreturn)
        );
    }
}

#[no_mangle]
pub extern "C" fn _start() -> ! {
    use ::acpi::sdt::madt::Madt;
    use ::acpi::AcpiTables;

    // Clearly actually executing this will result in an access violation. The point is to check that it compiles.
    let tables = unsafe { AcpiTables::from_rsdp(NullHandler {}, 0xd1e as usize) }
        .unwrap_or_else(|x| panic!("Failed to parse RSDP table: {:?}", x));

    let mut _madt = tables.find_table::<Madt>().expect("Failed to find MADT");

    _madt.get().entries().for_each(|_entry| {});

    // Just in case it doesn't die already!
    sys_exit(0);
}

/// This function is called on panic.
#[panic_handler]
fn panic(_info: &PanicInfo) -> ! {
    loop {}
}

(Heavily adapted from the example by zulinx86)

[IsaacWoods]

would you take a PR with an update to the Github action that does a test compile of something like this?

Yep, of course!