Skip to content

Conversation

@fw-immunant
Copy link
Contributor

It's currently a no-op. We'll also want to make it run by default, which is where it seems more likely we'll run into CI/release trouble due to our complex rustc version requirements.

@fw-immunant fw-immunant force-pushed the fw/enable-reorg-defs branch 6 times, most recently from ca53fc4 to 89ecc26 Compare October 15, 2025 15:41
"--cargo",
"--rewrite-mode",
"inplace",
"rename_unnamed",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had completely forgotten we had this, it probably would have fixed the issue from the libxml2 demo.

@fw-immunant fw-immunant force-pushed the fw/enable-reorg-defs branch 2 times, most recently from 1a148be to cbfd8f2 Compare October 30, 2025 21:17
@fw-immunant
Copy link
Contributor Author

Fixed a couple issues where the tests were overly brittle; now in cargo test only tests/simd.x86_64 seems to fail; many errors around not-found types, such as:

error[E0412]: cannot find type `__m128` in this scope

@fw-immunant
Copy link
Contributor Author

The problem seems to be that imports of needed types for SIMD get placed into submodules and then these types are not in scope for their later usage:

#include <immintrin.h>

void simd_fn_codegen(__m128i i)
{
    i = _mm_aesdeclast_si128(i, i);
}

transpiles with --reorganize-definitions to:

#![allow(
    dead_code,
    non_camel_case_types,
    non_snake_case,
    non_upper_case_globals,
    unused_assignments,
    unused_mut
)]
#![register_tool(c2rust)]
#![feature(register_tool, stdsimd)]
#[c2rust::header_src = "/usr/lib/clang/21/include/mmintrin.h:1"]
pub mod mmintrin_h {
    #[cfg(target_arch = "x86")]
    pub use ::core::arch::x86::__m128i;
    #[cfg(target_arch = "x86_64")]
    pub use ::core::arch::x86_64::__m128i;
}
#[c2rust::header_src = "/usr/lib/clang/21/include/__wmmintrin_aes.h:1"]
pub mod __wmmintrin_aes_h {
    #[cfg(target_arch = "x86")]
    pub use ::core::arch::x86::_mm_aesdeclast_si128;
    #[cfg(target_arch = "x86_64")]
    pub use ::core::arch::x86_64::_mm_aesdeclast_si128;
}
#[cfg(target_arch = "x86")]
pub use ::core::arch::x86::_mm_setzero_si128;
#[cfg(target_arch = "x86_64")]
pub use ::core::arch::x86_64::_mm_setzero_si128;
#[no_mangle]
#[c2rust::src_loc = "3:1"]
pub unsafe extern "C" fn rust_simd_fn_codegen(mut i: __m128i) {
    i = _mm_aesdeclast_si128(i, i);
}

@fw-immunant
Copy link
Contributor Author

Ah, there's another problem here: if -e/--emit-build-files is not passed (e.g. as when invoked from test_translator.py), the transpiler skips invoking the refactorer entirely, but does still change its output to include mods for headers and the various c2rust::src_loc/c2rust::header_src attributes. In this case the output does not compile at all, so even passing -e just results in the transpiler balking with:

warning: Reorganizing definitions failed: Crate does not compile.

So it seems we need to fix this in the transpiler, not the refactorer, and may also need to alter how the transpiler is invoked by test_translator.py if we want those tests to actually benefit from the refactorer.

@fw-immunant fw-immunant force-pushed the fw/enable-reorg-defs branch 2 times, most recently from f09ec6a to 8e5a67c Compare November 4, 2025 01:36
@fw-immunant
Copy link
Contributor Author

The next set of errors in CI are the testsuite failing due to __sigset_t and C2RustUnnamed types not being imported for some reason.

@fw-immunant
Copy link
Contributor Author

Now I'm seeing c2rust-refactor: error while loading shared libraries: librustc_driver-14a53782e7072fd8.so: cannot open shared object file: No such file or directory. Presumably a library path issue of some kind.

@fw-immunant fw-immunant changed the title [WIP] re-enable --reorganize-definitions flag Re-enable --reorganize-definitions flag Nov 4, 2025
@kkysen kkysen force-pushed the fw/enable-reorg-defs branch from f81ebb2 to f7c25bb Compare November 10, 2025 14:46
this closure is called when exporting types, and a convert_type method already exists
other exports from the submodule (for types it defines via enum/struct definitions) are already added to this set, but reexports were not.

this meant that if we organized imports of std/core types into a submodule (which the transpiler itself does when `--reorganize-definitions` is passed), these imports would then be missing from the main module.
these will have `use`s added unconditionally with the stdlib path if the main module uses them directly, so in order to allow deduplication without tracing through reexports, we should have the main module import these from their original (stdlib) location, not the reexported one
computing these is impure because it can call `import_type`. ideally we would
not disable this caching but instead cache both the initializer and its set of
required imports.
Unfortunately, we have to bend over backwards to make this work without changing CLI behavior.

This adds a new `--no-reorganize-definitions` flag to disable reorganizing definitions,
because it would not be backwards-compatible to add an optional argument for the flag
(it would eat a following argument that would previously be unassociated with the flag).
@kkysen
Copy link
Contributor

kkysen commented Nov 10, 2025

Split into and superseded by #1451 and #1452.

@kkysen kkysen closed this Nov 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants