Rust-GCC / gccrs

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

Investigate sharing code with GCC/C++ #1334

Open tschwinge opened 2 years ago

tschwinge commented 2 years ago

Originally posted by @CohenArthur in https://github.com/Rust-GCC/gccrs/pull/1329#pullrequestreview-1014858287:

[...], we might even think about simply linking against the C++ const folder in the future, [...]

Originally posted by @dafaust in https://github.com/Rust-GCC/gccrs/pull/1329#pullrequestreview-1015852117:

This is an interesting idea, I'd be curious to see if/how it works in practice. I was actually wondering whether some of the ported-but-not-renamed functions in this PR will give link errors if we try to build a gcc with both the rust and c++ frontends enabled. Definitely not a blocker for this to be merged!

It might turn out that if we want to link against the C++ const folder directly we'd need to factor it out of the C++ frontend to somewhere common, like how C and C++ share some functionality in the c-family directory. I'm not very familiar with the build processes for the front ends though so maybe these are issues long since solved :P I need to read up.

tschwinge commented 2 years ago

I'm lacking all context here, but if this is feasible then I'm all in favor, instead of copying GCC/C++ code, adapting it for GCC/Rust, and then having effort/difficulties picking up later GCC/C++ code changes.

CohenArthur commented 2 years ago

I agree :D However, I think that should come in much later - we might end up removing a lot from C++'s constexpr folder, or need extra stuff, etc. I think @abbasfaisal's project is gonna give us a very good idea of what we need and don't need, and we'll be able to make a decision at this point.

philberty commented 2 years ago

I would love for this to work but last I tried I ended up in the case where the code needs to link against the cpp lang hooks which is a pain.

Since we have not created any custom GENERIC trees it would be nice if there was a shared primitive constant evaluator for GCC which is what I think we will end up creating by extracting the one from the CPP front-end so that it could be used by any front-end in the end.

bjorn3 commented 2 years ago

Are you sure sharing a constant evaluator with C++ would be possible? How would it integrate with the query system once you have implement that? And what about handling rust specific intrinsics, vtable layouts and integration with const panics? And what about reporting UB during const evaluation? While reporting UB during const eval is not required as per the RFC about it, it would be nice to have.

CohenArthur commented 2 years ago

@bjorn3 I think this is definitely why we need to investigate! I personally hadn't given any thought about const panics or about how vtable layouts would impact the constant evaluator. I think this is definitely something we need to look into before making any decision.

The reason I originally stated this is because I only considered "basic" const expressions: C++ and Rust both have constant functions, both have complex control structures, both have constant variables, etc. So from that point of view, it makes sense to simply reuse the C++ constant evaluator instead of copy-pasting it into our frontend.

However, if we do end up wanting rust-specific behavior such as UB reporting: I'd rather extend the C++ evaluator, and keeping our copy which would contain more verifications, possibly more tree codes and so on.

tschwinge commented 1 year ago

This issue came up again in context of https://gcc.gnu.org/PR111899 "[14 regression] GCC fails to bootstrap with 'rust-tree.cc:131:10: error: ‘NON_DEPENDENT_EXPR’ was not declared in this scope'", where in https://inbox.sourceware.org/20231020173630.2328347-1-ppalka@redhat.com "rust: build failure after NON_DEPENDENT_EXPR removal [PR111899]" patch discussion @jicama confirmed that...

It would be nice to move a lot of the constexpr code into the middle-end, but I expect that would be a significant project.

tschwinge commented 1 year ago

@bjorn3:

Are you sure sharing a constant evaluator with C++ would be possible? How would it integrate with the query system once you have implement that? And what about handling rust specific [...]

Per my understanding, the generic (middle end) code would be configured for C++ vs. Rust language by a number of lang_hooks (see https://github.com/Rust-GCC/gccrs/blob/master/gcc/langhooks.h etc.). Making the existing C++ code generic (that is, abstracting the C++ "details" into lang_hooks) is what @jicama "expect that would be a significant project", I suppose.