Integer is zero when passing it to function that takes f32/f64

[thebigG]

Hi there,

I defined the following function in my gdextension:

    #[func]
    fn add_two(&mut self, a: f32) -> f32{
        println!("a:{}",a);
        return a + 2.0;
    }

The following call has no problems from gdscript

	print(add_two(1.0))

This will print a:1, which is expected.

However if I call this

print(add_two(1))

This prints a:0, which is not what I expected.

Is this behavior expected, or is there something else going here I'm missing?

My mind went directly to ABI--I thought for some reason something the rust compiler is doing...?

In any case I looked at the dwarf and it looks like the type abi from my rust gdextension matches that of Godot functions "real_t".

Here is real_t dwarf info from godot compiled from source:

0x00003839:   DW_TAG_base_type
                DW_AT_byte_size	(0x04)
                DW_AT_encoding	(DW_ATE_float)
                DW_AT_name	("float")

Here is the one for my rust code

0x00024b82:   DW_TAG_base_type
                DW_AT_name	("f32")
                DW_AT_encoding	(DW_ATE_float)
                DW_AT_byte_size	(0x04)

I hope I explained this clearly enough. Am I missing something here?

Thanks in advance!

[thebigG]

Here is some more info about my system/environment:

VERSION="22.04 LTS"
ID=pop
ID_LIKE="ubuntu debian"
PRETTY_NAME="Pop!_OS 22.04 LTS"
VERSION_ID="22.04"
HOME_URL="https://pop.system76.com"
SUPPORT_URL="https://support.system76.com"
BUG_REPORT_URL="https://github.com/pop-os/pop/issues"
PRIVACY_POLICY_URL="https://system76.com/privacy"
VERSION_CODENAME=jammy
UBUNTU_CODENAME=jammy
LOGO=distributor-logo-pop-os

Godot_v4.0-beta15_linux.x86_64 rustc 1.65.0 (897e37553 2022-11-02)

[Bromeon]

My mind went directly to ABI--I thought for some reason something the rust compiler is doing...?

I think conversions from GDScript int to Rust f32 are not yet implemented. The initial implementation was quite strict, types needed to match exactly.

In ergonomics sake, we can maybe define some rules regarding which conversions are safe. Unfortunately implicit conversions introduce a lot of potential for error, so I'm not sure if we should support it at all.

Anyway, thanks for reporting!

[lilizoey]

So i think this issue is at least partially fixed. i.e when done as a ptrcall it will succeed as expected, however when done as a varcall this will report a spurious error that the method does not exist for the second call.

this is caused (i believe) by us panicking when we try to convert a variant containing 1 into a float, which triggers the above message by #254. however with a pointer call we just use as to convert.

[Bromeon]

@thebigG do you know if this is still a problem with latest master and latest Godot (4.2-rc1)?

[lilizoey]

Current status of this, running this code:

var bar: Bar = $Bar
bar.add_two(1.0)
bar.add_two(1)
$Bar.add_two(1.0)
$Bar.add_two(1)

will print a: 1 for the first three, but then error on the fourth one with a type conversion error.

for consistency we should probably try to make it so that 2 and 4 have the same behavior. either both have a type conversion error or they both succeed with type coercion.