This is an archive of the discontinued LLVM Phabricator instance.

[clangd] NFC: Only pass ASTContext and TokenBuffer in getFoldingRanges API
AbandonedPublic

Authored by kbobyrev on Nov 1 2020, 11:55 PM.

Details

Diff Detail

Event Timeline

kbobyrev created this revision.Nov 1 2020, 11:55 PM
kbobyrev requested review of this revision.Nov 1 2020, 11:55 PM

This doesn't feel quite right to me - we're going to need to get PP conditional regions, include blocks etc from the ParsedAST (they're not in ASTContext).
My sense is that we'll need a fairly random subset of ParsedAST, and so ParsedAST is a reasonable abstraction unless it's hard to produce for tests. But it isn't!

What's the motivation for this change?

This doesn't feel quite right to me - we're going to need to get PP conditional regions, include blocks etc from the ParsedAST (they're not in ASTContext).
My sense is that we'll need a fairly random subset of ParsedAST, and so ParsedAST is a reasonable abstraction unless it's hard to produce for tests. But it isn't!

What's the motivation for this change?

Aww that comment is regarding syntax::buildSyntaxTree weren't you? I thought this was about getFoldingRanges API... Sorry.

This doesn't feel quite right to me - we're going to need to get PP conditional regions, include blocks etc from the ParsedAST (they're not in ASTContext).
My sense is that we'll need a fairly random subset of ParsedAST, and so ParsedAST is a reasonable abstraction unless it's hard to produce for tests. But it isn't!

What's the motivation for this change?

Aww that comment is regarding syntax::buildSyntaxTree weren't you? I thought this was about getFoldingRanges API... Sorry.

Oops, sorry - yes :-(

My the point there was that the traversal roots for building the syntax tree are the ASTContext's traversal scope, which defaults to TUDecl, so passing in TUDecl is misleading there.

kbobyrev abandoned this revision.Nov 3 2020, 1:26 AM