Qt Contributors Summit 2019 - moc and QMetaObject

• breaking ABI allows for performance changes and additional features in QMetaObject
• what about newer C++ features
  • raw literals are an issue e.g. like in tests
    • worse, error handling is confusing and makes it hard for users to know what's going on
  • can we use libclang instead of workarounds? see moc-ng
    • libclang can be quite slow, but we already did it for lupdate and qdoc
    • roughly an order of magnitude slower, but we could do better? => this is the biggest issue probably
    • when using build farms, moc is a bottleneck - unless it could be distributed but that doesn't sound feasible
    • bootstrapping is quasi impossible when using libclang, we'd have to port moc to not use C++ anymore
    • size of libclang + dependencies is only an issue for developer machines, roughly ~80mb
    • windows headers should be supported nowadays
    • libclang C api can be used, C++ api isn't stable, not a good idea probably - need to stay compatible with trunk continuously otherwise
  • why can't we use something easier than libclang?
    • parsing C++ is actually very hard with some C++ changes recently
    • we only need to parse a few things correctly, but we have to ignore all of the rest properly, which is tough
  • for qt6 we could remove old system to use moc without passing include paths, i.e. hard error if file is missing
• one could add a clang plugin in addition if moc is also "partially" a library that could be reused from elsewhere
  • that would allow us to do moc'ing at compile time to remove any overhead
  • we will get that once refactoring support lands in C++ for real
• when we need to extend moc, do we extend the old one or do we build a new tool based on top of libclang and add the new features there?
  • who does the work?
  • do we need it in Qt 6?
• reflection / verdigris
  • proper reflection will help to implement something like verdigris
  • what about the JSON output, that cannot be handled by C++ reflection
    • the JSON files are quasi the better solution to the aweful hack that is qmlplugindump
    • necessary for proper tooling support for QML
    • we could potentially put the JSON data into a separate DSO section instead and read it from there
    • verdigris should have the same knowledge to support all of the info necessary for the tooling side
    • C++ community may need similar features anyways for e.g. generating language bindings (that's also not part of the DSO but it would be e.g. a python file)
• ulf had an idea about using templates as a different mechanism to implement the introspection stuff -> how? needs more details/research