transpile: Always use absolute paths when referring to crates

[Rua]

• Fixes Qualified paths like libc::c_int should be globally qualified like ::libc::c_int to avoid name clashes #447.

[kkysen]

I think the CI failings are because you didn't update the os- and arch-specific snapshots that aren't run locally.

[kkysen]

@ahomescu, is #1399 able to handle stuff like this and still shorten the paths with imports? Also, is it or another refactor able to remove the :: where not needed? Would that be difficult at all?

The change here is correct and handles some edge cases, but it is longer, so it'd be nice to be able to refactor out the unnecessary ones afterward.

[Rua]

I think the CI failings are because you didn't update the os- and arch-specific snapshots that aren't run locally.

The three snapshot CI runs are failing because the leading double colon :: is expected by the snapshot (because I added it) but, for some reason, not actually generated by the transpiler. And this has me rather puzzled at the moment. For the Clang 18 test, snapshots__transpile-x86_64@vm_x86.c.snap gives this diff:

    6     6 │     unused_assignments,
    7     7 │     unused_mut
    8     8 │ )]
    9     9 │ #![feature(asm)]
   10       │-use ::core::arch::asm;
         10 │+use core::arch::asm;
   11    11 │ #[derive(Copy, Clone)]
   12    12 │ #[repr(C)]
   13    13 │ pub struct vm_t {
   14    14 │     pub programStack: ::core::ffi::c_int,

I can find only one place in the whole codebase that adds an import with the string "asm":

c2rust/c2rust-transpile/src/translator/assembly.rs

Line 1062 in 8d87265

item_store.add_use(vec!["core".into(), "arch".into()], "asm");

All items added to the item store are eventually fed through PathedMultiImports::into_items, where I have added lines to make absolute paths:

c2rust/c2rust-transpile/src/rust_ast/item_store.rs

Lines 55 to 64 in 8d87265

	if leaves.len() == 1 {
	path.push(leaves.pop().unwrap());
	let path = mk().abs_path(path);
	attrs.use_simple_item(path, None as Option<Ident>)
	} else {
	let path = mk().abs_path(path);
	attrs.use_multiple_item(path, leaves.into_iter())
	}
	}

And yet, the generated code does not have an absolute path. It's as if abs_path there is having no effect.

[kkysen]

This is weird. fs::read_to_string(&platform_rs_path).unwrap() is showing the use ::core::arch::asm;, but then the fs::read_to_string(&rs_path).unwrap() a few lines later is showing use core::arch::asm; again.

[kkysen]

Ah, I figured out what it is. It's rustfmt. It's deleting the ::.

[kkysen]

@Rua, I rebased this on #1409 to test if it fixes the issue.

[Rua]

It seems to be fixed, but it is now getting stuck on the empty Ident issue fixed by #1411.

[kkysen]

Ugh, why did this get closed?

[fw-immunant]

Ugh, why did this get closed?

GH seems to suggest it was closed because the target branch was deleted.

[kkysen]

Ugh, why did this get closed?

GH seems to suggest it was closed because the target branch was deleted.

Ugh, GitHub being dumb again. Normally when you delete the target branch, it changes it to master (or whatever the target branch of the PR that was closed is), but apparently when it's an external PR, it just closes the PR.

[Rua]

Hmm strange, the CI is still failing on the same error. Is it perhaps using an old version?

EDIT: But the MacOS test passed... huh?

[kkysen]

Hmm strange, the CI is still failing on the same error. Is it perhaps using an old version?

EDIT: But the MacOS test passed... huh?

I'm not sure, but the error message is slightly different. Might be a different error?

[Rua]

Transpile is able to generate a new Cargo.toml when transpiling, and it will fill it with dependencies used by the transpiled code, including c2rust-bitfields. Is it possible that the file it generates there refers to the stable/crates.io version of c2rust-bitfields, and not the one in the current directory tree? If so, that could explain what's going on maybe.

[kkysen]

Transpile is able to generate a new Cargo.toml when transpiling, and it will fill it with dependencies used by the transpiled code, including c2rust-bitfields. Is it possible that the file it generates there refers to the stable/crates.io version of c2rust-bitfields, and not the one in the current directory tree? If so, that could explain what's going on maybe.

I think you're right. And it seems to be using c2rust-bitfields= "0.3" from what I can tell, which is very old.