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

Tracking Issues: Current cxx-qt-gen Refactorings #937

Open
1 of 4 tasks
LeonMatthesKDAB opened this issue Apr 19, 2024 · 0 comments
Open
1 of 4 tasks

Tracking Issues: Current cxx-qt-gen Refactorings #937

LeonMatthesKDAB opened this issue Apr 19, 2024 · 0 comments
Assignees
Labels
👷 refactor Something needs to change

Comments

@LeonMatthesKDAB
Copy link
Collaborator

LeonMatthesKDAB commented Apr 19, 2024

What originally started as a refactor of naming (see #835 ) has now become a plan for a larger internal refactoring, which we aim to be the baseline of the next 0.7 release.
From this improved, cleaner architecture, we should be able to stabilize more easily and quickly.

The planned structure of cxx-qt-gen:

  • Frontend (Parser)
    • Parsing
      This phase should parse the syn tree into a list of declarations with all attributes resolved into usable data formats.
      However, all items should remain independent from each other and remain close to the way the user wrote it. (new 🌟 )
      The result should be a list of extern blocks, each with a list of items, like QObject declarations, QEnum declarations, etc.
    • Type Name extraction (the "Naming phase") (new 🌟 )
      Extracts all nameable types out of the parsed data.
      This is useful to resolve references and renamed types in the generation phase.
    • Checks phase??? (new 🌟 )
      We also consider adding a separate phase for certain checks. Though it's not yet clear what should belong there and what not.
  • Rust Backend
    • Generation
      We assume that for Rust code generation, most things can stay independent.
      Therefore we should be able to directly generate the Rust code from the input declarations without having to rearrange and associate more complex items like QObjects.
    • Writer
  • C++ Backend
    • Structuring (new 🌟 )
      C++ headers need to be structured, as all data within a QObject must be written inside the same pair of {...}.
      Therefore we need to associate the loosely parsed data from the Frontend.
      This should now be its own phase
    • Generation
    • Writer

Overall we should use the new functions from the naming module wherever possible, which should then solve our issues regarding cxx_name, rust_name, etc.

Associated issues:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
👷 refactor Something needs to change
Projects
None yet
Development

No branches or pull requests

1 participant