[workspace] Make vendor_cxx smarter

[jwnimmer-tri]

Reduce the flapping of open/close namespaces.
No need to wrap blank lines nor preprocessor directives.

Required by #17230. Towards #17231.

---

This change is 

[jwnimmer-tri]

+@sammy-tri for feature review, please?

[sammy-tri]

+@ggould-tri for platform review (rotation)

Reviewed 2 of 2 files at r1, all commit messages.
Reviewable status: LGTM missing from assignee ggould-tri(platform) (waiting on @ggould-tri)

[ggould-tri]

; nits.

Reviewed 2 of 2 files at r1, all commit messages.
Reviewable status: 2 unresolved discussions (waiting on @jwnimmer-tri)

---

tools/workspace/vendor_cxx.py line 80 at r1 (raw file):

                flags[i] = Flag.DONT_CARE
            else:
                flags[i] = Flag.WRAP

minor: It is unsound to mark trailing matter here as WRAP; it would be better to error.
For example, as written this generates invalid c++ on the following input:

#include <mumble>

/* some commentary
*/ class fumble {

};

(Also this case is untested)
(Also also, in any case I assert that trailing matter like this cannot be soundly resolved in any line-based parse, as I can always bridge WRAP and NO_WRAP matter with a C-style comment)

---

tools/workspace/vendor_cxx.py line 125 at r1 (raw file):

                    break

    # Anything remaining is DONT_CARE buffeted by WRAP, so we'll WRAP it.

nit: Is "buffeted" the right word here? This usage is unfamiliar to me. "Buffered" perhaps? "Enclosed"? "Surrounded"? "Defiled"?

[jwnimmer-tri]

Reviewable status: 1 unresolved discussion (waiting on @ggould-tri)

---

tools/workspace/vendor_cxx.py line 80 at r1 (raw file):

Previously, ggould-tri wrote…

minor: It is unsound to mark trailing matter here as WRAP; it would be better to error.
For example, as written this generates invalid c++ on the following input:

#include <mumble>

/* some commentary
*/ class fumble {

};

(Also this case is untested)
(Also also, in any case I assert that trailing matter like this cannot be soundly resolved in any line-based parse, as I can always bridge WRAP and NO_WRAP matter with a C-style comment)

Test added, and code fixed to treat the entire block with a uniform flag.

[ggould-tri]

Reviewable status: complete! all discussions resolved, LGTM from assignees ggould-tri(platform),sammy-tri(platform) (waiting on @jwnimmer-tri)

---

tools/workspace/vendor_cxx.py line 80 at r1 (raw file):

Previously, jwnimmer-tri (Jeremy Nimmer) wrote…

Test added, and code fixed to treat the entire block with a uniform flag.

I am not seeing another revision here. Did you miss a push?

[jwnimmer-tri]

Reviewable status: 1 unresolved discussion (waiting on @ggould-tri and @sammy-tri)

---

tools/workspace/vendor_cxx.py line 80 at r1 (raw file):

Previously, ggould-tri wrote…

I am not seeing another revision here. Did you miss a push?

Indeed! Pushed now.

[ggould-tri]

I expect I could still break this with some stupid code (A C comment that starts on an include line and ends on a class def line?) , and I'll write some up if you care, but I can't think of an even slightly reasonable case to break it with for now. lgtm

Reviewed 2 of 2 files at r2, all commit messages.
Reviewable status: complete! all discussions resolved, LGTM from assignees ggould-tri(platform),sammy-tri(platform) (waiting on @jwnimmer-tri)

[jwnimmer-tri]

I'm OK to defer for now. My basic premise here is that the unit test should cover the features of the tool, so that we can modify the tool's implementation with confidence.

It's very plausible that the tool's current feature set will still fail on various new externals (or upgrades to externals), most likely due to C++ language features (e.g., forward declarations, or "extern C") moreso than parsing mistakes. As long as the compilation fails when the tool fails, we will be fine -- we'll fail-fast. Then we can revisit the tool to adapt it to the particular of that failure, rather than Gedanken-bugs.