Feature Title
Custom clang-tidy check to apply standard porting templates
Feature Description & Current Pain Points
Porting of C/C++ projects involves lots of repetitive changes mechanically applied to upstream code across lots of projects.
Even after initial porting is done, it requires constant maintenance.
It's tedious and impractical; also it pollutes the upstream code.
thread_local is a good example.
It's used ubiquitously, and the support on z/OS is very limited (only v3.1 and only for trivially destructible variables).
Every time you have to go and add the same TLS simulation.
It's pretty likely that some future upstream updates will introduce more thread_local vars, and it'll need to be done again and again.
Also, I believe, at some point, the feature will be fully implemented on z/OS, and all the ugly simulations will need to be removed.
As a solution, I suggest using a custom clang-tidy check that would generate and apply patches automatically as a part of build process on z/OS.
IMO, it's a solid solution easy to implement (I've built a PoC for thread_local).
Proposed Solution & Expected Behavior
A custom clang-tidy check that detects language constructions to be adapted for z/OS and applies patches on the fly before build starts.
It's consistent with other LLVM-based tooling, reliable and makes porting and port maintenance way less tedious.
From technical point, it's a pretty trivial thing to implement given that clang-tidy is already ported.
I've been testing a PoC and will be happy to contribute if the approach gets accepted.
Environment Details (Optional)
No response
Additional Information (Optional)
No response
Feature Title
Custom clang-tidy check to apply standard porting templates
Feature Description & Current Pain Points
Porting of C/C++ projects involves lots of repetitive changes mechanically applied to upstream code across lots of projects.
Even after initial porting is done, it requires constant maintenance.
It's tedious and impractical; also it pollutes the upstream code.
thread_localis a good example.It's used ubiquitously, and the support on z/OS is very limited (only v3.1 and only for trivially destructible variables).
Every time you have to go and add the same TLS simulation.
It's pretty likely that some future upstream updates will introduce more thread_local vars, and it'll need to be done again and again.
Also, I believe, at some point, the feature will be fully implemented on z/OS, and all the ugly simulations will need to be removed.
As a solution, I suggest using a custom clang-tidy check that would generate and apply patches automatically as a part of build process on z/OS.
IMO, it's a solid solution easy to implement (I've built a PoC for
thread_local).Proposed Solution & Expected Behavior
A custom clang-tidy check that detects language constructions to be adapted for z/OS and applies patches on the fly before build starts.
It's consistent with other LLVM-based tooling, reliable and makes porting and port maintenance way less tedious.
From technical point, it's a pretty trivial thing to implement given that
clang-tidyis already ported.I've been testing a PoC and will be happy to contribute if the approach gets accepted.
Environment Details (Optional)
No response
Additional Information (Optional)
No response