On 5/28/22 20:21, Peter Dimov via Boost wrote:
Soronel Haetir wrote:
Something I would consider useful from a compiler standpoint would be able to control warnings on a path basis. That is, if it's part of the system includes (along with other customizable directories), a different, much more forgiving set of warnings is in effect. Particularly for style warnings like NULL vs nullptr vs 0. Only code that is explicitly part of my current target (whatever that means in the given environment) should have stylistic warnings in effect.
Even MSVC's #pragma warning doesn't give that kind of control, it can reduce warnings (or disable particular warnings) for a block of includes, but has nothing to do with the paths the files come from.
That's not as useful as it seems because the header is often included multiple times using different paths and because of include guards only the first path matters, which usually has nothing to do with the path that would have led to the warning were those previous includes not present.
I think the idea is to associate warning settings with a set of files in the filesystem (i.e. inodes), not the paths to them. Somewhat similar to how `#pragma once` works. Although there are caveats with `#pragma once`, most of the time it works rather reliably, so maybe not such a bad idea. Though I have a hard time to imagine how such heterogeneous settings would be expressed.