Hi all,
I’ve been catching up from the archive about talk about a C++11 migration tool. It seems all that communication culminated in the loop-convert tool currently in the clang-tools-extra repo. My team has been developing tools for migrating more C++11 features. We’re starting small and simple (e.g. nested template space removal between ‘>’, use of nullptr, etc.) and hope to tackle more and more complex transformations. Right each transformation lives in its own standalone tool, following the loop-convert model. However, based on the old conversation I think the intent was to have loop-convert as the basis of a single binary that does multiple transforms right?
Assuming ‘yes’ to that question, when we have a few tools to choose from, we want to merge them into a single c++11 migration tool. We’d welcome thoughts on the design of such a tool. I’m aware of earlier suggestions:
Hi all,
I’ve been catching up from the archive about talk about a C++11 migration tool. It seems all that communication culminated in the loop-convert tool currently in the clang-tools-extra repo. My team has been developing tools for migrating more C++11 features. We’re starting small and simple (e.g. nested template space removal between ‘>’, use of nullptr, etc.) and hope to tackle more and more complex transformations. Right each transformation lives in its own standalone tool, following the loop-convert model. However, based on the old conversation I think the intent was to have loop-convert as the basis of a single binary that does multiple transforms right?
Yes, we'd like to have a single "C++11 migrator" binary that can do multiple transforms. And I *definitely* think it's good to start with the simpler transformations, so we can get the basic architecture in place without having to also work on a ton of logic for individual migration steps.
Assuming ‘yes’ to that question, when we have a few tools to choose from, we want to merge them into a single c++11 migration tool. We’d welcome thoughts on the design of such a tool. I’m aware of earlier suggestions:
- Something akin to –O# to control the level of risk/change you’re willing to live with.
- Options to turn on/off certain transforms
The two aren't mutually exclusive. Personally, I think the latter is far more important: users need to be able to say, "use this C++11 feature, but not this other one". And it certainly makes sense to define a default set of transforms that are guaranteed to be safe (including the two you mentioned above).
- Doug
I would be happy to help define and build such a tool.
-- Marshall
Marshall Clow Idio Software <mailto:mclow.lists@gmail.com>
A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait).
-- Yu Suzuki
I would suggest that we get the tools submitted to a shared repository in their current form before trying to merge them. This was the tools are available to anyone who wants to use them while the merge work is happening.
I'd also vote in favor of the feature-by-feature enable and disable.
Yours,
Philip Reames
Personally, I'd rather see us refactor in place to get the architecture we like, then start building that out with additional migration steps. If adding a new migration step isn't super-easy, we should go refactor some more.
- Doug
Personally, I'd rather see us refactor in place to get the architecture we like,
then start building that out with additional migration steps. If adding a new
migration step isn't super-easy, we should go refactor some more.
Alright. First question I have about such a multi-pass tool would be how best to do the rewriting. Should we completely apply the previous pass' changes, re-parse, then move on to the next pass? For simple transforms rewrites probably wouldn't conflict (e.g. template space removal, nullptr usage) but one could easily forsee one pass making a change that might affect a later pass. Let's not forget that physical rewrites from one pass may overlap with rewrites from another. Assuming yes, I presume we shouldn't be writing out to disk every time but rather changing an in-memory buffer?