jyn

Parts of the compiler that would especially benefit: - parsing declarations - lvals and rvals

Status: `cranelift_object` doesn't work properly with `--target x86_64-pc-windows-gnu`, and the system linker doesn't work with `--target x86_64-apple-darwin` (because I don't know how to pass it the target flags).

~~Will be fixed by #151~~ Nope, not fixed: ```c int f(const int *p) { const int *q; p = q; } :3:3 error: invalid program: cannot assign to variable 'p'...

Relevant code: https://github.com/jyn514/saltwater/blob/0e36d97ac31a1875d6a1276b1f8840fedcef65e8/src/analyze/mod.rs#L273-L291 I think I need to pass in `&mut specs.qualifiers` to `parse_declarator`.

More test cases: - `int *const p, i;` - the `const` should only affect `p`. - `inline int (*f)()`, `int (*inline f)()` - not allowed

As an alternative to rewriting`ir`, it might be possible to add a third intermediary representation and do CFG analysis at the same time. This would be a large upfront investment...

A good start to this would be using target-lexicon to get the pointer size instead of trying to hard-code it ourselves. See https://docs.rs/target-lexicon/0.8.1/target_lexicon/struct.Triple.html#method.pointer_width.

Once https://github.com/bytecodealliance/cranelift/pull/1255 is merged, we won't have to wait on Faerie

Hmm, https://github.com/sile/rustracing/pull/9/ is a different approach than I was thinking of, it allows sending with either Tokio or with crossbeam. But I was actually suggesting removing the "send" abstraction altogether...

> The solution: I'd love a CARGO_TARGET_DIR environment variable. There's clearly precedent for this as cargo doc depends on such a thing today. This has cause and effect backwards. `cargo...