QtCS2017 Before Runtime discussion: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
 
(9 intermediate revisions by the same user not shown)
Line 1: Line 1:
== Make the API easy? ==
== Presentation / starting Subjects ==
=== Make the API easy? ===
* Copy on Write to avoid copies at runtime
* Copy on Write to avoid copies at runtime
* Can we do it at compile time?
* Can we do it at compile time?
Line 6: Line 7:
* Clang can help here
* Clang can help here


== Make changes easy ==
=== Make changes easy ===
* API changes are expensive
* API changes are expensive
* API looks outdated if not adapted to current paradigms (legacy code)
* API looks outdated if not adapted to current paradigms (legacy code)
Line 12: Line 13:
* How can Clang help here
* How can Clang help here


== Clang Query ==
=== Clang Query ===
* Think about it as SQL for the AST
* Think about it as SQL for the AST
* Makes big changes much cheaper and secure
* Makes big changes much cheaper and secure


== Immediate feedback vs overnight refactoring ==
=== Immediate feedback vs overnight refactoring ===
* Both are important
* Both are important
* Immediate feedback reduces refactorings and reviews
* Immediate feedback reduces refactorings and reviews
Line 22: Line 23:
* Integration with the CI
* Integration with the CI


=== Notes ===
== Notes ==
* need real examples
* need real examples
* QtCreator supports only very basic refactoring tools
* QtCreator supports only very basic refactoring tools
Line 41: Line 42:
* how far can we get with transformation with tools?
* how far can we get with transformation with tools?
* Clangtidy is alreadys there
* Clangtidy is alreadys there
* these tools are not available on all desktop plattforms
** can have plugins
** how can it be a part of our workflow
* these tools are not available on all desktop platforms
** so this can not the only way to do these transformations
** so this can not the only way to do these transformations
* example: new Qt connections -> running transformation -> slightly different behavior
* problem with #ifdef sections
* kind of cross compilation with clangtidy with necessary defines
** possibility to skip some of the problematic headers
* warn about section where we can not do our work
* the tool only helps when changes are there, but it should not decrease the border to have these changes
* good example: QRegEx -> QRegularExpression
* there are two different tasks
** show it immediately
** batch processing task
* we need both, but they are sharing code
* clang static analyzer is something different
=== Conclusion ===
* we need and want this
* this should not only happen in the Berlin office
* can QtCreator show Clazy warnings?
** was not working in the past
** but this would be the first step to go further

Latest revision as of 12:06, 9 October 2017

Presentation / starting Subjects

Make the API easy?

  • Copy on Write to avoid copies at runtime
  • Can we do it at compile time?
  • Let tools get const and references right
  • Warn about unnecessary copies
  • Clang can help here

Make changes easy

  • API changes are expensive
  • API looks outdated if not adapted to current paradigms (legacy code)
  • How can we make them easy
  • How can Clang help here

Clang Query

  • Think about it as SQL for the AST
  • Makes big changes much cheaper and secure

Immediate feedback vs overnight refactoring

  • Both are important
  • Immediate feedback reduces refactorings and reviews
  • Run refactorings overnight for expansive refactorings
  • Integration with the CI

Notes

  • need real examples
  • QtCreator supports only very basic refactoring tools
    • having tools outside of QtCreator and use these tools maybe inside
  • API changes need to be available by Clangtidy scripts (?)
  • what about templates?
    • concept
  • the tools cannot fit to all cases
  • this kind of tools can help to move to Qt 6(or other future versions)
  • renaming methods would be easier with this kind of tools
  • mental work to remember this new name is still there
  • can a tool do exchange deprecate things with the new "right" thing
    • using clang "Fixit" maybe possible
    • clang is here a tool and not the only compiler
    • these "Fixit" information should be inside the code
      • if it is not there it will lose sync to the code
      • maybe inside the code there can be a link to something?
  • how far can we get with transformation with tools?
  • Clangtidy is alreadys there
    • can have plugins
    • how can it be a part of our workflow
  • these tools are not available on all desktop platforms
    • so this can not the only way to do these transformations
  • example: new Qt connections -> running transformation -> slightly different behavior
  • problem with #ifdef sections
  • kind of cross compilation with clangtidy with necessary defines
    • possibility to skip some of the problematic headers
  • warn about section where we can not do our work
  • the tool only helps when changes are there, but it should not decrease the border to have these changes
  • good example: QRegEx -> QRegularExpression
  • there are two different tasks
    • show it immediately
    • batch processing task
  • we need both, but they are sharing code
  • clang static analyzer is something different


Conclusion

  • we need and want this
  • this should not only happen in the Berlin office
  • can QtCreator show Clazy warnings?
    • was not working in the past
    • but this would be the first step to go further