GCC 16 warnings about incomplete types in an SFINAE context
-
-
Yeah, I know this – and I also read the big fat warnings saying "This function violates the object-oriented principle of modularity" ;-)
Also, I don't always need the sender, because the popup can be requested from a spinbox and from a radio button – but I always need the spinbox. So this couldn't even be used in this case.
-
Yeah, I know this – and I also read the big fat warnings saying "This function violates the object-oriented principle of modularity" ;-)
Also, I don't always need the sender, because the popup can be requested from a spinbox and from a radio button – but I always need the spinbox. So this couldn't even be used in this case.
@l3u_ said in GCC 16 warnings about incomplete types in an SFINAE context:
Yeah, I know this – and I also read the big fat warnings saying "This function violates the object-oriented principle of modularity" ;-)
Also, I don't always need the sender, because the popup can be requested from a spinbox and from a radio button – but I always need the spinbox. So this couldn't even be used in this case.
Technically, you're doing the same violation since your dialog has to know which object has called it.
Usually, to keep things separated, it boils down to these two options:
- Call the dialog in a fashion where you get back the value you want and set it to whatever control makes sense (e.g. QInputDialog)
- Connect the dialog to the widget through signals and slots
If you are reusing the dialog, nothing forbids you to disconnect and reconnect your widgets again and again.
-
This bit my whole organization after we upgraded to Fedora 44 last week and got GCC 16 along for the ride.
Every single TU where we were forward declaring any class involved in a signal or slot declaration (rather than including the header directly) generates this warning. Since we run -Wall and -Werror as policy it basically borked our entire code base.IMO this is really a Qt issue since the SFINAE-on-potentially-incomplete-type trait check is in moc's autogenerated output
and QtPrivate::QMetaTypeForType::check() as opposed to user code.
Qt's documentation has long encouraged forward-declaration in QObject headers for compile-time hygiene (rightly so!) That guidance is now actively unsafe under any -Werror build on GCC 14+.Now I'm left with a choice. I either suppress the warning (which I absolutely hate), or I include the headers and take the coimpile time hit on a project with 250,000 lines of code.
It would be great if this could get fixed in the moc generation.
-
This bit my whole organization after we upgraded to Fedora 44 last week and got GCC 16 along for the ride.
Every single TU where we were forward declaring any class involved in a signal or slot declaration (rather than including the header directly) generates this warning. Since we run -Wall and -Werror as policy it basically borked our entire code base.IMO this is really a Qt issue since the SFINAE-on-potentially-incomplete-type trait check is in moc's autogenerated output
and QtPrivate::QMetaTypeForType::check() as opposed to user code.
Qt's documentation has long encouraged forward-declaration in QObject headers for compile-time hygiene (rightly so!) That guidance is now actively unsafe under any -Werror build on GCC 14+.Now I'm left with a choice. I either suppress the warning (which I absolutely hate), or I include the headers and take the coimpile time hit on a project with 250,000 lines of code.
It would be great if this could get fixed in the moc generation.
@Plastic.Jesus said in GCC 16 warnings about incomplete types in an SFINAE context:
It would be great if this could get fixed in the moc generation.
I am not affected by this issue, but understand what you are saying. But if you wish or hope for some change in moc generation you would need to open an issue at https://qt-project.atlassian.net/issues/
-
@JonB understood. Just trying to get my arms fully wrapped around the implications.
It turned out the compile-time hit was not as bad as I'd anticipated ~1-2% increase.
I think the biggest impact in the real world is going to be the ambiguity of the compile warnings (or errors if -Werror). The GCC output is only for the .moc and there is really no indication of any kind as to the actual offending header, as I believe is the genesis of this topic. The OP is digging around trying to figure out what's wrong with his class, but the actual issue is in some other QObject which uses the class in a signal or slot declaration.
Once I mess around with this a little more it'll probably be worth filing a ticket.
Thanks!
-
@JonB understood. Just trying to get my arms fully wrapped around the implications.
It turned out the compile-time hit was not as bad as I'd anticipated ~1-2% increase.
I think the biggest impact in the real world is going to be the ambiguity of the compile warnings (or errors if -Werror). The GCC output is only for the .moc and there is really no indication of any kind as to the actual offending header, as I believe is the genesis of this topic. The OP is digging around trying to figure out what's wrong with his class, but the actual issue is in some other QObject which uses the class in a signal or slot declaration.
Once I mess around with this a little more it'll probably be worth filing a ticket.
Thanks!
@Plastic.Jesus I think that including the moc generated file at the bottom of your class implementation should also fix that. Can you check ?
-
@Plastic.Jesus I think that including the moc generated file at the bottom of your class implementation should also fix that. Can you check ?
@SGaist That is a really interesting approach that I never considered. I'm going to definitely try it out - always looking to shave seconds off compile time and this could really be a big win.
We've already added the appropriate#include's through our code base to clear up the SFINAE warnings, but I'm going to run a spike to see what a full-scale test of this approach buys us.
Thanks for the tip! -
To add support for @SGaist's suggestion, #including the moc output is standard procedure for Qt autotests, and has been for a very long time. There's quite a bit of it in the libraries as well.
