Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[TESTING] Remove use of deprecated C++ features, allow compilation with C++20 #4297

Draft
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

vlstill
Copy link
Contributor

@vlstill vlstill commented Dec 17, 2023

No description provided.

@vlstill vlstill self-assigned this Dec 17, 2023
@vlstill vlstill force-pushed the forward-cpp-friendly branch from 5c412dc to 27f648c Compare December 17, 2023 19:31
@vlstill vlstill force-pushed the forward-cpp-friendly branch from 27f648c to 9113020 Compare January 12, 2024 19:12
@vlstill vlstill changed the title [TESTING] Remove deprecated [TESTING] Remove use of deprecated C++ features, allow compilation with C++20 Jan 23, 2024
@fruffy fruffy added the core Topics concerning the core segments of the compiler (frontend, midend, parser) label Mar 15, 2024
@fruffy
Copy link
Collaborator

fruffy commented Apr 11, 2024

@vlstill Should we rebase this PR. Things might be easier after recent updates.

@vlstill
Copy link
Contributor Author

vlstill commented Apr 11, 2024

@fruffy I've tried this few weeks ago after the recent changes like removal of StringRef. Sadly it still did not work easily. The main problem is that there is a lot of implicit casts between string-like types (cstring and IR::ID being the main culprits I believe). With the new rules for comparsion operators in C++20 (mainly the symmetry -- ability of the compiler to flip arguments of == and !=) this produces a lot of ambiguous overloads. I think the best way to get rid of these is actually to force lot of implicit casts to be explicit. At least the IR::ID shouldn't really be implicitly constructible from string types. This will be a breaking change of course, but it should not be too hard to apply to the downstream projects.

I did not get much further as sadly I don't have much time to spare for the open source p4c lately :-(.

@fruffy
Copy link
Collaborator

fruffy commented Apr 11, 2024

@fruffy I've tried this few weeks ago after the recent changes like removal of StringRef. Sadly it still did not work easily. The main problem is that there is a lot of implicit casts between string-like types (cstring and IR::ID being the main culprits I believe). With the new rules for comparsion operators in C++20 (mainly the symmetry -- ability of the compiler to flip arguments of == and !=) this produces a lot of ambiguous overloads. I think the best way to get rid of these is actually to force lot of implicit casts to be explicit. At least the IR::ID shouldn't really be implicitly constructible from string types. This will be a breaking change of course, but it should not be too hard to apply to the downstream projects.

I did not get much further as sadly I don't have much time to spare for the open source p4c lately :-(.

Let me check how much work needs to be done with the current compiler.

@vlstill vlstill force-pushed the forward-cpp-friendly branch from 9113020 to c5b2c3b Compare April 11, 2024 18:38
@vlstill
Copy link
Contributor Author

vlstill commented Apr 11, 2024

@fruffy I've pushed what I had in my local branch here. The old one is https://github.com/vlstill/p4c/tree/forward-cpp-friendly-old.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core Topics concerning the core segments of the compiler (frontend, midend, parser)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants