[clang] [clang][Lex] add -Wnonportable-include-path-separator (PR #186770)

[Aaron Ballman via cfe-commits]

================
@@ -380,6 +380,9 @@ def pp_nonportable_path : NonportablePath,
   InGroup<DiagGroup<"nonportable-include-path">>;
 def pp_nonportable_system_path : NonportablePath, DefaultIgnore,
   InGroup<DiagGroup<"nonportable-system-include-path">>;
+def pp_nonportable_path_separator : Warning<
+  "non-portable path to file '%0'; specified path contains backslashes">,
+  DefaultIgnore, InGroup<DiagGroup<"nonportable-include-path-separator">>;
----------------
AaronBallman wrote:

> I don't think it should necessarily be on by default for non-Windows targets

For background: we generally don't take new diagnostics that are off-by-default because of how much evidence we have that they don't get enabled often enough to warrant the effort. So we're always trying to find ways to get diagnostics to have a sufficiently low false-positive rate so that we can enable them by default.

This diagnostic is a tough one though -- I can see people wanting to have some way to know about a non-portable include path but that diagnostic would be more apt to false positives on platforms with a backslash separator. So I think it's also fine for us to have it but off-by-default.

> Am I right to think that if nonportable-include-path-separator is always off by default, there's no use in tying it to nonportable-include-path? (I'm not familiar with this, but I saw that DiagGroups can have subgroups and I guess that's what you mean?)

Subgroups was what I was after, yes. We have a group for non-portable include paths and this new diagnostic is a new kind of non-portable include path. So if a user does `-Weverything -Wno-nonportable-include-path` I think they'd be surprised if they got diagnostics about a nonportable include path with backslash separators.

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