Issue 1115 in include-what-you-use: IWYU pragma: export not effective for forward declared enum class

[notifi...@include-what-you-use.org]

New issue 1115 by justusranvier: IWYU pragma: export not effective for forward declared enum class
https://github.com/include-what-you-use/include-what-you-use/issues/1115

IWYU adds forward declarations of enum classes to every file that references the enum even if those files already includes a header that has a forward declaration marked with // IWYU pragma: export

[notifi...@include-what-you-use.org]

Comment #1 on issue 1115 by kimgr: IWYU pragma: export not effective for forward declared enum class
https://github.com/include-what-you-use/include-what-you-use/issues/1115

I don't think pragma export applies to forward declarations. Not sure how involved it would be to make that happen.

[notifi...@include-what-you-use.org]

Comment #2 on issue 1115 by justusranvier: IWYU pragma: export not effective for forward declared enum class
https://github.com/include-what-you-use/include-what-you-use/issues/1115

I found this out because I was testing the develop branch of IWYU with clang-15 and found that it's now adding forward declarations for enum classes in a few hundred files that don't need the forward declarations because they already include the header that is intended for that purpose.

If we can't use the export then we'll need hundreds of no_forward_declare pragmas.

[notifi...@include-what-you-use.org]

Comment #3 on issue 1115 by justusranvier: IWYU pragma: export not effective for forward declared enum class
https://github.com/include-what-you-use/include-what-you-use/issues/1115

Actually the feature of forward declaring an enum class the way IWYU is doing it is pretty suspect in the first place.

It's not like forward declaring a regular class where you're only making the name available - the forward declarations include the underlying type, which raises the possibility that it might get changed in one place and now all the forward declarations are wrong.

[notifi...@include-what-you-use.org]

Comment #4 on issue 1115 by kimgr: IWYU pragma: export not effective for forward declared enum class
https://github.com/include-what-you-use/include-what-you-use/issues/1115

Sounds like something @bolshakov-a would be interested in. @justusranvier Do you see any pattern to the behavior? Can you reduce it to a freestanding testcase?

[notifi...@include-what-you-use.org]

Comment #5 on issue 1115 by bolshakov-a: IWYU pragma: export not effective for forward declared enum class
https://github.com/include-what-you-use/include-what-you-use/issues/1115

Yes, it seems that IWYU don't have an option to export something but `#include`s at now. @justusranvier, the problem is mainly with source files or header files? [I have an idea](https://github.com/include-what-you-use/include-what-you-use/pull/675#issuecomment-1236344461) that forward declarations should not appear in source files at all. Maybe, it could be done though command line switch in order not to break tests...

> It's not like forward declaring a regular class where you're only making the name available - the forward declarations include the underlying type, which raises the possibility that it might get changed in one place and now all the forward declarations are wrong.

But you can forward-declare a regular class, then make it `struct` (or, likely, vice versa) and also have to change all the forward declarations. Or just change its name... My opinion is that the cases when one changes an underlying type are much less frequent as the cases when one adds a new enum item and recompiles many files which could not be recompiled. Maybe, IWYU didn't always report full enum type usages earlier, but there were inconsistencies with it.
I aggree that enum forward declarations could theoretically cause a problem: there are very specific cases when it is possible to link together files with different underlying types of single enum and to get a runtime crash. And I thought to make a command-line flag for this feature. But I think that the benefit outweights possible harm...

[notifi...@include-what-you-use.org]

Comment #6 on issue 1115 by justusranvier: IWYU pragma: export not effective for forward declared enum class
https://github.com/include-what-you-use/include-what-you-use/issues/1115

> Can you reduce it to a freestanding testcase?

A freestanding test case is difficult, but the replication conditions aren't too terribly complex.

If you build this docker image: https://github.com/Open-Transactions/docker/tree/071a270d6a8061c8fd8d33d992c88ca6a9799037/ci and then run the run-iwyu.sh script against this source tree: https://github.com/open-transactions/opentxs then you'll see the behavior.

[notifi...@include-what-you-use.org]

Comment #6 on issue 1115 by justusranvier: IWYU pragma: export not effective for forward declared enum class
https://github.com/include-what-you-use/include-what-you-use/issues/1115

> Can you reduce it to a freestanding testcase?

A freestanding test case is difficult, but the replication conditions aren't too terribly complex.

If you build [this docker image at tag ci-37.0](https://github.com/Open-Transactions/docker/tree/071a270d6a8061c8fd8d33d992c88ca6a9799037/ci) and then run the run-iwyu.sh script against [this repository's develop branch](https://github.com/open-trci-ansactions/opentxs) then you'll see the behavior.

[notifi...@include-what-you-use.org]

Comment #7 on issue 1115 by justusranvier: IWYU pragma: export not effective for forward declared enum class
https://github.com/include-what-you-use/include-what-you-use/issues/1115

> Maybe, IWYU didn't always report full enum type usages earlier, but there were inconsistencies with it.

IWYU-0.18 and lower never tried to add forward declarations for enums. I never saw this behavior until I tried out a newer IWYU commit (1d053edce2169209ad4be8fbf3031eec414ffef2) because 0.18 wasn't compiling against llvm-15.

[notifi...@include-what-you-use.org]

Comment #8 on issue 1115 by bolshakov-a: IWYU pragma: export not effective for forward declared enum class
https://github.com/include-what-you-use/include-what-you-use/issues/1115

Yes, correct. I mean IWYU suggested earlier to add `#include`s for enums, but, maybe, not always, I don't remember. As I understand from your question, you have got many fwd-decl suggestions for enums, but not suggestions to remove enum header inclusions, right? There weren't enum header reportings in IWYU-0.18? If so, it was erroneous and inconsistent behavior, because if you have mentioned an enum name in the code, you should either include the header with full enum type definition or add forward- (opaque-) declaration.

[notifi...@include-what-you-use.org]

Comment #9 on issue 1115 by justusranvier: IWYU pragma: export not effective for forward declared enum class
https://github.com/include-what-you-use/include-what-you-use/issues/1115

> If so, it was erroneous and inconsistent behavior, because if you have mentioned an enum name in the code, you should either include the header with full enum type definition or add forward- (opaque-) declaration.

The way the project is currently written I have opaque declarations in dedicated headers which all the files that do not require access to specific enum values include, and separate headers with the full definition which files that need specific values include.

This way if for some reason the underlying type needs to change then it only need to be changed in exactly two headers, not every place that mentions the enum.

It would be great if I could preserve this behavior while still using IWYU and the export pragma seems like the logical way to do it. As it stands now if I want to upgrade past IWYU-0.18 I'll need to add dozens to hundreds of no_forward_declare pragmas to my code first.

[notifi...@include-what-you-use.org]

Comment #9 on issue 1115 by justusranvier: IWYU pragma: export not effective for forward declared enum class
https://github.com/include-what-you-use/include-what-you-use/issues/1115

> If so, it was erroneous and inconsistent behavior, because if you have mentioned an enum name in the code, you should either include the header with full enum type definition or add forward- (opaque-) declaration.

The way the project is currently written I have opaque declarations in dedicated headers which all the files that do not require access to specific enum values include, and separate headers with the full definition which files that need specific values include.

This way if for some reason the underlying type needs to change then it only need to be changed in exactly two headers, not every place that mentions the enum.

IWYU-0.18 is mostly fine with this configuration, except that in a few places I have to use a no_include pragma to prevent it from pulling in the full definition header where it is not necessary.