Make C/C++/ObjC include directive scanning pattern more strict

[Lastique]

Proposed changes

1. Require that the directive is at the beginning of a line, sans leading spaces.
2. Require that the header name is not empty.

This eliminates majority of comments that look like #include directives. One practical example is a comment in Boost.Wave that has #include <> and #include "" in its body.

This issue came up during Boost 1.85 release preparation.

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no api changes)
• Documentation content changes
• Other (please describe):

Checklist

• I searched the discussions
• I searched the closed and open issues
• I read the contribution guidelines
• I added myself to the copyright attributions for significant changes
• I checked that tests pass locally with my changes
• I added tests that prove my fix is effective or that my feature works
• I added necessary documentation (if appropriate)

[teeks99]

I wanted to ping this, as I believe it blocks the 1.85 release.

[grafikrobot]

@teeks99 it doesn't block the release as the error output does not affect actual operation. It's just unsightly, AFAIK.

[teeks99]

it doesn't block the release as the error output does not affect actual operation. It's just unsightly, AFAIK.

I guess that is true for msvc-14.1+, however for msvc-14.0 that is less clear. This appears (and I'm not clear what I'm looking at, so maybe this is just a noisy log) to cause an issue in wave. log

At the very least, this makes it annoyingly hard to see if there were other errors during the build.

Regardless of its blocking status, it would definitely be nice to get into 1.85. Is this the plan?

[grafikrobot]

it doesn't block the release as the error output does not affect actual operation. It's just unsightly, AFAIK.

I guess that is true for msvc-14.1+, however for msvc-14.0 that is less clear. This appears (and I'm not clear what I'm looking at, so maybe this is just a noisy log) to cause an issue in wave. log

In that, it still completes building everything without build errors of any targets (at the end it doesn't say it failed or skipped targets).

At the very least, this makes it annoyingly hard to see if there were other errors during the build.

Right.

Regardless of its blocking status, it would definitely be nice to get into 1.85. Is this the plan?

Working on it.