Open tschwinge opened 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.
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.
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.
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.
@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.
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.
@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.
Originally posted by @CohenArthur in https://github.com/Rust-GCC/gccrs/pull/1329#pullrequestreview-1014858287:
Originally posted by @dafaust in https://github.com/Rust-GCC/gccrs/pull/1329#pullrequestreview-1015852117: