Thanks for the writeup! Speaking as someone who’s familiar with clangd but not so much with HLSL or frontend internals like how attributes are processed, the proposed clangd changes seem generally reasonable to me.
You’re probably already mindful of this, but if something can be fixed at the AST level, that has the potential to benefit more consumers than just clangd. I do see in the decision doc that you’ve considered fixing things at the AST level, and in cases where you’ve opted not to (e.g. option A in I5) the choice seems well justified (e.g. it would involve changes with a larger scope). I’m happy to trust your and your project mentors’ judgment in these cases. I would maybe suggest filing issues to track future work where appropriate (e.g. for I5, where the doc says “Recovering the original string is documented as a known limitation and future work.”).
One question: for I2, have you considered modifying RecursiveASTVisitor itself to call TraverseAttr when traversing an AttributedStmt? If that’s feasible, it would seem like a better option to me than having this logic at the SelectionTree level.