search

Rust-GCC / gccrs

GCC Front-End for Rust
https://rust-gcc.github.io/
GNU General Public License v2.0
2.31k stars 146 forks source link

Builtin macros #927

Open CohenArthur opened 2 years ago

CohenArthur commented 2 years ago

Bang macros

Attribute macros

Derive macros

Directly taken from https://github.com/rust-lang/rust/blob/a240ccd81c74c105b6f5fe84c46f8d36edb7e306/compiler/rustc_builtin_macros/src/lib.rs#L52-L119

Thanks a lot to @bjorn3 for the corrections

Builtin macros which are declared and/or used in libcore 1.49:

bjorn3 commented 2 years ago

Deprecated Derive macros

There seems to be a push to destabilize them in rustc. Skipping them in gccrs should be fine I think.

cmdline_attrs

This is not a macro, but the module implementing -Zcrate-attr.

deriving

This is the module containing all builtin #[derive] macros.

proc_macro_harness

This module is for the proc macro implementation.

source_util

Haven't checked, but also likely not a macro.

There are a couple other items on the list that I don't think are actual macros.

CohenArthur commented 2 years ago

@bjorn3 this was mostly created by looking here and by grepping for compiler built-in in the rust repo. I do think it needs some adjustments, so thanks a lot! I'll double check it

liushuyu commented 1 year ago

This table probably needs an update.

Since the last update of this issue, the following macros have been implemented:

Most remainders require the format_args! macro to be implemented (print! and println! family of macros also depend on this).

CohenArthur commented 1 year ago

Yeah, format_args is a big blocker at the moment for a lot of macros including std ones. I wonder how hard it would be to implement it in our current state. The format of format strings (:D) is definitely hard to implement, but ideally it should be relatively easy to add calls into the Display, Debug, Pointer... etc traits to the fmt method. This will definitely be an interesting and complex project on its own :) I hope we can do it gradually and extend it as time goes

liushuyu commented 1 year ago

Yeah, format_args is a big blocker at the moment for a lot of macros including std ones.

It also prevents most of the "real world projects" (I would guess >95%) from compiling if it is unimplemented.

I wonder how hard it would be to implement it in our current state.

I would consider the difficulty extremely hard at the moment. format_args! by itself is a 3k+ lines monstrosity in rustc, not including all the other machinery that needs to be added to accommodate its addition.

Also, another potentially problematic macro would be asm! since that would require a change to the current AST structures (a new kind of node needs to be added), and the consequence of that will be most of the existing visitors need to adapt to this change. I am not sure if there exists a way to pass the assembly fragment w/o adding a new kind of ASTNode type.

CohenArthur commented 1 year ago

I think asm is a very difficult one indeed. It's a whole other syntax than what gcc currently supports too, but I think we'll eventually be able to translate one to the other. And yeah, format_args is quite big haha, but it is tremendously important as you point out, even for other builtin macros (unreachable, panic...)

CohenArthur commented 1 year ago

Edited to reflect which macros we really need to focus on for libcore 1.49