kadircet wrote: I am a little hesitant on the memory growth implications, as this won't be a fixed cost we have in static index, but also a significant increase in dynamic-index memory footprint (which grows proportionally with number of touched files in an editing session). We're going to pay some significant costs in a pretty common workflow, and not in a way that we can turn off (or only pay if we're getting some functionality). Hence I'd like to better understand what we're getting in practice (and if we can't get it any other way).
so some high-level questions: - is this functionality really worthwhile? - clangd doesn't support `LocationLink`s today already. do we have plans to add capabilities here? - regarding various `.range` fields in responses, including TypeHierarchyItem.range. what does it really enable for editors/lsp clients? - Why not invest into an implementation that just performs bracket matching in a file? - all of this functionality seem to just care about ~nearest enclosing brace range. parsing declarator itself is hard, braces might not be around in some edge cases where they expand from macro bodies, performing IO might be hard. - but depending on the use cases we want, this might actually be a viable alternative. as define-outline already does IO and has a fallback. type-hierarchy is likely to perform ~limited IO. providing a generic `LocationLink` capability might be hard with this approach. https://github.com/llvm/llvm-project/pull/118102 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
