Amalgamate and c2rust transpile
#1
Conversation
…s the compilation database must be named exactly `compile_commands.json` for `libclang` to work.
Also, `bsp_default_app_{startup,run}.c` is skipped,
as it duplicates the real definitions in `cfe_psp_start.c`.
…exed array, and an `align_of` translated with a nullptr deref).
…of` since `c2rust analyze` is stuck on the old nightly.
| } | ||
| - Alignment = &mut (*(0 as *mut C2RustUnnamed_25)).Align as *mut CFE_ES_PoolAlign_t as cpuaddr; | ||
| + Alignment = core::mem::align_of::<CFE_ES_PoolAlign_t>() as _; | ||
| if Alignment < 4 as libc::c_int as libc::c_ulong { |
|
|
||
| const commands = JSON.parse((await fsp.readFile("compile_commands.json")).toString()) | ||
| .map(({ directory, file, output, command, arguments: args }) => { | ||
| const relativePath = pathLib.relative(".", file); |
There was a problem hiding this comment.
If we enable the tests, we get duplicate files. We should check for that (e.g. see #2, or use whatever approach you think works).
There was a problem hiding this comment.
I don't remember exactly, but I think part of the problem is that even though there are duplicate files, they do different things (like the unit tests). And since we don't care as much about the unit tests (at least I made that decision; if it's incorrect, we can switch things), I excluded them all. If we just only choose the first of each file, then we may exclude the versions of a file that we actually want.
| const flagsWithoutDefines = flags.filter(flag => !flag.startsWith(definePrefix)); | ||
|
|
||
| const includeLines = () => [ | ||
| ...defines().map(({ name, value }) => `#define ${name} ${value}`), |
There was a problem hiding this comment.
The macro might have already been defined elsewhere. I think we should do something like (see #2)
#pragma push_macro("${name}")
#undef ${name}
#define ${name} ${value}
...
#undef ${name}
#pragma pop_macro("${name}")
There was a problem hiding this comment.
How does {push,pop}_macro work? If it works the way I assume it does, then yes, this seems more robust and handles macros, too.
| }; | ||
| }) | ||
| // Exclude unit tests as that compiles things twice, leading to redefinition errors. | ||
| .filter(e => !e.defines().find(define => define.name === "_UNIT_TEST_")) |
There was a problem hiding this comment.
See comment above: couldn't we just check for duplicates?
| "#define _GNU_SOURCE", | ||
| "#include <pthread.h>", | ||
| "#include <sched.h>", | ||
| "#undef _GNU_SOURCE", |
There was a problem hiding this comment.
IIRC it didn't build without this, since otherwise the first use of pthread.h and sched.h didn't have _GNU_SOURCE defined yet, so it didn't define the necessary functions, but we can't define _GNU_SOURCE for every translation unit, since some have it undefined (I think).
|
|
||
|
|
||
| function toShellCommand(cmd) { | ||
| const command = cmd.arguments && cmd.arguments.join(" ") || cmd.command; |
There was a problem hiding this comment.
Do we need to escape the arguments here?
| mv ${rust_dir} ${rust_dir}.old | ||
| cargo new ${rust_dir} | ||
| (cd "${rust_dir}" | ||
| cargo add libc |
There was a problem hiding this comment.
We should pin these and all their dependencies. I'm already running into problems with cc updating to version 1.1.0 and asking for a newer rustc.
There was a problem hiding this comment.
Alternatively, could we just freeze Cargo.toml and Cargo.lock?
There was a problem hiding this comment.
Alternatively, could we just freeze
Cargo.tomlandCargo.lock?
Yeah, maybe.
| cargo add memoffset | ||
| cargo add f128 | ||
|
|
||
| # mv ../${rust_dir}.old/build.rs . # Don't need it. |
There was a problem hiding this comment.
It was from lighttpd-rust/amalgamate.mjs. And since I did things very quick and dirty, I wanted to leave in stuff I may want to re-enable in the future if I encountered problems or something.
|
|
||
| rust_dir=${name}_rust_amalgamated | ||
|
|
||
| # export CC=clang |
| @@ -0,0 +1,264 @@ | |||
| #!/usr/bin/env node | |||
There was a problem hiding this comment.
In the future, could we use either Python or shell scripts?
There was a problem hiding this comment.
Yeah. Shell probably isn't a good idea; it's too complex. But we could do Python. It started out as some very basic scripting, and since compile_commands.json is JSON, I used the node REPL, and then it grew, but I only worked on it for a couple of days quickly and dirtily, so it wasn't worth rewriting it much. And for cfs-rust, I just copied the one from lighttpd-rust and modified it.
| const { stderr } = await runCommand(amalgamated.o, "-fdiagnostics-format=json"); | ||
| const errors = JSON.parse(stderr); | ||
| return errors | ||
| .filter(error => error.message.match(/^rede(fini|clara)tion of /)) |
There was a problem hiding this comment.
One problem we have here are macro redefinitions, but I'm not sure how to solve that because we can't rename them using #define.
There was a problem hiding this comment.
Oh yeah, that's a problem. Did you run into any of them?
| await fsp.writeFile(amalgamatedPath("compile_commands.json"), JSON.stringify(commands, null, 4)); | ||
| } | ||
|
|
||
| async function main() { |
There was a problem hiding this comment.
Are we getting any value out of async here? It seems like each step blocks on the previous one.
There was a problem hiding this comment.
You can't really block in JS, so stuff like file writing is always async. Perf doesn't matter, though, so it doesn't need any concurrency.
This was based on
lighttpd-rust's amalgamation and transpilation.