[clang] [clang][modules] Headers meant to be included multiple times can be completely invisible in clang module builds (PR #83660)

[Ian Anderson via cfe-commits]

ian-twilightcoder wrote:

> > Sometimes it does confuse clang, at least I saw problems with a `typedef enum` when I made an include-once header `textual`.
> 
> Ok, I see. I would just consider it a bug, not a design decision.
> 
> > That's correct. `#import` is an external source - often it comes from the users of the header and not the author, and the users might not be consistent with each other. `textual` comes from the author and a much stronger indicator of intent.
> 
> Hmm, I need to think more about it. Usually I prefer for modular builds to act like non-modular as it minimizes the surprises and allows to have a portable code. But I haven't really considered the implications of such preference.

Yes generally, but modules build more headers than non-modular builds, nothing we can do about that.

> I see why you prefer to give more priority to `textual`. To give a different perspective, what if a developer wants to use a newer library, for example, ncurses. The rest of SDK expects an older version and the developer might need to do some header gymnastics to make it work. So there are cases when developers need to go against library author's intent. I'm thinking that library authors aren't able to predict all the ways their library is used, so it is useful to have some flexibility around that, even at the cost of misusing the library. But this is a general opinion, I don't have specific data about the needs to tweak libraries or the risks of a library misuse. So the opinion isn't particularly strong.

That one seems like an edge case, and using `#import` wouldn't necessarily help you because the SDK module could build first before your `#import` is seen.

https://github.com/llvm/llvm-project/pull/83660