It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie on the #hackers channel in Chat (don't just cc him here, he won't see it! He's on Discord!).

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

test-exempt: only affects comments

but this is totally testable, actually. @gspencergoog did a ton of work to make all the framework tests get fully analyzed and even gave us the ability to give them unit tests, if i'm not mistaken. maybe we can extend that logic to this repo?

Was just asking about exactly that. Would be great to avoid any more sneaking in. This was an "oh hey there are new keywords there" while fixing an "oh hey there are std::unique_ptr(new ...) where there could be std::make_unique here" noticed while pair-reading some code for totally un-new-related reasons. Would love to get this analyzed/linted.

This is the only kind of code we don't analyze, because there's not enough context to make it analyzable. These can't be analyzed because these blocks are meant to have an arbitrarily small snippet of code in them, including "bad" examples where the code isn't meant to analyze cleanly.

The best solution here would be to convert them to {@tool snippet} blocks, which would put a blue box around them, but would cause them to be analyzed with the rest of the sample code.

Perhaps we need a new kind of "@tool" configuration that will cause the wrapped code to be analyzed, but not treated terribly differently (visually) from the bare markdown escapes.

@Hixie