@Amanieu Are you aware of any outstanding unaddressed issues in the RFC? Either things that need adding to the text, or alternatives/concerns/etc that haven't been documented in the appropriate alternatives/etc sections?
Or have all open discussions on the RFC been addressed to the best of your knowledge?
I'm asking because I'm thinking of proposing FCP soon.
Not that I know of. I've tried to add every objection to the RFC text.
I've seen, and I really appreciate your thoroughness.
The only one that's still unresolved is whether we want to namespace the asm! macro
I'm fine leaving that one an unresolved question for now. I personally would find it quite inconvenient if we did, to the point that I suspect there will quickly arise a standard crate re-exporting it as a common name.
We could even do that ourselves in the standard library: provide
std::arch::x86::asm! and similar, but re-export the one for the current target architecture under a common name.
That would defeat the point
Not necessarily. I could see value in being able to unambiguously reference one of the architecture-specific macros, perhaps.
But in any case, if the standard library doesn't provide it under a common name, a crate will. Nobody wants to write a giant tower of
#[cfg(...)] use std::arch::...::asm; at the top of their code.
Nonetheless, this isn't a question that needs resolving in the RFC. For now, your implementation provides it under a single name, and we can experiment with that in nightly, and if someone has a compelling argument for namespacing it they can make that argument based on real-world experience with nightly.
Also, same question for the PR: as far as you know, is the implementation of the new
asm! completely done in terms of the specified behavior from the RFC, or are there any outstanding issues you still want to address?
(speaking of which, I'll start a new topic for the LLVM version/feature detection issue.)
All of the RFC is implemented, except the fallback to an external assembler for cranelift.
It seems reasonable to do that in a separate PR.
(Is the cranelift backend fully buildable from rust-lang/rust at this point, or does it still require an external tree?)
It's still external at this point.
Then in that case, that change definitely belongs in a follow-up PR.
I got a WIP branch that integrates it into the rust build system. I am mostly waiting for how
git subtree will work out before submitting a PR.
@bjorn3 On that note you might want follow up about that, I remember the Clippy team recently ran into issues with using
git subtree but I don’t remember the outcome
@XAMPPRocky I have seen the discussion. I can't remember the outcome either though.
we're waiting on upstream git to merge the subtree patch. It has been finished according to the author and submitted: https://github.com/gitgitgadget/git/pull/493#issuecomment-626484834
@Amanieu Thank you for getting the dialect preservation patch into upstream LLVM!