forked from OSchip/llvm-project
b60896fad9
Summary: The problem: LSP specifies that Positions are between characters. Therefore when a position (or an empty range) is used to target elements of the source code, there is an ambiguity - should we look left or right of the cursor? Until now, SelectionTree resolved this to the right except in trivial cases (where there's whitespace, semicolon, or eof on the right). This meant that it's unable to e.g. out-line `int foo^()` today. Complicating this, LSP notwithstanding the cursor is *on* a character in many editors (mostly terminal-based). In these cases there's no ambiguity - we must "look right" - but there's also no way to tell in LSP. (Several features currently resolve this by using getBeginningOfIdentifier, which tries to rewind and supports end-of-identifier. But this relies on raw lexing and is limited and buggy). Precedent: well - most other languages aren't so full of densely packed symbols that we might want to target. Bias-towards-identifier works well enough. MS C++ for vscode seems to mostly use bias-toward-identifier too. The problem with this solution is it doesn't provide any way to target some things such as the constructor call in Foo^(bar()); Presented solution: When an ambiguous selection is found, we generate *both* possible selection trees. We try to run the feature on the rightward tree first, and then on the leftward tree if it fails. This is basically do-what-I-mean, the main downside is the need to do this on a feature-by-feature basis (because each feature knows what "fail" means). The most complicated instance of this is Tweaks, where the preferred selection may vary tweak-by-tweak. Wrinkles: While production behavior is pretty consistent, this introduces some inconsistency in testing, depending whether the interface we're testing is inside or outside the "retry" wrapper. In particular, for many features like Hover, the unit tests will show production behavior, while for Tweaks the harness would have to run the loop itself if we want this. Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, usaxena95, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D71345 |
||
|---|---|---|
| .. | ||
| clang-apply-replacements | ||
| clang-change-namespace | ||
| clang-doc | ||
| clang-include-fixer | ||
| clang-move | ||
| clang-query | ||
| clang-reorder-fields | ||
| clang-tidy | ||
| clangd | ||
| docs | ||
| modularize | ||
| pp-trace | ||
| test | ||
| tool-template | ||
| unittests | ||
| .arcconfig | ||
| .gitignore | ||
| CMakeLists.txt | ||
| CODE_OWNERS.TXT | ||
| LICENSE.TXT | ||
| README.txt | ||
README.txt
//===----------------------------------------------------------------------===// // Clang Tools repository //===----------------------------------------------------------------------===// Welcome to the repository of extra Clang Tools. This repository holds tools that are developed as part of the LLVM compiler infrastructure project and the Clang frontend. These tools are kept in a separate "extra" repository to allow lighter weight checkouts of the core Clang codebase. This repository is only intended to be checked out inside of a full LLVM+Clang tree, and in the 'tools/extra' subdirectory of the Clang checkout. All discussion regarding Clang, Clang-based tools, and code in this repository should be held using the standard Clang mailing lists: http://lists.llvm.org/mailman/listinfo/cfe-dev Code review for this tree should take place on the standard Clang patch and commit lists: http://lists.llvm.org/mailman/listinfo/cfe-commits If you find a bug in these tools, please file it in the LLVM bug tracker: http://llvm.org/bugs/