2017-12-19 20:23:48 +08:00
|
|
|
//===--- SourceCode.h - Manipulating source code as strings -----*- C++ -*-===//
|
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2017-12-19 20:23:48 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
#include "SourceCode.h"
|
|
|
|
|
2019-05-06 18:25:10 +08:00
|
|
|
#include "FuzzyMatch.h"
|
[clangd] locateMacroAt handles patched macros
Summary: Depends on D79992.
This patch changes locateMacroAt to perform #line directive substitution
for macro identifier locations.
We first check whether a location is inside a file included through
built-in header. If so we check whether line directive maps it back to
the main file, and afterwards use TokenBuffers to find exact location of
the identifier on the line.
Instead of performing the mapping in locateMacroAt, we could also store
a mapping inside the ParsedAST whenever we use a patched preamble. But
that would imply adding more responsibility to ParsedAST and paying for
the mapping even when it is not going to be used.
====
Go-To-Definition:
Later on these locations are used for serving go-to-definition requests,
this enables jumping to definition inside the preamble section in
presence of patched macros.
=====
Go-To-Refs:
Macro references in main file are collected separetely and stored as a
map from macro's symbol id to reference ranges. Those ranges are
computed inside PPCallbacks, hence we don't have access to TokenBuffer.
In presence of preamble patch, any reference to a macro inside the
preamble section will unfortunately have the wrong range. They'll point
into the patch rather than the main file. Hence during findReferences,
we won't get any ranges reported for those.
Fixing those requires:
- Lexing the preamble section to figure out "real range" of a patched
macro definition
- Postponing range/location calculations until a later step in which we
have access to tokenbuffers.
This patch trades some accuracy in favor of code complexity. We don't do
any patching for references inside the preamble patch but get any
reference inside the main file for free.
Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D80198
2020-05-14 18:26:47 +08:00
|
|
|
#include "Preamble.h"
|
2019-03-28 01:47:49 +08:00
|
|
|
#include "Protocol.h"
|
2019-09-09 20:28:44 +08:00
|
|
|
#include "refactor/Tweak.h"
|
[clangd] Move non-clang base pieces into separate support/ lib. NFCI
Summary:
This enforces layering, reduces a sprawling clangd/ directory, and makes life
easier for embedders.
Reviewers: kbobyrev
Subscribers: mgorny, ilya-biryukov, javed.absar, MaskRay, jkorous, arphaman, jfb, kadircet, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D79014
2020-04-28 23:49:17 +08:00
|
|
|
#include "support/Context.h"
|
|
|
|
#include "support/Logger.h"
|
2020-06-17 17:53:32 +08:00
|
|
|
#include "support/Threading.h"
|
2018-07-06 03:35:01 +08:00
|
|
|
#include "clang/AST/ASTContext.h"
|
2019-07-12 19:42:31 +08:00
|
|
|
#include "clang/Basic/LangOptions.h"
|
|
|
|
#include "clang/Basic/SourceLocation.h"
|
2018-02-21 10:39:08 +08:00
|
|
|
#include "clang/Basic/SourceManager.h"
|
2019-04-26 15:45:49 +08:00
|
|
|
#include "clang/Basic/TokenKinds.h"
|
[clangd] Add isHeaderFile helper.
Summary:
we have a few places using `ASTCtx.getLangOpts().IsHeaderFile` to
determine a header file, but it relies on "-x c-header" compiler flag,
if the compilation command doesn't have this flag, we will get a false
positive. We are encountering this issue in bazel build system.
To solve this problem, we infer the file from file name, actual changes will
come in follow-ups.
Reviewers: sammccall
Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D70235
2019-11-13 23:30:07 +08:00
|
|
|
#include "clang/Driver/Types.h"
|
2019-04-26 15:45:49 +08:00
|
|
|
#include "clang/Format/Format.h"
|
2018-07-06 03:35:01 +08:00
|
|
|
#include "clang/Lex/Lexer.h"
|
2019-07-01 17:26:48 +08:00
|
|
|
#include "clang/Lex/Preprocessor.h"
|
2019-09-25 17:35:38 +08:00
|
|
|
#include "clang/Lex/Token.h"
|
2019-09-09 20:28:44 +08:00
|
|
|
#include "clang/Tooling/Core/Replacement.h"
|
2020-02-27 22:10:54 +08:00
|
|
|
#include "clang/Tooling/Syntax/Tokens.h"
|
2019-09-09 20:28:44 +08:00
|
|
|
#include "llvm/ADT/ArrayRef.h"
|
2019-02-01 05:30:05 +08:00
|
|
|
#include "llvm/ADT/None.h"
|
2019-09-25 17:35:38 +08:00
|
|
|
#include "llvm/ADT/STLExtras.h"
|
2019-04-26 15:45:49 +08:00
|
|
|
#include "llvm/ADT/StringExtras.h"
|
2019-09-09 20:28:44 +08:00
|
|
|
#include "llvm/ADT/StringMap.h"
|
2019-02-01 05:30:05 +08:00
|
|
|
#include "llvm/ADT/StringRef.h"
|
2019-05-06 18:25:10 +08:00
|
|
|
#include "llvm/Support/Compiler.h"
|
Make positionToOffset return llvm::Expected<size_t>
Summary:
To implement incremental document syncing, we want to verify that the
ranges provided by the front-end are valid. Currently, positionToOffset
deals with invalid Positions by returning 0 or Code.size(), which are
two valid offsets. Instead, return an llvm:Expected<size_t> with an
error if the position is invalid.
According to the LSP, if the character value exceeds the number of
characters of the given line, it should default back to the end of the
line. It makes sense in some contexts to have this behavior, and does
not in other contexts. The AllowColumnsBeyondLineLength parameter
allows to decide what to do in that case, default back to the end of the
line, or return an error.
Reviewers: ilya-biryukov
Subscribers: klimek, ilya-biryukov, jkorous-apple, ioeric, cfe-commits
Differential Revision: https://reviews.llvm.org/D44673
llvm-svn: 328100
2018-03-21 22:36:46 +08:00
|
|
|
#include "llvm/Support/Errc.h"
|
|
|
|
#include "llvm/Support/Error.h"
|
2019-03-28 22:37:51 +08:00
|
|
|
#include "llvm/Support/ErrorHandling.h"
|
2019-09-09 20:28:44 +08:00
|
|
|
#include "llvm/Support/LineIterator.h"
|
|
|
|
#include "llvm/Support/MemoryBuffer.h"
|
2018-07-06 03:35:01 +08:00
|
|
|
#include "llvm/Support/Path.h"
|
2019-09-09 20:28:44 +08:00
|
|
|
#include "llvm/Support/SHA1.h"
|
|
|
|
#include "llvm/Support/VirtualFileSystem.h"
|
[clangd] Use xxhash instead of SHA1 for background index file digests.
Summary:
Currently SHA1 is about 10% of our CPU, this patch reduces it to ~1%.
xxhash is a well-defined (stable) non-cryptographic hash optimized for
fast checksums (like crc32).
Collisions shouldn't be a problem, despite the reduced length:
- for actual file content (used to invalidate bg index shards), there
are only two versions that can collide (new shard and old shard).
- for file paths in bg index shard filenames, we would need 2^32 files
with the same filename to expect a collision. Imperfect hashing may
reduce this a bit but it's well beyond what's plausible.
This will invalidate shards on disk (as usual; I bumped the version),
but this time the filenames are changing so the old files will stick
around :-( So this is more expensive than the usual bump, but would be
good to land before the v9 branch when everyone will start using bg index.
Reviewers: kadircet
Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D64306
llvm-svn: 365311
2019-07-08 19:33:17 +08:00
|
|
|
#include "llvm/Support/xxhash.h"
|
2019-04-26 15:45:49 +08:00
|
|
|
#include <algorithm>
|
2019-09-25 17:35:38 +08:00
|
|
|
#include <cstddef>
|
|
|
|
#include <string>
|
|
|
|
#include <vector>
|
2018-02-21 10:39:08 +08:00
|
|
|
|
2017-12-19 20:23:48 +08:00
|
|
|
namespace clang {
|
|
|
|
namespace clangd {
|
|
|
|
|
[clangd] Fix unicode handling, using UTF-16 where LSP requires it.
Summary:
The Language Server Protocol unfortunately mandates that locations in files
be represented by line/column pairs, where the "column" is actually an index
into the UTF-16-encoded text of the line.
(This is because VSCode is written in JavaScript, which is UTF-16-native).
Internally clangd treats source files at UTF-8, the One True Encoding, and
generally deals with byte offsets (though there are exceptions).
Before this patch, conversions between offsets and LSP Position pretended
that Position.character was UTF-8 bytes, which is only true for ASCII lines.
Now we examine the text to convert correctly (but don't actually need to
transcode it, due to some nice details of the encodings).
The updated functions in SourceCode are the blessed way to interact with
the Position.character field, and anything else is likely to be wrong.
So I also updated the other accesses:
- CodeComplete needs a "clang-style" line/column, with column in utf-8 bytes.
This is now converted via Position -> offset -> clang line/column
(a new function is added to SourceCode.h for the second conversion).
- getBeginningOfIdentifier skipped backwards in UTF-16 space, which is will
behave badly when it splits a surrogate pair. Skipping backwards in UTF-8
coordinates gives the lexer a fighting chance of getting this right.
While here, I clarified(?) the logic comments, fixed a bug with identifiers
containing digits, simplified the signature slightly and added a test.
This seems likely to cause problems with editors that have the same bug, and
treat the protocol as if columns are UTF-8 bytes. But we can find and fix those.
Reviewers: hokein
Subscribers: klimek, ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D46035
llvm-svn: 331029
2018-04-27 19:59:28 +08:00
|
|
|
// Here be dragons. LSP positions use columns measured in *UTF-16 code units*!
|
|
|
|
// Clangd uses UTF-8 and byte-offsets internally, so conversion is nontrivial.
|
|
|
|
|
|
|
|
// Iterates over unicode codepoints in the (UTF-8) string. For each,
|
|
|
|
// invokes CB(UTF-8 length, UTF-16 length), and breaks if it returns true.
|
|
|
|
// Returns true if CB returned true, false if we hit the end of string.
|
2020-06-10 12:40:00 +08:00
|
|
|
//
|
|
|
|
// If the string is not valid UTF-8, we log this error and "decode" the
|
|
|
|
// text in some arbitrary way. This is pretty sad, but this tends to happen deep
|
|
|
|
// within indexing of headers where clang misdetected the encoding, and
|
|
|
|
// propagating the error all the way back up is (probably?) not be worth it.
|
[clangd] Fix unicode handling, using UTF-16 where LSP requires it.
Summary:
The Language Server Protocol unfortunately mandates that locations in files
be represented by line/column pairs, where the "column" is actually an index
into the UTF-16-encoded text of the line.
(This is because VSCode is written in JavaScript, which is UTF-16-native).
Internally clangd treats source files at UTF-8, the One True Encoding, and
generally deals with byte offsets (though there are exceptions).
Before this patch, conversions between offsets and LSP Position pretended
that Position.character was UTF-8 bytes, which is only true for ASCII lines.
Now we examine the text to convert correctly (but don't actually need to
transcode it, due to some nice details of the encodings).
The updated functions in SourceCode are the blessed way to interact with
the Position.character field, and anything else is likely to be wrong.
So I also updated the other accesses:
- CodeComplete needs a "clang-style" line/column, with column in utf-8 bytes.
This is now converted via Position -> offset -> clang line/column
(a new function is added to SourceCode.h for the second conversion).
- getBeginningOfIdentifier skipped backwards in UTF-16 space, which is will
behave badly when it splits a surrogate pair. Skipping backwards in UTF-8
coordinates gives the lexer a fighting chance of getting this right.
While here, I clarified(?) the logic comments, fixed a bug with identifiers
containing digits, simplified the signature slightly and added a test.
This seems likely to cause problems with editors that have the same bug, and
treat the protocol as if columns are UTF-8 bytes. But we can find and fix those.
Reviewers: hokein
Subscribers: klimek, ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D46035
llvm-svn: 331029
2018-04-27 19:59:28 +08:00
|
|
|
template <typename Callback>
|
2019-01-07 23:45:19 +08:00
|
|
|
static bool iterateCodepoints(llvm::StringRef U8, const Callback &CB) {
|
2020-06-10 12:40:00 +08:00
|
|
|
bool LoggedInvalid = false;
|
2019-03-28 22:37:51 +08:00
|
|
|
// A codepoint takes two UTF-16 code unit if it's astral (outside BMP).
|
|
|
|
// Astral codepoints are encoded as 4 bytes in UTF-8, starting with 11110xxx.
|
[clangd] Fix unicode handling, using UTF-16 where LSP requires it.
Summary:
The Language Server Protocol unfortunately mandates that locations in files
be represented by line/column pairs, where the "column" is actually an index
into the UTF-16-encoded text of the line.
(This is because VSCode is written in JavaScript, which is UTF-16-native).
Internally clangd treats source files at UTF-8, the One True Encoding, and
generally deals with byte offsets (though there are exceptions).
Before this patch, conversions between offsets and LSP Position pretended
that Position.character was UTF-8 bytes, which is only true for ASCII lines.
Now we examine the text to convert correctly (but don't actually need to
transcode it, due to some nice details of the encodings).
The updated functions in SourceCode are the blessed way to interact with
the Position.character field, and anything else is likely to be wrong.
So I also updated the other accesses:
- CodeComplete needs a "clang-style" line/column, with column in utf-8 bytes.
This is now converted via Position -> offset -> clang line/column
(a new function is added to SourceCode.h for the second conversion).
- getBeginningOfIdentifier skipped backwards in UTF-16 space, which is will
behave badly when it splits a surrogate pair. Skipping backwards in UTF-8
coordinates gives the lexer a fighting chance of getting this right.
While here, I clarified(?) the logic comments, fixed a bug with identifiers
containing digits, simplified the signature slightly and added a test.
This seems likely to cause problems with editors that have the same bug, and
treat the protocol as if columns are UTF-8 bytes. But we can find and fix those.
Reviewers: hokein
Subscribers: klimek, ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D46035
llvm-svn: 331029
2018-04-27 19:59:28 +08:00
|
|
|
for (size_t I = 0; I < U8.size();) {
|
|
|
|
unsigned char C = static_cast<unsigned char>(U8[I]);
|
|
|
|
if (LLVM_LIKELY(!(C & 0x80))) { // ASCII character.
|
|
|
|
if (CB(1, 1))
|
|
|
|
return true;
|
|
|
|
++I;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
// This convenient property of UTF-8 holds for all non-ASCII characters.
|
2019-01-07 23:45:19 +08:00
|
|
|
size_t UTF8Length = llvm::countLeadingOnes(C);
|
[clangd] Fix unicode handling, using UTF-16 where LSP requires it.
Summary:
The Language Server Protocol unfortunately mandates that locations in files
be represented by line/column pairs, where the "column" is actually an index
into the UTF-16-encoded text of the line.
(This is because VSCode is written in JavaScript, which is UTF-16-native).
Internally clangd treats source files at UTF-8, the One True Encoding, and
generally deals with byte offsets (though there are exceptions).
Before this patch, conversions between offsets and LSP Position pretended
that Position.character was UTF-8 bytes, which is only true for ASCII lines.
Now we examine the text to convert correctly (but don't actually need to
transcode it, due to some nice details of the encodings).
The updated functions in SourceCode are the blessed way to interact with
the Position.character field, and anything else is likely to be wrong.
So I also updated the other accesses:
- CodeComplete needs a "clang-style" line/column, with column in utf-8 bytes.
This is now converted via Position -> offset -> clang line/column
(a new function is added to SourceCode.h for the second conversion).
- getBeginningOfIdentifier skipped backwards in UTF-16 space, which is will
behave badly when it splits a surrogate pair. Skipping backwards in UTF-8
coordinates gives the lexer a fighting chance of getting this right.
While here, I clarified(?) the logic comments, fixed a bug with identifiers
containing digits, simplified the signature slightly and added a test.
This seems likely to cause problems with editors that have the same bug, and
treat the protocol as if columns are UTF-8 bytes. But we can find and fix those.
Reviewers: hokein
Subscribers: klimek, ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D46035
llvm-svn: 331029
2018-04-27 19:59:28 +08:00
|
|
|
// 0xxx is ASCII, handled above. 10xxx is a trailing byte, invalid here.
|
2020-06-10 12:40:00 +08:00
|
|
|
// 11111xxx is not valid UTF-8 at all, maybe some ISO-8859-*.
|
|
|
|
if (LLVM_UNLIKELY(UTF8Length < 2 || UTF8Length > 4)) {
|
|
|
|
if (!LoggedInvalid) {
|
|
|
|
elog("File has invalid UTF-8 near offset {0}: {1}", I, llvm::toHex(U8));
|
|
|
|
LoggedInvalid = true;
|
|
|
|
}
|
|
|
|
// We can't give a correct result, but avoid returning something wild.
|
|
|
|
// Pretend this is a valid ASCII byte, for lack of better options.
|
|
|
|
// (Too late to get ISO-8859-* right, we've skipped some bytes already).
|
|
|
|
if (CB(1, 1))
|
|
|
|
return true;
|
|
|
|
++I;
|
|
|
|
continue;
|
|
|
|
}
|
[clangd] Fix unicode handling, using UTF-16 where LSP requires it.
Summary:
The Language Server Protocol unfortunately mandates that locations in files
be represented by line/column pairs, where the "column" is actually an index
into the UTF-16-encoded text of the line.
(This is because VSCode is written in JavaScript, which is UTF-16-native).
Internally clangd treats source files at UTF-8, the One True Encoding, and
generally deals with byte offsets (though there are exceptions).
Before this patch, conversions between offsets and LSP Position pretended
that Position.character was UTF-8 bytes, which is only true for ASCII lines.
Now we examine the text to convert correctly (but don't actually need to
transcode it, due to some nice details of the encodings).
The updated functions in SourceCode are the blessed way to interact with
the Position.character field, and anything else is likely to be wrong.
So I also updated the other accesses:
- CodeComplete needs a "clang-style" line/column, with column in utf-8 bytes.
This is now converted via Position -> offset -> clang line/column
(a new function is added to SourceCode.h for the second conversion).
- getBeginningOfIdentifier skipped backwards in UTF-16 space, which is will
behave badly when it splits a surrogate pair. Skipping backwards in UTF-8
coordinates gives the lexer a fighting chance of getting this right.
While here, I clarified(?) the logic comments, fixed a bug with identifiers
containing digits, simplified the signature slightly and added a test.
This seems likely to cause problems with editors that have the same bug, and
treat the protocol as if columns are UTF-8 bytes. But we can find and fix those.
Reviewers: hokein
Subscribers: klimek, ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D46035
llvm-svn: 331029
2018-04-27 19:59:28 +08:00
|
|
|
I += UTF8Length; // Skip over all trailing bytes.
|
|
|
|
// A codepoint takes two UTF-16 code unit if it's astral (outside BMP).
|
|
|
|
// Astral codepoints are encoded as 4 bytes in UTF-8 (11110xxx ...)
|
|
|
|
if (CB(UTF8Length, UTF8Length == 4 ? 2 : 1))
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2019-03-28 22:37:51 +08:00
|
|
|
// Returns the byte offset into the string that is an offset of \p Units in
|
|
|
|
// the specified encoding.
|
|
|
|
// Conceptually, this converts to the encoding, truncates to CodeUnits,
|
|
|
|
// converts back to UTF-8, and returns the length in bytes.
|
|
|
|
static size_t measureUnits(llvm::StringRef U8, int Units, OffsetEncoding Enc,
|
|
|
|
bool &Valid) {
|
|
|
|
Valid = Units >= 0;
|
|
|
|
if (Units <= 0)
|
|
|
|
return 0;
|
[clangd] Fix unicode handling, using UTF-16 where LSP requires it.
Summary:
The Language Server Protocol unfortunately mandates that locations in files
be represented by line/column pairs, where the "column" is actually an index
into the UTF-16-encoded text of the line.
(This is because VSCode is written in JavaScript, which is UTF-16-native).
Internally clangd treats source files at UTF-8, the One True Encoding, and
generally deals with byte offsets (though there are exceptions).
Before this patch, conversions between offsets and LSP Position pretended
that Position.character was UTF-8 bytes, which is only true for ASCII lines.
Now we examine the text to convert correctly (but don't actually need to
transcode it, due to some nice details of the encodings).
The updated functions in SourceCode are the blessed way to interact with
the Position.character field, and anything else is likely to be wrong.
So I also updated the other accesses:
- CodeComplete needs a "clang-style" line/column, with column in utf-8 bytes.
This is now converted via Position -> offset -> clang line/column
(a new function is added to SourceCode.h for the second conversion).
- getBeginningOfIdentifier skipped backwards in UTF-16 space, which is will
behave badly when it splits a surrogate pair. Skipping backwards in UTF-8
coordinates gives the lexer a fighting chance of getting this right.
While here, I clarified(?) the logic comments, fixed a bug with identifiers
containing digits, simplified the signature slightly and added a test.
This seems likely to cause problems with editors that have the same bug, and
treat the protocol as if columns are UTF-8 bytes. But we can find and fix those.
Reviewers: hokein
Subscribers: klimek, ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D46035
llvm-svn: 331029
2018-04-27 19:59:28 +08:00
|
|
|
size_t Result = 0;
|
2019-03-28 22:37:51 +08:00
|
|
|
switch (Enc) {
|
|
|
|
case OffsetEncoding::UTF8:
|
|
|
|
Result = Units;
|
|
|
|
break;
|
|
|
|
case OffsetEncoding::UTF16:
|
|
|
|
Valid = iterateCodepoints(U8, [&](int U8Len, int U16Len) {
|
|
|
|
Result += U8Len;
|
|
|
|
Units -= U16Len;
|
|
|
|
return Units <= 0;
|
|
|
|
});
|
|
|
|
if (Units < 0) // Offset in the middle of a surrogate pair.
|
|
|
|
Valid = false;
|
|
|
|
break;
|
|
|
|
case OffsetEncoding::UTF32:
|
|
|
|
Valid = iterateCodepoints(U8, [&](int U8Len, int U16Len) {
|
|
|
|
Result += U8Len;
|
|
|
|
Units--;
|
|
|
|
return Units <= 0;
|
|
|
|
});
|
|
|
|
break;
|
|
|
|
case OffsetEncoding::UnsupportedEncoding:
|
|
|
|
llvm_unreachable("unsupported encoding");
|
|
|
|
}
|
[clangd] Fix unicode handling, using UTF-16 where LSP requires it.
Summary:
The Language Server Protocol unfortunately mandates that locations in files
be represented by line/column pairs, where the "column" is actually an index
into the UTF-16-encoded text of the line.
(This is because VSCode is written in JavaScript, which is UTF-16-native).
Internally clangd treats source files at UTF-8, the One True Encoding, and
generally deals with byte offsets (though there are exceptions).
Before this patch, conversions between offsets and LSP Position pretended
that Position.character was UTF-8 bytes, which is only true for ASCII lines.
Now we examine the text to convert correctly (but don't actually need to
transcode it, due to some nice details of the encodings).
The updated functions in SourceCode are the blessed way to interact with
the Position.character field, and anything else is likely to be wrong.
So I also updated the other accesses:
- CodeComplete needs a "clang-style" line/column, with column in utf-8 bytes.
This is now converted via Position -> offset -> clang line/column
(a new function is added to SourceCode.h for the second conversion).
- getBeginningOfIdentifier skipped backwards in UTF-16 space, which is will
behave badly when it splits a surrogate pair. Skipping backwards in UTF-8
coordinates gives the lexer a fighting chance of getting this right.
While here, I clarified(?) the logic comments, fixed a bug with identifiers
containing digits, simplified the signature slightly and added a test.
This seems likely to cause problems with editors that have the same bug, and
treat the protocol as if columns are UTF-8 bytes. But we can find and fix those.
Reviewers: hokein
Subscribers: klimek, ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D46035
llvm-svn: 331029
2018-04-27 19:59:28 +08:00
|
|
|
// Don't return an out-of-range index if we overran.
|
2019-03-28 22:37:51 +08:00
|
|
|
if (Result > U8.size()) {
|
|
|
|
Valid = false;
|
|
|
|
return U8.size();
|
|
|
|
}
|
|
|
|
return Result;
|
[clangd] Fix unicode handling, using UTF-16 where LSP requires it.
Summary:
The Language Server Protocol unfortunately mandates that locations in files
be represented by line/column pairs, where the "column" is actually an index
into the UTF-16-encoded text of the line.
(This is because VSCode is written in JavaScript, which is UTF-16-native).
Internally clangd treats source files at UTF-8, the One True Encoding, and
generally deals with byte offsets (though there are exceptions).
Before this patch, conversions between offsets and LSP Position pretended
that Position.character was UTF-8 bytes, which is only true for ASCII lines.
Now we examine the text to convert correctly (but don't actually need to
transcode it, due to some nice details of the encodings).
The updated functions in SourceCode are the blessed way to interact with
the Position.character field, and anything else is likely to be wrong.
So I also updated the other accesses:
- CodeComplete needs a "clang-style" line/column, with column in utf-8 bytes.
This is now converted via Position -> offset -> clang line/column
(a new function is added to SourceCode.h for the second conversion).
- getBeginningOfIdentifier skipped backwards in UTF-16 space, which is will
behave badly when it splits a surrogate pair. Skipping backwards in UTF-8
coordinates gives the lexer a fighting chance of getting this right.
While here, I clarified(?) the logic comments, fixed a bug with identifiers
containing digits, simplified the signature slightly and added a test.
This seems likely to cause problems with editors that have the same bug, and
treat the protocol as if columns are UTF-8 bytes. But we can find and fix those.
Reviewers: hokein
Subscribers: klimek, ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D46035
llvm-svn: 331029
2018-04-27 19:59:28 +08:00
|
|
|
}
|
|
|
|
|
2019-03-28 01:47:49 +08:00
|
|
|
Key<OffsetEncoding> kCurrentOffsetEncoding;
|
2019-03-28 22:37:51 +08:00
|
|
|
static OffsetEncoding lspEncoding() {
|
2019-03-28 01:47:49 +08:00
|
|
|
auto *Enc = Context::current().get(kCurrentOffsetEncoding);
|
2019-03-28 22:37:51 +08:00
|
|
|
return Enc ? *Enc : OffsetEncoding::UTF16;
|
2019-03-28 01:47:49 +08:00
|
|
|
}
|
|
|
|
|
[clangd] Fix unicode handling, using UTF-16 where LSP requires it.
Summary:
The Language Server Protocol unfortunately mandates that locations in files
be represented by line/column pairs, where the "column" is actually an index
into the UTF-16-encoded text of the line.
(This is because VSCode is written in JavaScript, which is UTF-16-native).
Internally clangd treats source files at UTF-8, the One True Encoding, and
generally deals with byte offsets (though there are exceptions).
Before this patch, conversions between offsets and LSP Position pretended
that Position.character was UTF-8 bytes, which is only true for ASCII lines.
Now we examine the text to convert correctly (but don't actually need to
transcode it, due to some nice details of the encodings).
The updated functions in SourceCode are the blessed way to interact with
the Position.character field, and anything else is likely to be wrong.
So I also updated the other accesses:
- CodeComplete needs a "clang-style" line/column, with column in utf-8 bytes.
This is now converted via Position -> offset -> clang line/column
(a new function is added to SourceCode.h for the second conversion).
- getBeginningOfIdentifier skipped backwards in UTF-16 space, which is will
behave badly when it splits a surrogate pair. Skipping backwards in UTF-8
coordinates gives the lexer a fighting chance of getting this right.
While here, I clarified(?) the logic comments, fixed a bug with identifiers
containing digits, simplified the signature slightly and added a test.
This seems likely to cause problems with editors that have the same bug, and
treat the protocol as if columns are UTF-8 bytes. But we can find and fix those.
Reviewers: hokein
Subscribers: klimek, ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D46035
llvm-svn: 331029
2018-04-27 19:59:28 +08:00
|
|
|
// Like most strings in clangd, the input is UTF-8 encoded.
|
2019-01-07 23:45:19 +08:00
|
|
|
size_t lspLength(llvm::StringRef Code) {
|
[clangd] Fix unicode handling, using UTF-16 where LSP requires it.
Summary:
The Language Server Protocol unfortunately mandates that locations in files
be represented by line/column pairs, where the "column" is actually an index
into the UTF-16-encoded text of the line.
(This is because VSCode is written in JavaScript, which is UTF-16-native).
Internally clangd treats source files at UTF-8, the One True Encoding, and
generally deals with byte offsets (though there are exceptions).
Before this patch, conversions between offsets and LSP Position pretended
that Position.character was UTF-8 bytes, which is only true for ASCII lines.
Now we examine the text to convert correctly (but don't actually need to
transcode it, due to some nice details of the encodings).
The updated functions in SourceCode are the blessed way to interact with
the Position.character field, and anything else is likely to be wrong.
So I also updated the other accesses:
- CodeComplete needs a "clang-style" line/column, with column in utf-8 bytes.
This is now converted via Position -> offset -> clang line/column
(a new function is added to SourceCode.h for the second conversion).
- getBeginningOfIdentifier skipped backwards in UTF-16 space, which is will
behave badly when it splits a surrogate pair. Skipping backwards in UTF-8
coordinates gives the lexer a fighting chance of getting this right.
While here, I clarified(?) the logic comments, fixed a bug with identifiers
containing digits, simplified the signature slightly and added a test.
This seems likely to cause problems with editors that have the same bug, and
treat the protocol as if columns are UTF-8 bytes. But we can find and fix those.
Reviewers: hokein
Subscribers: klimek, ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D46035
llvm-svn: 331029
2018-04-27 19:59:28 +08:00
|
|
|
size_t Count = 0;
|
2019-03-28 22:37:51 +08:00
|
|
|
switch (lspEncoding()) {
|
|
|
|
case OffsetEncoding::UTF8:
|
|
|
|
Count = Code.size();
|
|
|
|
break;
|
|
|
|
case OffsetEncoding::UTF16:
|
|
|
|
iterateCodepoints(Code, [&](int U8Len, int U16Len) {
|
|
|
|
Count += U16Len;
|
|
|
|
return false;
|
|
|
|
});
|
|
|
|
break;
|
|
|
|
case OffsetEncoding::UTF32:
|
|
|
|
iterateCodepoints(Code, [&](int U8Len, int U16Len) {
|
|
|
|
++Count;
|
|
|
|
return false;
|
|
|
|
});
|
|
|
|
break;
|
|
|
|
case OffsetEncoding::UnsupportedEncoding:
|
|
|
|
llvm_unreachable("unsupported encoding");
|
|
|
|
}
|
[clangd] Fix unicode handling, using UTF-16 where LSP requires it.
Summary:
The Language Server Protocol unfortunately mandates that locations in files
be represented by line/column pairs, where the "column" is actually an index
into the UTF-16-encoded text of the line.
(This is because VSCode is written in JavaScript, which is UTF-16-native).
Internally clangd treats source files at UTF-8, the One True Encoding, and
generally deals with byte offsets (though there are exceptions).
Before this patch, conversions between offsets and LSP Position pretended
that Position.character was UTF-8 bytes, which is only true for ASCII lines.
Now we examine the text to convert correctly (but don't actually need to
transcode it, due to some nice details of the encodings).
The updated functions in SourceCode are the blessed way to interact with
the Position.character field, and anything else is likely to be wrong.
So I also updated the other accesses:
- CodeComplete needs a "clang-style" line/column, with column in utf-8 bytes.
This is now converted via Position -> offset -> clang line/column
(a new function is added to SourceCode.h for the second conversion).
- getBeginningOfIdentifier skipped backwards in UTF-16 space, which is will
behave badly when it splits a surrogate pair. Skipping backwards in UTF-8
coordinates gives the lexer a fighting chance of getting this right.
While here, I clarified(?) the logic comments, fixed a bug with identifiers
containing digits, simplified the signature slightly and added a test.
This seems likely to cause problems with editors that have the same bug, and
treat the protocol as if columns are UTF-8 bytes. But we can find and fix those.
Reviewers: hokein
Subscribers: klimek, ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D46035
llvm-svn: 331029
2018-04-27 19:59:28 +08:00
|
|
|
return Count;
|
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::Expected<size_t> positionToOffset(llvm::StringRef Code, Position P,
|
|
|
|
bool AllowColumnsBeyondLineLength) {
|
2017-12-19 20:23:48 +08:00
|
|
|
if (P.line < 0)
|
2020-09-14 17:33:12 +08:00
|
|
|
return error(llvm::errc::invalid_argument,
|
|
|
|
"Line value can't be negative ({0})", P.line);
|
Make positionToOffset return llvm::Expected<size_t>
Summary:
To implement incremental document syncing, we want to verify that the
ranges provided by the front-end are valid. Currently, positionToOffset
deals with invalid Positions by returning 0 or Code.size(), which are
two valid offsets. Instead, return an llvm:Expected<size_t> with an
error if the position is invalid.
According to the LSP, if the character value exceeds the number of
characters of the given line, it should default back to the end of the
line. It makes sense in some contexts to have this behavior, and does
not in other contexts. The AllowColumnsBeyondLineLength parameter
allows to decide what to do in that case, default back to the end of the
line, or return an error.
Reviewers: ilya-biryukov
Subscribers: klimek, ilya-biryukov, jkorous-apple, ioeric, cfe-commits
Differential Revision: https://reviews.llvm.org/D44673
llvm-svn: 328100
2018-03-21 22:36:46 +08:00
|
|
|
if (P.character < 0)
|
2020-09-14 17:33:12 +08:00
|
|
|
return error(llvm::errc::invalid_argument,
|
|
|
|
"Character value can't be negative ({0})", P.character);
|
2017-12-19 20:23:48 +08:00
|
|
|
size_t StartOfLine = 0;
|
|
|
|
for (int I = 0; I != P.line; ++I) {
|
|
|
|
size_t NextNL = Code.find('\n', StartOfLine);
|
2019-01-07 23:45:19 +08:00
|
|
|
if (NextNL == llvm::StringRef::npos)
|
2020-09-14 17:33:12 +08:00
|
|
|
return error(llvm::errc::invalid_argument,
|
|
|
|
"Line value is out of range ({0})", P.line);
|
2017-12-19 20:23:48 +08:00
|
|
|
StartOfLine = NextNL + 1;
|
|
|
|
}
|
2019-03-28 01:47:49 +08:00
|
|
|
StringRef Line =
|
|
|
|
Code.substr(StartOfLine).take_until([](char C) { return C == '\n'; });
|
Make positionToOffset return llvm::Expected<size_t>
Summary:
To implement incremental document syncing, we want to verify that the
ranges provided by the front-end are valid. Currently, positionToOffset
deals with invalid Positions by returning 0 or Code.size(), which are
two valid offsets. Instead, return an llvm:Expected<size_t> with an
error if the position is invalid.
According to the LSP, if the character value exceeds the number of
characters of the given line, it should default back to the end of the
line. It makes sense in some contexts to have this behavior, and does
not in other contexts. The AllowColumnsBeyondLineLength parameter
allows to decide what to do in that case, default back to the end of the
line, or return an error.
Reviewers: ilya-biryukov
Subscribers: klimek, ilya-biryukov, jkorous-apple, ioeric, cfe-commits
Differential Revision: https://reviews.llvm.org/D44673
llvm-svn: 328100
2018-03-21 22:36:46 +08:00
|
|
|
|
2019-03-28 22:37:51 +08:00
|
|
|
// P.character may be in UTF-16, transcode if necessary.
|
[clangd] Fix unicode handling, using UTF-16 where LSP requires it.
Summary:
The Language Server Protocol unfortunately mandates that locations in files
be represented by line/column pairs, where the "column" is actually an index
into the UTF-16-encoded text of the line.
(This is because VSCode is written in JavaScript, which is UTF-16-native).
Internally clangd treats source files at UTF-8, the One True Encoding, and
generally deals with byte offsets (though there are exceptions).
Before this patch, conversions between offsets and LSP Position pretended
that Position.character was UTF-8 bytes, which is only true for ASCII lines.
Now we examine the text to convert correctly (but don't actually need to
transcode it, due to some nice details of the encodings).
The updated functions in SourceCode are the blessed way to interact with
the Position.character field, and anything else is likely to be wrong.
So I also updated the other accesses:
- CodeComplete needs a "clang-style" line/column, with column in utf-8 bytes.
This is now converted via Position -> offset -> clang line/column
(a new function is added to SourceCode.h for the second conversion).
- getBeginningOfIdentifier skipped backwards in UTF-16 space, which is will
behave badly when it splits a surrogate pair. Skipping backwards in UTF-8
coordinates gives the lexer a fighting chance of getting this right.
While here, I clarified(?) the logic comments, fixed a bug with identifiers
containing digits, simplified the signature slightly and added a test.
This seems likely to cause problems with editors that have the same bug, and
treat the protocol as if columns are UTF-8 bytes. But we can find and fix those.
Reviewers: hokein
Subscribers: klimek, ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D46035
llvm-svn: 331029
2018-04-27 19:59:28 +08:00
|
|
|
bool Valid;
|
2019-03-28 22:37:51 +08:00
|
|
|
size_t ByteInLine = measureUnits(Line, P.character, lspEncoding(), Valid);
|
[clangd] Fix unicode handling, using UTF-16 where LSP requires it.
Summary:
The Language Server Protocol unfortunately mandates that locations in files
be represented by line/column pairs, where the "column" is actually an index
into the UTF-16-encoded text of the line.
(This is because VSCode is written in JavaScript, which is UTF-16-native).
Internally clangd treats source files at UTF-8, the One True Encoding, and
generally deals with byte offsets (though there are exceptions).
Before this patch, conversions between offsets and LSP Position pretended
that Position.character was UTF-8 bytes, which is only true for ASCII lines.
Now we examine the text to convert correctly (but don't actually need to
transcode it, due to some nice details of the encodings).
The updated functions in SourceCode are the blessed way to interact with
the Position.character field, and anything else is likely to be wrong.
So I also updated the other accesses:
- CodeComplete needs a "clang-style" line/column, with column in utf-8 bytes.
This is now converted via Position -> offset -> clang line/column
(a new function is added to SourceCode.h for the second conversion).
- getBeginningOfIdentifier skipped backwards in UTF-16 space, which is will
behave badly when it splits a surrogate pair. Skipping backwards in UTF-8
coordinates gives the lexer a fighting chance of getting this right.
While here, I clarified(?) the logic comments, fixed a bug with identifiers
containing digits, simplified the signature slightly and added a test.
This seems likely to cause problems with editors that have the same bug, and
treat the protocol as if columns are UTF-8 bytes. But we can find and fix those.
Reviewers: hokein
Subscribers: klimek, ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D46035
llvm-svn: 331029
2018-04-27 19:59:28 +08:00
|
|
|
if (!Valid && !AllowColumnsBeyondLineLength)
|
2020-09-14 17:33:12 +08:00
|
|
|
return error(llvm::errc::invalid_argument,
|
|
|
|
"{0} offset {1} is invalid for line {2}", lspEncoding(),
|
|
|
|
P.character, P.line);
|
2019-03-28 22:37:51 +08:00
|
|
|
return StartOfLine + ByteInLine;
|
2017-12-19 20:23:48 +08:00
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
Position offsetToPosition(llvm::StringRef Code, size_t Offset) {
|
2017-12-19 20:23:48 +08:00
|
|
|
Offset = std::min(Code.size(), Offset);
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::StringRef Before = Code.substr(0, Offset);
|
2017-12-19 20:23:48 +08:00
|
|
|
int Lines = Before.count('\n');
|
|
|
|
size_t PrevNL = Before.rfind('\n');
|
2019-01-07 23:45:19 +08:00
|
|
|
size_t StartOfLine = (PrevNL == llvm::StringRef::npos) ? 0 : (PrevNL + 1);
|
2018-02-14 18:52:04 +08:00
|
|
|
Position Pos;
|
|
|
|
Pos.line = Lines;
|
2018-10-23 19:51:53 +08:00
|
|
|
Pos.character = lspLength(Before.substr(StartOfLine));
|
2018-02-14 18:52:04 +08:00
|
|
|
return Pos;
|
2017-12-19 20:23:48 +08:00
|
|
|
}
|
|
|
|
|
2018-02-21 10:39:08 +08:00
|
|
|
Position sourceLocToPosition(const SourceManager &SM, SourceLocation Loc) {
|
[clangd] Fix unicode handling, using UTF-16 where LSP requires it.
Summary:
The Language Server Protocol unfortunately mandates that locations in files
be represented by line/column pairs, where the "column" is actually an index
into the UTF-16-encoded text of the line.
(This is because VSCode is written in JavaScript, which is UTF-16-native).
Internally clangd treats source files at UTF-8, the One True Encoding, and
generally deals with byte offsets (though there are exceptions).
Before this patch, conversions between offsets and LSP Position pretended
that Position.character was UTF-8 bytes, which is only true for ASCII lines.
Now we examine the text to convert correctly (but don't actually need to
transcode it, due to some nice details of the encodings).
The updated functions in SourceCode are the blessed way to interact with
the Position.character field, and anything else is likely to be wrong.
So I also updated the other accesses:
- CodeComplete needs a "clang-style" line/column, with column in utf-8 bytes.
This is now converted via Position -> offset -> clang line/column
(a new function is added to SourceCode.h for the second conversion).
- getBeginningOfIdentifier skipped backwards in UTF-16 space, which is will
behave badly when it splits a surrogate pair. Skipping backwards in UTF-8
coordinates gives the lexer a fighting chance of getting this right.
While here, I clarified(?) the logic comments, fixed a bug with identifiers
containing digits, simplified the signature slightly and added a test.
This seems likely to cause problems with editors that have the same bug, and
treat the protocol as if columns are UTF-8 bytes. But we can find and fix those.
Reviewers: hokein
Subscribers: klimek, ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D46035
llvm-svn: 331029
2018-04-27 19:59:28 +08:00
|
|
|
// We use the SourceManager's line tables, but its column number is in bytes.
|
|
|
|
FileID FID;
|
|
|
|
unsigned Offset;
|
|
|
|
std::tie(FID, Offset) = SM.getDecomposedSpellingLoc(Loc);
|
2018-02-21 10:39:08 +08:00
|
|
|
Position P;
|
[clangd] Fix unicode handling, using UTF-16 where LSP requires it.
Summary:
The Language Server Protocol unfortunately mandates that locations in files
be represented by line/column pairs, where the "column" is actually an index
into the UTF-16-encoded text of the line.
(This is because VSCode is written in JavaScript, which is UTF-16-native).
Internally clangd treats source files at UTF-8, the One True Encoding, and
generally deals with byte offsets (though there are exceptions).
Before this patch, conversions between offsets and LSP Position pretended
that Position.character was UTF-8 bytes, which is only true for ASCII lines.
Now we examine the text to convert correctly (but don't actually need to
transcode it, due to some nice details of the encodings).
The updated functions in SourceCode are the blessed way to interact with
the Position.character field, and anything else is likely to be wrong.
So I also updated the other accesses:
- CodeComplete needs a "clang-style" line/column, with column in utf-8 bytes.
This is now converted via Position -> offset -> clang line/column
(a new function is added to SourceCode.h for the second conversion).
- getBeginningOfIdentifier skipped backwards in UTF-16 space, which is will
behave badly when it splits a surrogate pair. Skipping backwards in UTF-8
coordinates gives the lexer a fighting chance of getting this right.
While here, I clarified(?) the logic comments, fixed a bug with identifiers
containing digits, simplified the signature slightly and added a test.
This seems likely to cause problems with editors that have the same bug, and
treat the protocol as if columns are UTF-8 bytes. But we can find and fix those.
Reviewers: hokein
Subscribers: klimek, ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D46035
llvm-svn: 331029
2018-04-27 19:59:28 +08:00
|
|
|
P.line = static_cast<int>(SM.getLineNumber(FID, Offset)) - 1;
|
|
|
|
bool Invalid = false;
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::StringRef Code = SM.getBufferData(FID, &Invalid);
|
[clangd] Fix unicode handling, using UTF-16 where LSP requires it.
Summary:
The Language Server Protocol unfortunately mandates that locations in files
be represented by line/column pairs, where the "column" is actually an index
into the UTF-16-encoded text of the line.
(This is because VSCode is written in JavaScript, which is UTF-16-native).
Internally clangd treats source files at UTF-8, the One True Encoding, and
generally deals with byte offsets (though there are exceptions).
Before this patch, conversions between offsets and LSP Position pretended
that Position.character was UTF-8 bytes, which is only true for ASCII lines.
Now we examine the text to convert correctly (but don't actually need to
transcode it, due to some nice details of the encodings).
The updated functions in SourceCode are the blessed way to interact with
the Position.character field, and anything else is likely to be wrong.
So I also updated the other accesses:
- CodeComplete needs a "clang-style" line/column, with column in utf-8 bytes.
This is now converted via Position -> offset -> clang line/column
(a new function is added to SourceCode.h for the second conversion).
- getBeginningOfIdentifier skipped backwards in UTF-16 space, which is will
behave badly when it splits a surrogate pair. Skipping backwards in UTF-8
coordinates gives the lexer a fighting chance of getting this right.
While here, I clarified(?) the logic comments, fixed a bug with identifiers
containing digits, simplified the signature slightly and added a test.
This seems likely to cause problems with editors that have the same bug, and
treat the protocol as if columns are UTF-8 bytes. But we can find and fix those.
Reviewers: hokein
Subscribers: klimek, ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D46035
llvm-svn: 331029
2018-04-27 19:59:28 +08:00
|
|
|
if (!Invalid) {
|
|
|
|
auto ColumnInBytes = SM.getColumnNumber(FID, Offset) - 1;
|
|
|
|
auto LineSoFar = Code.substr(Offset - ColumnInBytes, ColumnInBytes);
|
2018-10-23 19:51:53 +08:00
|
|
|
P.character = lspLength(LineSoFar);
|
[clangd] Fix unicode handling, using UTF-16 where LSP requires it.
Summary:
The Language Server Protocol unfortunately mandates that locations in files
be represented by line/column pairs, where the "column" is actually an index
into the UTF-16-encoded text of the line.
(This is because VSCode is written in JavaScript, which is UTF-16-native).
Internally clangd treats source files at UTF-8, the One True Encoding, and
generally deals with byte offsets (though there are exceptions).
Before this patch, conversions between offsets and LSP Position pretended
that Position.character was UTF-8 bytes, which is only true for ASCII lines.
Now we examine the text to convert correctly (but don't actually need to
transcode it, due to some nice details of the encodings).
The updated functions in SourceCode are the blessed way to interact with
the Position.character field, and anything else is likely to be wrong.
So I also updated the other accesses:
- CodeComplete needs a "clang-style" line/column, with column in utf-8 bytes.
This is now converted via Position -> offset -> clang line/column
(a new function is added to SourceCode.h for the second conversion).
- getBeginningOfIdentifier skipped backwards in UTF-16 space, which is will
behave badly when it splits a surrogate pair. Skipping backwards in UTF-8
coordinates gives the lexer a fighting chance of getting this right.
While here, I clarified(?) the logic comments, fixed a bug with identifiers
containing digits, simplified the signature slightly and added a test.
This seems likely to cause problems with editors that have the same bug, and
treat the protocol as if columns are UTF-8 bytes. But we can find and fix those.
Reviewers: hokein
Subscribers: klimek, ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D46035
llvm-svn: 331029
2018-04-27 19:59:28 +08:00
|
|
|
}
|
2018-02-21 10:39:08 +08:00
|
|
|
return P;
|
|
|
|
}
|
|
|
|
|
2019-08-07 04:25:59 +08:00
|
|
|
bool isSpelledInSource(SourceLocation Loc, const SourceManager &SM) {
|
|
|
|
if (Loc.isMacroID()) {
|
|
|
|
std::string PrintLoc = SM.getSpellingLoc(Loc).printToString(SM);
|
|
|
|
if (llvm::StringRef(PrintLoc).startswith("<scratch") ||
|
|
|
|
llvm::StringRef(PrintLoc).startswith("<command line>"))
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2019-02-01 05:30:05 +08:00
|
|
|
bool isValidFileRange(const SourceManager &Mgr, SourceRange R) {
|
|
|
|
if (!R.getBegin().isValid() || !R.getEnd().isValid())
|
|
|
|
return false;
|
|
|
|
|
|
|
|
FileID BeginFID;
|
|
|
|
size_t BeginOffset = 0;
|
|
|
|
std::tie(BeginFID, BeginOffset) = Mgr.getDecomposedLoc(R.getBegin());
|
|
|
|
|
|
|
|
FileID EndFID;
|
|
|
|
size_t EndOffset = 0;
|
|
|
|
std::tie(EndFID, EndOffset) = Mgr.getDecomposedLoc(R.getEnd());
|
|
|
|
|
|
|
|
return BeginFID.isValid() && BeginFID == EndFID && BeginOffset <= EndOffset;
|
|
|
|
}
|
|
|
|
|
2019-08-27 16:44:06 +08:00
|
|
|
SourceLocation includeHashLoc(FileID IncludedFile, const SourceManager &SM) {
|
|
|
|
assert(SM.getLocForEndOfFile(IncludedFile).isFileID());
|
|
|
|
FileID IncludingFile;
|
|
|
|
unsigned Offset;
|
|
|
|
std::tie(IncludingFile, Offset) =
|
|
|
|
SM.getDecomposedExpansionLoc(SM.getIncludeLoc(IncludedFile));
|
|
|
|
bool Invalid = false;
|
|
|
|
llvm::StringRef Buf = SM.getBufferData(IncludingFile, &Invalid);
|
|
|
|
if (Invalid)
|
|
|
|
return SourceLocation();
|
|
|
|
// Now buf is "...\n#include <foo>\n..."
|
|
|
|
// and Offset points here: ^
|
|
|
|
// Rewind to the preceding # on the line.
|
|
|
|
assert(Offset < Buf.size());
|
|
|
|
for (;; --Offset) {
|
|
|
|
if (Buf[Offset] == '#')
|
|
|
|
return SM.getComposedLoc(IncludingFile, Offset);
|
|
|
|
if (Buf[Offset] == '\n' || Offset == 0) // no hash, what's going on?
|
|
|
|
return SourceLocation();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-07-12 19:42:31 +08:00
|
|
|
static unsigned getTokenLengthAtLoc(SourceLocation Loc, const SourceManager &SM,
|
|
|
|
const LangOptions &LangOpts) {
|
|
|
|
Token TheTok;
|
|
|
|
if (Lexer::getRawToken(Loc, TheTok, SM, LangOpts))
|
|
|
|
return 0;
|
|
|
|
// FIXME: Here we check whether the token at the location is a greatergreater
|
|
|
|
// (>>) token and consider it as a single greater (>). This is to get it
|
|
|
|
// working for templates but it isn't correct for the right shift operator. We
|
|
|
|
// can avoid this by using half open char ranges in getFileRange() but getting
|
|
|
|
// token ending is not well supported in macroIDs.
|
|
|
|
if (TheTok.is(tok::greatergreater))
|
|
|
|
return 1;
|
|
|
|
return TheTok.getLength();
|
|
|
|
}
|
|
|
|
|
|
|
|
// Returns location of the last character of the token at a given loc
|
|
|
|
static SourceLocation getLocForTokenEnd(SourceLocation BeginLoc,
|
|
|
|
const SourceManager &SM,
|
|
|
|
const LangOptions &LangOpts) {
|
|
|
|
unsigned Len = getTokenLengthAtLoc(BeginLoc, SM, LangOpts);
|
|
|
|
return BeginLoc.getLocWithOffset(Len ? Len - 1 : 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Returns location of the starting of the token at a given EndLoc
|
|
|
|
static SourceLocation getLocForTokenBegin(SourceLocation EndLoc,
|
|
|
|
const SourceManager &SM,
|
|
|
|
const LangOptions &LangOpts) {
|
|
|
|
return EndLoc.getLocWithOffset(
|
|
|
|
-(signed)getTokenLengthAtLoc(EndLoc, SM, LangOpts));
|
|
|
|
}
|
|
|
|
|
|
|
|
// Converts a char source range to a token range.
|
|
|
|
static SourceRange toTokenRange(CharSourceRange Range, const SourceManager &SM,
|
|
|
|
const LangOptions &LangOpts) {
|
|
|
|
if (!Range.isTokenRange())
|
|
|
|
Range.setEnd(getLocForTokenBegin(Range.getEnd(), SM, LangOpts));
|
|
|
|
return Range.getAsRange();
|
|
|
|
}
|
|
|
|
// Returns the union of two token ranges.
|
|
|
|
// To find the maximum of the Ends of the ranges, we compare the location of the
|
|
|
|
// last character of the token.
|
|
|
|
static SourceRange unionTokenRange(SourceRange R1, SourceRange R2,
|
|
|
|
const SourceManager &SM,
|
|
|
|
const LangOptions &LangOpts) {
|
2019-08-27 16:44:06 +08:00
|
|
|
SourceLocation Begin =
|
|
|
|
SM.isBeforeInTranslationUnit(R1.getBegin(), R2.getBegin())
|
|
|
|
? R1.getBegin()
|
|
|
|
: R2.getBegin();
|
|
|
|
SourceLocation End =
|
|
|
|
SM.isBeforeInTranslationUnit(getLocForTokenEnd(R1.getEnd(), SM, LangOpts),
|
|
|
|
getLocForTokenEnd(R2.getEnd(), SM, LangOpts))
|
|
|
|
? R2.getEnd()
|
|
|
|
: R1.getEnd();
|
|
|
|
return SourceRange(Begin, End);
|
2019-07-12 19:42:31 +08:00
|
|
|
}
|
|
|
|
|
2019-08-27 16:44:06 +08:00
|
|
|
// Given a range whose endpoints may be in different expansions or files,
|
|
|
|
// tries to find a range within a common file by following up the expansion and
|
|
|
|
// include location in each.
|
|
|
|
static SourceRange rangeInCommonFile(SourceRange R, const SourceManager &SM,
|
|
|
|
const LangOptions &LangOpts) {
|
2019-08-07 01:01:12 +08:00
|
|
|
// Fast path for most common cases.
|
2019-08-27 16:44:06 +08:00
|
|
|
if (SM.isWrittenInSameFile(R.getBegin(), R.getEnd()))
|
|
|
|
return R;
|
2019-08-07 01:01:12 +08:00
|
|
|
// Record the stack of expansion locations for the beginning, keyed by FileID.
|
|
|
|
llvm::DenseMap<FileID, SourceLocation> BeginExpansions;
|
2019-08-27 16:44:06 +08:00
|
|
|
for (SourceLocation Begin = R.getBegin(); Begin.isValid();
|
2019-08-07 01:01:12 +08:00
|
|
|
Begin = Begin.isFileID()
|
2019-08-27 16:44:06 +08:00
|
|
|
? includeHashLoc(SM.getFileID(Begin), SM)
|
2019-08-07 01:01:12 +08:00
|
|
|
: SM.getImmediateExpansionRange(Begin).getBegin()) {
|
|
|
|
BeginExpansions[SM.getFileID(Begin)] = Begin;
|
|
|
|
}
|
|
|
|
// Move up the stack of expansion locations for the end until we find the
|
|
|
|
// location in BeginExpansions with that has the same file id.
|
2019-08-27 16:44:06 +08:00
|
|
|
for (SourceLocation End = R.getEnd(); End.isValid();
|
|
|
|
End = End.isFileID() ? includeHashLoc(SM.getFileID(End), SM)
|
2019-08-07 01:01:12 +08:00
|
|
|
: toTokenRange(SM.getImmediateExpansionRange(End),
|
|
|
|
SM, LangOpts)
|
|
|
|
.getEnd()) {
|
|
|
|
auto It = BeginExpansions.find(SM.getFileID(End));
|
2019-08-27 16:44:06 +08:00
|
|
|
if (It != BeginExpansions.end()) {
|
|
|
|
if (SM.getFileOffset(It->second) > SM.getFileOffset(End))
|
|
|
|
return SourceLocation();
|
2019-08-07 01:01:12 +08:00
|
|
|
return {It->second, End};
|
2019-08-27 16:44:06 +08:00
|
|
|
}
|
2019-08-07 01:01:12 +08:00
|
|
|
}
|
2019-08-27 16:44:06 +08:00
|
|
|
return SourceRange();
|
2019-08-07 01:01:12 +08:00
|
|
|
}
|
2019-08-27 16:44:06 +08:00
|
|
|
|
|
|
|
// Find an expansion range (not necessarily immediate) the ends of which are in
|
|
|
|
// the same file id.
|
|
|
|
static SourceRange
|
|
|
|
getExpansionTokenRangeInSameFile(SourceLocation Loc, const SourceManager &SM,
|
|
|
|
const LangOptions &LangOpts) {
|
|
|
|
return rangeInCommonFile(
|
|
|
|
toTokenRange(SM.getImmediateExpansionRange(Loc), SM, LangOpts), SM,
|
|
|
|
LangOpts);
|
|
|
|
}
|
|
|
|
|
2019-08-07 01:01:12 +08:00
|
|
|
// Returns the file range for a given Location as a Token Range
|
2019-07-12 19:42:31 +08:00
|
|
|
// This is quite similar to getFileLoc in SourceManager as both use
|
|
|
|
// getImmediateExpansionRange and getImmediateSpellingLoc (for macro IDs).
|
|
|
|
// However:
|
|
|
|
// - We want to maintain the full range information as we move from one file to
|
|
|
|
// the next. getFileLoc only uses the BeginLoc of getImmediateExpansionRange.
|
2019-08-07 01:01:12 +08:00
|
|
|
// - We want to split '>>' tokens as the lexer parses the '>>' in nested
|
|
|
|
// template instantiations as a '>>' instead of two '>'s.
|
2019-07-12 19:42:31 +08:00
|
|
|
// There is also getExpansionRange but it simply calls
|
|
|
|
// getImmediateExpansionRange on the begin and ends separately which is wrong.
|
|
|
|
static SourceRange getTokenFileRange(SourceLocation Loc,
|
|
|
|
const SourceManager &SM,
|
|
|
|
const LangOptions &LangOpts) {
|
|
|
|
SourceRange FileRange = Loc;
|
|
|
|
while (!FileRange.getBegin().isFileID()) {
|
|
|
|
if (SM.isMacroArgExpansion(FileRange.getBegin())) {
|
2019-08-07 01:01:12 +08:00
|
|
|
FileRange = unionTokenRange(
|
|
|
|
SM.getImmediateSpellingLoc(FileRange.getBegin()),
|
|
|
|
SM.getImmediateSpellingLoc(FileRange.getEnd()), SM, LangOpts);
|
2019-08-27 16:44:06 +08:00
|
|
|
assert(SM.isWrittenInSameFile(FileRange.getBegin(), FileRange.getEnd()));
|
2019-07-12 19:42:31 +08:00
|
|
|
} else {
|
2019-08-07 01:01:12 +08:00
|
|
|
SourceRange ExpansionRangeForBegin =
|
|
|
|
getExpansionTokenRangeInSameFile(FileRange.getBegin(), SM, LangOpts);
|
|
|
|
SourceRange ExpansionRangeForEnd =
|
|
|
|
getExpansionTokenRangeInSameFile(FileRange.getEnd(), SM, LangOpts);
|
2019-08-27 16:44:06 +08:00
|
|
|
if (ExpansionRangeForBegin.isInvalid() ||
|
|
|
|
ExpansionRangeForEnd.isInvalid())
|
|
|
|
return SourceRange();
|
|
|
|
assert(SM.isWrittenInSameFile(ExpansionRangeForBegin.getBegin(),
|
|
|
|
ExpansionRangeForEnd.getBegin()) &&
|
2019-08-07 01:01:12 +08:00
|
|
|
"Both Expansion ranges should be in same file.");
|
2019-07-12 19:42:31 +08:00
|
|
|
FileRange = unionTokenRange(ExpansionRangeForBegin, ExpansionRangeForEnd,
|
|
|
|
SM, LangOpts);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return FileRange;
|
|
|
|
}
|
|
|
|
|
2019-07-19 16:33:39 +08:00
|
|
|
bool isInsideMainFile(SourceLocation Loc, const SourceManager &SM) {
|
2020-03-02 23:54:56 +08:00
|
|
|
if (!Loc.isValid())
|
|
|
|
return false;
|
|
|
|
FileID FID = SM.getFileID(SM.getExpansionLoc(Loc));
|
|
|
|
return FID == SM.getMainFileID() || FID == SM.getPreambleFileID();
|
2019-07-19 16:33:39 +08:00
|
|
|
}
|
|
|
|
|
2019-07-12 19:42:31 +08:00
|
|
|
llvm::Optional<SourceRange> toHalfOpenFileRange(const SourceManager &SM,
|
2019-02-01 05:30:05 +08:00
|
|
|
const LangOptions &LangOpts,
|
|
|
|
SourceRange R) {
|
2019-07-12 19:42:31 +08:00
|
|
|
SourceRange R1 = getTokenFileRange(R.getBegin(), SM, LangOpts);
|
|
|
|
if (!isValidFileRange(SM, R1))
|
2019-02-01 05:30:05 +08:00
|
|
|
return llvm::None;
|
2019-07-12 19:42:31 +08:00
|
|
|
|
|
|
|
SourceRange R2 = getTokenFileRange(R.getEnd(), SM, LangOpts);
|
|
|
|
if (!isValidFileRange(SM, R2))
|
2019-02-01 05:30:05 +08:00
|
|
|
return llvm::None;
|
|
|
|
|
2019-08-27 16:44:06 +08:00
|
|
|
SourceRange Result =
|
|
|
|
rangeInCommonFile(unionTokenRange(R1, R2, SM, LangOpts), SM, LangOpts);
|
2019-07-12 19:42:31 +08:00
|
|
|
unsigned TokLen = getTokenLengthAtLoc(Result.getEnd(), SM, LangOpts);
|
|
|
|
// Convert from closed token range to half-open (char) range
|
|
|
|
Result.setEnd(Result.getEnd().getLocWithOffset(TokLen));
|
|
|
|
if (!isValidFileRange(SM, Result))
|
2019-02-01 05:30:05 +08:00
|
|
|
return llvm::None;
|
2019-07-12 19:42:31 +08:00
|
|
|
|
2019-02-01 05:30:05 +08:00
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::StringRef toSourceCode(const SourceManager &SM, SourceRange R) {
|
|
|
|
assert(isValidFileRange(SM, R));
|
2020-10-15 02:36:00 +08:00
|
|
|
auto Buf = SM.getBufferOrNone(SM.getFileID(R.getBegin()));
|
|
|
|
assert(Buf);
|
2019-02-01 05:30:05 +08:00
|
|
|
|
|
|
|
size_t BeginOffset = SM.getFileOffset(R.getBegin());
|
|
|
|
size_t EndOffset = SM.getFileOffset(R.getEnd());
|
|
|
|
return Buf->getBuffer().substr(BeginOffset, EndOffset - BeginOffset);
|
|
|
|
}
|
|
|
|
|
[clangd] Interfaces for writing code tweaks
Summary:
The code tweaks are an implementation of mini-refactorings exposed
via the LSP code actions. They run in two stages:
- Stage 1. Decides whether the action is available to the user and
collects all the information required to finish the action.
Should be cheap, since this will run over all the actions known to
clangd on each textDocument/codeAction request from the client.
- Stage 2. Uses information from stage 1 to produce the actual edits
that the code action should perform. This stage can be expensive and
will only run if the user chooses to perform the specified action in
the UI.
One unfortunate consequence of this change is increased latency of
processing the textDocument/codeAction requests, which now wait for an
AST. However, we cannot avoid this with what we have available in the LSP
today.
Reviewers: kadircet, ioeric, hokein, sammccall
Reviewed By: sammccall
Subscribers: mgrang, mgorny, MaskRay, jkorous, arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D56267
llvm-svn: 352494
2019-01-29 22:17:36 +08:00
|
|
|
llvm::Expected<SourceLocation> sourceLocationInMainFile(const SourceManager &SM,
|
|
|
|
Position P) {
|
2020-10-15 02:36:00 +08:00
|
|
|
llvm::StringRef Code = SM.getBufferOrFake(SM.getMainFileID()).getBuffer();
|
[clangd] Interfaces for writing code tweaks
Summary:
The code tweaks are an implementation of mini-refactorings exposed
via the LSP code actions. They run in two stages:
- Stage 1. Decides whether the action is available to the user and
collects all the information required to finish the action.
Should be cheap, since this will run over all the actions known to
clangd on each textDocument/codeAction request from the client.
- Stage 2. Uses information from stage 1 to produce the actual edits
that the code action should perform. This stage can be expensive and
will only run if the user chooses to perform the specified action in
the UI.
One unfortunate consequence of this change is increased latency of
processing the textDocument/codeAction requests, which now wait for an
AST. However, we cannot avoid this with what we have available in the LSP
today.
Reviewers: kadircet, ioeric, hokein, sammccall
Reviewed By: sammccall
Subscribers: mgrang, mgorny, MaskRay, jkorous, arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D56267
llvm-svn: 352494
2019-01-29 22:17:36 +08:00
|
|
|
auto Offset =
|
|
|
|
positionToOffset(Code, P, /*AllowColumnBeyondLineLength=*/false);
|
|
|
|
if (!Offset)
|
|
|
|
return Offset.takeError();
|
|
|
|
return SM.getLocForStartOfFile(SM.getMainFileID()).getLocWithOffset(*Offset);
|
|
|
|
}
|
|
|
|
|
2018-03-12 23:28:22 +08:00
|
|
|
Range halfOpenToRange(const SourceManager &SM, CharSourceRange R) {
|
|
|
|
// Clang is 1-based, LSP uses 0-based indexes.
|
|
|
|
Position Begin = sourceLocToPosition(SM, R.getBegin());
|
|
|
|
Position End = sourceLocToPosition(SM, R.getEnd());
|
|
|
|
|
|
|
|
return {Begin, End};
|
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
std::pair<size_t, size_t> offsetToClangLineColumn(llvm::StringRef Code,
|
[clangd] Fix unicode handling, using UTF-16 where LSP requires it.
Summary:
The Language Server Protocol unfortunately mandates that locations in files
be represented by line/column pairs, where the "column" is actually an index
into the UTF-16-encoded text of the line.
(This is because VSCode is written in JavaScript, which is UTF-16-native).
Internally clangd treats source files at UTF-8, the One True Encoding, and
generally deals with byte offsets (though there are exceptions).
Before this patch, conversions between offsets and LSP Position pretended
that Position.character was UTF-8 bytes, which is only true for ASCII lines.
Now we examine the text to convert correctly (but don't actually need to
transcode it, due to some nice details of the encodings).
The updated functions in SourceCode are the blessed way to interact with
the Position.character field, and anything else is likely to be wrong.
So I also updated the other accesses:
- CodeComplete needs a "clang-style" line/column, with column in utf-8 bytes.
This is now converted via Position -> offset -> clang line/column
(a new function is added to SourceCode.h for the second conversion).
- getBeginningOfIdentifier skipped backwards in UTF-16 space, which is will
behave badly when it splits a surrogate pair. Skipping backwards in UTF-8
coordinates gives the lexer a fighting chance of getting this right.
While here, I clarified(?) the logic comments, fixed a bug with identifiers
containing digits, simplified the signature slightly and added a test.
This seems likely to cause problems with editors that have the same bug, and
treat the protocol as if columns are UTF-8 bytes. But we can find and fix those.
Reviewers: hokein
Subscribers: klimek, ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D46035
llvm-svn: 331029
2018-04-27 19:59:28 +08:00
|
|
|
size_t Offset) {
|
|
|
|
Offset = std::min(Code.size(), Offset);
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::StringRef Before = Code.substr(0, Offset);
|
[clangd] Fix unicode handling, using UTF-16 where LSP requires it.
Summary:
The Language Server Protocol unfortunately mandates that locations in files
be represented by line/column pairs, where the "column" is actually an index
into the UTF-16-encoded text of the line.
(This is because VSCode is written in JavaScript, which is UTF-16-native).
Internally clangd treats source files at UTF-8, the One True Encoding, and
generally deals with byte offsets (though there are exceptions).
Before this patch, conversions between offsets and LSP Position pretended
that Position.character was UTF-8 bytes, which is only true for ASCII lines.
Now we examine the text to convert correctly (but don't actually need to
transcode it, due to some nice details of the encodings).
The updated functions in SourceCode are the blessed way to interact with
the Position.character field, and anything else is likely to be wrong.
So I also updated the other accesses:
- CodeComplete needs a "clang-style" line/column, with column in utf-8 bytes.
This is now converted via Position -> offset -> clang line/column
(a new function is added to SourceCode.h for the second conversion).
- getBeginningOfIdentifier skipped backwards in UTF-16 space, which is will
behave badly when it splits a surrogate pair. Skipping backwards in UTF-8
coordinates gives the lexer a fighting chance of getting this right.
While here, I clarified(?) the logic comments, fixed a bug with identifiers
containing digits, simplified the signature slightly and added a test.
This seems likely to cause problems with editors that have the same bug, and
treat the protocol as if columns are UTF-8 bytes. But we can find and fix those.
Reviewers: hokein
Subscribers: klimek, ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D46035
llvm-svn: 331029
2018-04-27 19:59:28 +08:00
|
|
|
int Lines = Before.count('\n');
|
|
|
|
size_t PrevNL = Before.rfind('\n');
|
2019-01-07 23:45:19 +08:00
|
|
|
size_t StartOfLine = (PrevNL == llvm::StringRef::npos) ? 0 : (PrevNL + 1);
|
[clangd] Fix unicode handling, using UTF-16 where LSP requires it.
Summary:
The Language Server Protocol unfortunately mandates that locations in files
be represented by line/column pairs, where the "column" is actually an index
into the UTF-16-encoded text of the line.
(This is because VSCode is written in JavaScript, which is UTF-16-native).
Internally clangd treats source files at UTF-8, the One True Encoding, and
generally deals with byte offsets (though there are exceptions).
Before this patch, conversions between offsets and LSP Position pretended
that Position.character was UTF-8 bytes, which is only true for ASCII lines.
Now we examine the text to convert correctly (but don't actually need to
transcode it, due to some nice details of the encodings).
The updated functions in SourceCode are the blessed way to interact with
the Position.character field, and anything else is likely to be wrong.
So I also updated the other accesses:
- CodeComplete needs a "clang-style" line/column, with column in utf-8 bytes.
This is now converted via Position -> offset -> clang line/column
(a new function is added to SourceCode.h for the second conversion).
- getBeginningOfIdentifier skipped backwards in UTF-16 space, which is will
behave badly when it splits a surrogate pair. Skipping backwards in UTF-8
coordinates gives the lexer a fighting chance of getting this right.
While here, I clarified(?) the logic comments, fixed a bug with identifiers
containing digits, simplified the signature slightly and added a test.
This seems likely to cause problems with editors that have the same bug, and
treat the protocol as if columns are UTF-8 bytes. But we can find and fix those.
Reviewers: hokein
Subscribers: klimek, ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D46035
llvm-svn: 331029
2018-04-27 19:59:28 +08:00
|
|
|
return {Lines + 1, Offset - StartOfLine + 1};
|
|
|
|
}
|
|
|
|
|
2019-02-01 05:30:05 +08:00
|
|
|
std::pair<StringRef, StringRef> splitQualifiedName(StringRef QName) {
|
[clangd] Implementation of workspace/symbol request
Summary:
This is a basic implementation of the "workspace/symbol" request which is
used to find symbols by a string query. Since this is similar to code completion
in terms of result, this implementation reuses the "fuzzyFind" in order to get
matches. For now, the scoring algorithm is the same as code completion and
improvements could be done in the future.
The index model doesn't contain quite enough symbols for this to cover
common symbols like methods, enum class enumerators, functions in unamed
namespaces, etc. The index model will be augmented separately to achieve this.
Reviewers: sammccall, ilya-biryukov
Reviewed By: sammccall
Subscribers: jkorous, hokein, simark, sammccall, klimek, mgorny, ilya-biryukov, mgrang, jkorous-apple, ioeric, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D44882
llvm-svn: 330637
2018-04-24 04:00:52 +08:00
|
|
|
size_t Pos = QName.rfind("::");
|
2019-01-07 23:45:19 +08:00
|
|
|
if (Pos == llvm::StringRef::npos)
|
|
|
|
return {llvm::StringRef(), QName};
|
[clangd] Implementation of workspace/symbol request
Summary:
This is a basic implementation of the "workspace/symbol" request which is
used to find symbols by a string query. Since this is similar to code completion
in terms of result, this implementation reuses the "fuzzyFind" in order to get
matches. For now, the scoring algorithm is the same as code completion and
improvements could be done in the future.
The index model doesn't contain quite enough symbols for this to cover
common symbols like methods, enum class enumerators, functions in unamed
namespaces, etc. The index model will be augmented separately to achieve this.
Reviewers: sammccall, ilya-biryukov
Reviewed By: sammccall
Subscribers: jkorous, hokein, simark, sammccall, klimek, mgorny, ilya-biryukov, mgrang, jkorous-apple, ioeric, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D44882
llvm-svn: 330637
2018-04-24 04:00:52 +08:00
|
|
|
return {QName.substr(0, Pos + 2), QName.substr(Pos + 2)};
|
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
TextEdit replacementToEdit(llvm::StringRef Code,
|
|
|
|
const tooling::Replacement &R) {
|
2018-05-11 20:12:08 +08:00
|
|
|
Range ReplacementRange = {
|
|
|
|
offsetToPosition(Code, R.getOffset()),
|
|
|
|
offsetToPosition(Code, R.getOffset() + R.getLength())};
|
2020-01-29 03:23:46 +08:00
|
|
|
return {ReplacementRange, std::string(R.getReplacementText())};
|
2018-05-11 20:12:08 +08:00
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
std::vector<TextEdit> replacementsToEdits(llvm::StringRef Code,
|
2018-05-11 20:12:08 +08:00
|
|
|
const tooling::Replacements &Repls) {
|
|
|
|
std::vector<TextEdit> Edits;
|
|
|
|
for (const auto &R : Repls)
|
|
|
|
Edits.push_back(replacementToEdit(Code, R));
|
|
|
|
return Edits;
|
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::Optional<std::string> getCanonicalPath(const FileEntry *F,
|
|
|
|
const SourceManager &SourceMgr) {
|
2018-12-19 18:46:21 +08:00
|
|
|
if (!F)
|
|
|
|
return None;
|
[clangd] Avoid duplicates in findDefinitions response
Summary:
When compile_commands.json contains some source files expressed as
relative paths, we can get duplicate responses to findDefinitions. The
responses only differ by the URI, which are different versions of the
same file:
"result": [
{
...
"uri": "file:///home/emaisin/src/ls-interact/cpp-test/build/../src/first.h"
},
{
...
"uri": "file:///home/emaisin/src/ls-interact/cpp-test/src/first.h"
}
]
In getAbsoluteFilePath, we try to obtain the realpath of the FileEntry
by calling tryGetRealPathName. However, this can fail and return an
empty string. It may be bug a bug in clang, but in any case we should
fall back to computing it ourselves if it happens.
I changed getAbsoluteFilePath so that if tryGetRealPathName succeeds, we
return right away (a real path is always absolute). Otherwise, we try
to build an absolute path, as we did before, but we also call
VFS->getRealPath to make sure to get the canonical path (e.g. without
any ".." in it).
Reviewers: malaperle
Subscribers: hokein, ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D48687
llvm-svn: 339483
2018-08-11 06:27:53 +08:00
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::SmallString<128> FilePath = F->getName();
|
|
|
|
if (!llvm::sys::path::is_absolute(FilePath)) {
|
2018-12-19 18:46:21 +08:00
|
|
|
if (auto EC =
|
2019-03-27 06:32:06 +08:00
|
|
|
SourceMgr.getFileManager().getVirtualFileSystem().makeAbsolute(
|
2018-12-19 18:46:21 +08:00
|
|
|
FilePath)) {
|
|
|
|
elog("Could not turn relative path '{0}' to absolute: {1}", FilePath,
|
|
|
|
EC.message());
|
2018-10-20 23:30:37 +08:00
|
|
|
return None;
|
2018-07-06 03:35:01 +08:00
|
|
|
}
|
|
|
|
}
|
[clangd] Avoid duplicates in findDefinitions response
Summary:
When compile_commands.json contains some source files expressed as
relative paths, we can get duplicate responses to findDefinitions. The
responses only differ by the URI, which are different versions of the
same file:
"result": [
{
...
"uri": "file:///home/emaisin/src/ls-interact/cpp-test/build/../src/first.h"
},
{
...
"uri": "file:///home/emaisin/src/ls-interact/cpp-test/src/first.h"
}
]
In getAbsoluteFilePath, we try to obtain the realpath of the FileEntry
by calling tryGetRealPathName. However, this can fail and return an
empty string. It may be bug a bug in clang, but in any case we should
fall back to computing it ourselves if it happens.
I changed getAbsoluteFilePath so that if tryGetRealPathName succeeds, we
return right away (a real path is always absolute). Otherwise, we try
to build an absolute path, as we did before, but we also call
VFS->getRealPath to make sure to get the canonical path (e.g. without
any ".." in it).
Reviewers: malaperle
Subscribers: hokein, ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D48687
llvm-svn: 339483
2018-08-11 06:27:53 +08:00
|
|
|
|
2018-12-19 18:46:21 +08:00
|
|
|
// Handle the symbolic link path case where the current working directory
|
2019-09-09 20:28:44 +08:00
|
|
|
// (getCurrentWorkingDirectory) is a symlink. We always want to the real
|
2018-12-19 18:46:21 +08:00
|
|
|
// file path (instead of the symlink path) for the C++ symbols.
|
|
|
|
//
|
|
|
|
// Consider the following example:
|
|
|
|
//
|
|
|
|
// src dir: /project/src/foo.h
|
|
|
|
// current working directory (symlink): /tmp/build -> /project/src/
|
|
|
|
//
|
|
|
|
// The file path of Symbol is "/project/src/foo.h" instead of
|
|
|
|
// "/tmp/build/foo.h"
|
2019-08-02 05:32:01 +08:00
|
|
|
if (auto Dir = SourceMgr.getFileManager().getDirectory(
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::sys::path::parent_path(FilePath))) {
|
|
|
|
llvm::SmallString<128> RealPath;
|
2019-08-02 05:32:01 +08:00
|
|
|
llvm::StringRef DirName = SourceMgr.getFileManager().getCanonicalName(*Dir);
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::sys::path::append(RealPath, DirName,
|
|
|
|
llvm::sys::path::filename(FilePath));
|
2018-12-19 18:46:21 +08:00
|
|
|
return RealPath.str().str();
|
[clangd] Avoid duplicates in findDefinitions response
Summary:
When compile_commands.json contains some source files expressed as
relative paths, we can get duplicate responses to findDefinitions. The
responses only differ by the URI, which are different versions of the
same file:
"result": [
{
...
"uri": "file:///home/emaisin/src/ls-interact/cpp-test/build/../src/first.h"
},
{
...
"uri": "file:///home/emaisin/src/ls-interact/cpp-test/src/first.h"
}
]
In getAbsoluteFilePath, we try to obtain the realpath of the FileEntry
by calling tryGetRealPathName. However, this can fail and return an
empty string. It may be bug a bug in clang, but in any case we should
fall back to computing it ourselves if it happens.
I changed getAbsoluteFilePath so that if tryGetRealPathName succeeds, we
return right away (a real path is always absolute). Otherwise, we try
to build an absolute path, as we did before, but we also call
VFS->getRealPath to make sure to get the canonical path (e.g. without
any ".." in it).
Reviewers: malaperle
Subscribers: hokein, ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D48687
llvm-svn: 339483
2018-08-11 06:27:53 +08:00
|
|
|
}
|
|
|
|
|
2018-12-19 18:46:21 +08:00
|
|
|
return FilePath.str().str();
|
2018-07-06 03:35:01 +08:00
|
|
|
}
|
|
|
|
|
2018-08-08 16:59:29 +08:00
|
|
|
TextEdit toTextEdit(const FixItHint &FixIt, const SourceManager &M,
|
|
|
|
const LangOptions &L) {
|
|
|
|
TextEdit Result;
|
|
|
|
Result.range =
|
|
|
|
halfOpenToRange(M, Lexer::makeFileCharRange(FixIt.RemoveRange, M, L));
|
|
|
|
Result.newText = FixIt.CodeToInsert;
|
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
FileDigest digest(llvm::StringRef Content) {
|
[clangd] Use xxhash instead of SHA1 for background index file digests.
Summary:
Currently SHA1 is about 10% of our CPU, this patch reduces it to ~1%.
xxhash is a well-defined (stable) non-cryptographic hash optimized for
fast checksums (like crc32).
Collisions shouldn't be a problem, despite the reduced length:
- for actual file content (used to invalidate bg index shards), there
are only two versions that can collide (new shard and old shard).
- for file paths in bg index shard filenames, we would need 2^32 files
with the same filename to expect a collision. Imperfect hashing may
reduce this a bit but it's well beyond what's plausible.
This will invalidate shards on disk (as usual; I bumped the version),
but this time the filenames are changing so the old files will stick
around :-( So this is more expensive than the usual bump, but would be
good to land before the v9 branch when everyone will start using bg index.
Reviewers: kadircet
Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D64306
llvm-svn: 365311
2019-07-08 19:33:17 +08:00
|
|
|
uint64_t Hash{llvm::xxHash64(Content)};
|
|
|
|
FileDigest Result;
|
|
|
|
for (unsigned I = 0; I < Result.size(); ++I) {
|
|
|
|
Result[I] = uint8_t(Hash);
|
|
|
|
Hash >>= 8;
|
|
|
|
}
|
|
|
|
return Result;
|
2018-11-28 00:08:53 +08:00
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::Optional<FileDigest> digestFile(const SourceManager &SM, FileID FID) {
|
2018-11-28 00:08:53 +08:00
|
|
|
bool Invalid = false;
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::StringRef Content = SM.getBufferData(FID, &Invalid);
|
2018-11-28 00:08:53 +08:00
|
|
|
if (Invalid)
|
|
|
|
return None;
|
|
|
|
return digest(Content);
|
|
|
|
}
|
|
|
|
|
2020-06-17 17:53:32 +08:00
|
|
|
format::FormatStyle getFormatStyleForFile(llvm::StringRef File,
|
|
|
|
llvm::StringRef Content,
|
2020-06-18 00:09:54 +08:00
|
|
|
const ThreadsafeFS &TFS) {
|
2020-06-17 17:53:32 +08:00
|
|
|
auto Style = format::getStyle(format::DefaultFormatStyle, File,
|
|
|
|
format::DefaultFallbackStyle, Content,
|
2020-06-18 00:09:54 +08:00
|
|
|
TFS.view(/*CWD=*/llvm::None).get());
|
2019-01-28 22:01:55 +08:00
|
|
|
if (!Style) {
|
|
|
|
log("getStyle() failed for file {0}: {1}. Fallback is LLVM style.", File,
|
|
|
|
Style.takeError());
|
2020-05-04 04:13:49 +08:00
|
|
|
return format::getLLVMStyle();
|
2019-01-28 22:01:55 +08:00
|
|
|
}
|
|
|
|
return *Style;
|
|
|
|
}
|
|
|
|
|
2019-02-06 23:24:50 +08:00
|
|
|
llvm::Expected<tooling::Replacements>
|
|
|
|
cleanupAndFormat(StringRef Code, const tooling::Replacements &Replaces,
|
|
|
|
const format::FormatStyle &Style) {
|
|
|
|
auto CleanReplaces = cleanupAroundReplacements(Code, Replaces, Style);
|
|
|
|
if (!CleanReplaces)
|
|
|
|
return CleanReplaces;
|
|
|
|
return formatReplacements(Code, std::move(*CleanReplaces), Style);
|
|
|
|
}
|
|
|
|
|
2019-11-07 17:53:19 +08:00
|
|
|
static void
|
|
|
|
lex(llvm::StringRef Code, const LangOptions &LangOpts,
|
2020-02-27 22:10:54 +08:00
|
|
|
llvm::function_ref<void(const syntax::Token &, const SourceManager &SM)>
|
2019-11-07 17:53:19 +08:00
|
|
|
Action) {
|
2019-04-26 15:45:49 +08:00
|
|
|
// FIXME: InMemoryFileAdapter crashes unless the buffer is null terminated!
|
|
|
|
std::string NullTerminatedCode = Code.str();
|
|
|
|
SourceManagerForFile FileSM("dummy.cpp", NullTerminatedCode);
|
2019-04-11 17:36:36 +08:00
|
|
|
auto &SM = FileSM.get();
|
2020-02-27 22:10:54 +08:00
|
|
|
for (const auto &Tok : syntax::tokenize(SM.getMainFileID(), SM, LangOpts))
|
2019-10-30 20:21:47 +08:00
|
|
|
Action(Tok, SM);
|
2019-04-26 15:45:49 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
llvm::StringMap<unsigned> collectIdentifiers(llvm::StringRef Content,
|
|
|
|
const format::FormatStyle &Style) {
|
2019-04-11 17:36:36 +08:00
|
|
|
llvm::StringMap<unsigned> Identifiers;
|
2019-10-30 20:21:47 +08:00
|
|
|
auto LangOpt = format::getFormattingLangOpts(Style);
|
2020-02-27 22:10:54 +08:00
|
|
|
lex(Content, LangOpt, [&](const syntax::Token &Tok, const SourceManager &SM) {
|
|
|
|
if (Tok.kind() == tok::identifier)
|
|
|
|
++Identifiers[Tok.text(SM)];
|
|
|
|
// FIXME: Should this function really return keywords too ?
|
|
|
|
else if (const auto *Keyword = tok::getKeywordSpelling(Tok.kind()))
|
|
|
|
++Identifiers[Keyword];
|
2019-04-26 15:45:49 +08:00
|
|
|
});
|
2019-04-11 17:36:36 +08:00
|
|
|
return Identifiers;
|
|
|
|
}
|
|
|
|
|
2019-10-30 20:21:47 +08:00
|
|
|
std::vector<Range> collectIdentifierRanges(llvm::StringRef Identifier,
|
|
|
|
llvm::StringRef Content,
|
|
|
|
const LangOptions &LangOpts) {
|
|
|
|
std::vector<Range> Ranges;
|
2020-02-27 22:10:54 +08:00
|
|
|
lex(Content, LangOpts,
|
|
|
|
[&](const syntax::Token &Tok, const SourceManager &SM) {
|
|
|
|
if (Tok.kind() != tok::identifier || Tok.text(SM) != Identifier)
|
|
|
|
return;
|
2020-03-01 23:05:12 +08:00
|
|
|
Ranges.push_back(halfOpenToRange(SM, Tok.range(SM).toCharRange(SM)));
|
2020-02-27 22:10:54 +08:00
|
|
|
});
|
2019-10-30 20:21:47 +08:00
|
|
|
return Ranges;
|
|
|
|
}
|
|
|
|
|
2020-10-05 21:10:53 +08:00
|
|
|
bool isKeyword(llvm::StringRef NewName, const LangOptions &LangOpts) {
|
|
|
|
// Keywords are initialized in constructor.
|
|
|
|
clang::IdentifierTable KeywordsTable(LangOpts);
|
|
|
|
return KeywordsTable.find(NewName) != KeywordsTable.end();
|
|
|
|
}
|
|
|
|
|
2019-04-26 15:45:49 +08:00
|
|
|
namespace {
|
2019-09-25 17:35:38 +08:00
|
|
|
struct NamespaceEvent {
|
|
|
|
enum {
|
|
|
|
BeginNamespace, // namespace <ns> {. Payload is resolved <ns>.
|
|
|
|
EndNamespace, // } // namespace <ns>. Payload is resolved *outer*
|
|
|
|
// namespace.
|
|
|
|
UsingDirective // using namespace <ns>. Payload is unresolved <ns>.
|
|
|
|
} Trigger;
|
|
|
|
std::string Payload;
|
|
|
|
Position Pos;
|
2019-04-26 15:45:49 +08:00
|
|
|
};
|
|
|
|
// Scans C++ source code for constructs that change the visible namespaces.
|
2020-03-06 08:03:26 +08:00
|
|
|
void parseNamespaceEvents(llvm::StringRef Code, const LangOptions &LangOpts,
|
2019-09-25 17:35:38 +08:00
|
|
|
llvm::function_ref<void(NamespaceEvent)> Callback) {
|
2019-04-26 15:45:49 +08:00
|
|
|
|
|
|
|
// Stack of enclosing namespaces, e.g. {"clang", "clangd"}
|
|
|
|
std::vector<std::string> Enclosing; // Contains e.g. "clang", "clangd"
|
|
|
|
// Stack counts open braces. true if the brace opened a namespace.
|
|
|
|
std::vector<bool> BraceStack;
|
|
|
|
|
|
|
|
enum {
|
|
|
|
Default,
|
|
|
|
Namespace, // just saw 'namespace'
|
|
|
|
NamespaceName, // just saw 'namespace' NSName
|
|
|
|
Using, // just saw 'using'
|
|
|
|
UsingNamespace, // just saw 'using namespace'
|
|
|
|
UsingNamespaceName, // just saw 'using namespace' NSName
|
|
|
|
} State = Default;
|
|
|
|
std::string NSName;
|
|
|
|
|
2019-09-25 17:35:38 +08:00
|
|
|
NamespaceEvent Event;
|
2020-03-06 08:03:26 +08:00
|
|
|
lex(Code, LangOpts, [&](const syntax::Token &Tok, const SourceManager &SM) {
|
|
|
|
Event.Pos = sourceLocToPosition(SM, Tok.location());
|
|
|
|
switch (Tok.kind()) {
|
|
|
|
case tok::kw_using:
|
|
|
|
State = State == Default ? Using : Default;
|
|
|
|
break;
|
|
|
|
case tok::kw_namespace:
|
|
|
|
switch (State) {
|
|
|
|
case Using:
|
|
|
|
State = UsingNamespace;
|
|
|
|
break;
|
|
|
|
case Default:
|
|
|
|
State = Namespace;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
State = Default;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case tok::identifier:
|
|
|
|
switch (State) {
|
|
|
|
case UsingNamespace:
|
|
|
|
NSName.clear();
|
|
|
|
LLVM_FALLTHROUGH;
|
|
|
|
case UsingNamespaceName:
|
|
|
|
NSName.append(Tok.text(SM).str());
|
|
|
|
State = UsingNamespaceName;
|
|
|
|
break;
|
|
|
|
case Namespace:
|
|
|
|
NSName.clear();
|
|
|
|
LLVM_FALLTHROUGH;
|
|
|
|
case NamespaceName:
|
|
|
|
NSName.append(Tok.text(SM).str());
|
|
|
|
State = NamespaceName;
|
|
|
|
break;
|
|
|
|
case Using:
|
|
|
|
case Default:
|
|
|
|
State = Default;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case tok::coloncolon:
|
|
|
|
// This can come at the beginning or in the middle of a namespace
|
|
|
|
// name.
|
|
|
|
switch (State) {
|
|
|
|
case UsingNamespace:
|
|
|
|
NSName.clear();
|
|
|
|
LLVM_FALLTHROUGH;
|
|
|
|
case UsingNamespaceName:
|
|
|
|
NSName.append("::");
|
|
|
|
State = UsingNamespaceName;
|
|
|
|
break;
|
|
|
|
case NamespaceName:
|
|
|
|
NSName.append("::");
|
|
|
|
State = NamespaceName;
|
|
|
|
break;
|
|
|
|
case Namespace: // Not legal here.
|
|
|
|
case Using:
|
|
|
|
case Default:
|
|
|
|
State = Default;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case tok::l_brace:
|
|
|
|
// Record which { started a namespace, so we know when } ends one.
|
|
|
|
if (State == NamespaceName) {
|
|
|
|
// Parsed: namespace <name> {
|
|
|
|
BraceStack.push_back(true);
|
|
|
|
Enclosing.push_back(NSName);
|
|
|
|
Event.Trigger = NamespaceEvent::BeginNamespace;
|
|
|
|
Event.Payload = llvm::join(Enclosing, "::");
|
|
|
|
Callback(Event);
|
|
|
|
} else {
|
|
|
|
// This case includes anonymous namespaces (State = Namespace).
|
|
|
|
// For our purposes, they're not namespaces and we ignore them.
|
|
|
|
BraceStack.push_back(false);
|
|
|
|
}
|
|
|
|
State = Default;
|
|
|
|
break;
|
|
|
|
case tok::r_brace:
|
|
|
|
// If braces are unmatched, we're going to be confused, but don't
|
|
|
|
// crash.
|
|
|
|
if (!BraceStack.empty()) {
|
|
|
|
if (BraceStack.back()) {
|
|
|
|
// Parsed: } // namespace
|
|
|
|
Enclosing.pop_back();
|
|
|
|
Event.Trigger = NamespaceEvent::EndNamespace;
|
|
|
|
Event.Payload = llvm::join(Enclosing, "::");
|
|
|
|
Callback(Event);
|
2019-04-26 15:45:49 +08:00
|
|
|
}
|
2020-03-06 08:03:26 +08:00
|
|
|
BraceStack.pop_back();
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case tok::semi:
|
|
|
|
if (State == UsingNamespaceName) {
|
|
|
|
// Parsed: using namespace <name> ;
|
|
|
|
Event.Trigger = NamespaceEvent::UsingDirective;
|
|
|
|
Event.Payload = std::move(NSName);
|
|
|
|
Callback(Event);
|
|
|
|
}
|
|
|
|
State = Default;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
State = Default;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
});
|
2019-04-26 15:45:49 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Returns the prefix namespaces of NS: {"" ... NS}.
|
|
|
|
llvm::SmallVector<llvm::StringRef, 8> ancestorNamespaces(llvm::StringRef NS) {
|
|
|
|
llvm::SmallVector<llvm::StringRef, 8> Results;
|
|
|
|
Results.push_back(NS.take_front(0));
|
|
|
|
NS.split(Results, "::", /*MaxSplit=*/-1, /*KeepEmpty=*/false);
|
|
|
|
for (llvm::StringRef &R : Results)
|
|
|
|
R = NS.take_front(R.end() - NS.begin());
|
|
|
|
return Results;
|
|
|
|
}
|
|
|
|
|
|
|
|
} // namespace
|
|
|
|
|
|
|
|
std::vector<std::string> visibleNamespaces(llvm::StringRef Code,
|
2020-03-06 08:03:26 +08:00
|
|
|
const LangOptions &LangOpts) {
|
2019-04-26 15:45:49 +08:00
|
|
|
std::string Current;
|
|
|
|
// Map from namespace to (resolved) namespaces introduced via using directive.
|
|
|
|
llvm::StringMap<llvm::StringSet<>> UsingDirectives;
|
|
|
|
|
2020-03-06 08:03:26 +08:00
|
|
|
parseNamespaceEvents(Code, LangOpts, [&](NamespaceEvent Event) {
|
2019-09-25 17:35:38 +08:00
|
|
|
llvm::StringRef NS = Event.Payload;
|
|
|
|
switch (Event.Trigger) {
|
|
|
|
case NamespaceEvent::BeginNamespace:
|
|
|
|
case NamespaceEvent::EndNamespace:
|
|
|
|
Current = std::move(Event.Payload);
|
|
|
|
break;
|
|
|
|
case NamespaceEvent::UsingDirective:
|
|
|
|
if (NS.consume_front("::"))
|
|
|
|
UsingDirectives[Current].insert(NS);
|
|
|
|
else {
|
|
|
|
for (llvm::StringRef Enclosing : ancestorNamespaces(Current)) {
|
|
|
|
if (Enclosing.empty())
|
|
|
|
UsingDirectives[Current].insert(NS);
|
|
|
|
else
|
|
|
|
UsingDirectives[Current].insert((Enclosing + "::" + NS).str());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
});
|
2019-04-26 15:45:49 +08:00
|
|
|
|
|
|
|
std::vector<std::string> Found;
|
|
|
|
for (llvm::StringRef Enclosing : ancestorNamespaces(Current)) {
|
2020-01-29 03:23:46 +08:00
|
|
|
Found.push_back(std::string(Enclosing));
|
2019-04-26 15:45:49 +08:00
|
|
|
auto It = UsingDirectives.find(Enclosing);
|
|
|
|
if (It != UsingDirectives.end())
|
2019-09-25 17:35:38 +08:00
|
|
|
for (const auto &Used : It->second)
|
2020-01-29 03:23:46 +08:00
|
|
|
Found.push_back(std::string(Used.getKey()));
|
2019-04-26 15:45:49 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
llvm::sort(Found, [&](const std::string &LHS, const std::string &RHS) {
|
|
|
|
if (Current == RHS)
|
|
|
|
return false;
|
|
|
|
if (Current == LHS)
|
|
|
|
return true;
|
|
|
|
return LHS < RHS;
|
|
|
|
});
|
|
|
|
Found.erase(std::unique(Found.begin(), Found.end()), Found.end());
|
|
|
|
return Found;
|
|
|
|
}
|
|
|
|
|
2019-05-06 18:25:10 +08:00
|
|
|
llvm::StringSet<> collectWords(llvm::StringRef Content) {
|
|
|
|
// We assume short words are not significant.
|
|
|
|
// We may want to consider other stopwords, e.g. language keywords.
|
|
|
|
// (A very naive implementation showed no benefit, but lexing might do better)
|
|
|
|
static constexpr int MinWordLength = 4;
|
|
|
|
|
|
|
|
std::vector<CharRole> Roles(Content.size());
|
|
|
|
calculateRoles(Content, Roles);
|
|
|
|
|
|
|
|
llvm::StringSet<> Result;
|
|
|
|
llvm::SmallString<256> Word;
|
|
|
|
auto Flush = [&] {
|
|
|
|
if (Word.size() >= MinWordLength) {
|
|
|
|
for (char &C : Word)
|
|
|
|
C = llvm::toLower(C);
|
|
|
|
Result.insert(Word);
|
|
|
|
}
|
|
|
|
Word.clear();
|
|
|
|
};
|
|
|
|
for (unsigned I = 0; I < Content.size(); ++I) {
|
|
|
|
switch (Roles[I]) {
|
|
|
|
case Head:
|
|
|
|
Flush();
|
|
|
|
LLVM_FALLTHROUGH;
|
|
|
|
case Tail:
|
|
|
|
Word.push_back(Content[I]);
|
|
|
|
break;
|
|
|
|
case Unknown:
|
|
|
|
case Separator:
|
|
|
|
Flush();
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
Flush();
|
|
|
|
|
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
|
2020-03-03 05:45:25 +08:00
|
|
|
static bool isLikelyIdentifier(llvm::StringRef Word, llvm::StringRef Before,
|
|
|
|
llvm::StringRef After) {
|
|
|
|
// `foo` is an identifier.
|
|
|
|
if (Before.endswith("`") && After.startswith("`"))
|
|
|
|
return true;
|
|
|
|
// In foo::bar, both foo and bar are identifiers.
|
|
|
|
if (Before.endswith("::") || After.startswith("::"))
|
|
|
|
return true;
|
|
|
|
// Doxygen tags like \c foo indicate identifiers.
|
|
|
|
// Don't search too far back.
|
|
|
|
// This duplicates clang's doxygen parser, revisit if it gets complicated.
|
|
|
|
Before = Before.take_back(100); // Don't search too far back.
|
|
|
|
auto Pos = Before.find_last_of("\\@");
|
|
|
|
if (Pos != llvm::StringRef::npos) {
|
|
|
|
llvm::StringRef Tag = Before.substr(Pos + 1).rtrim(' ');
|
|
|
|
if (Tag == "p" || Tag == "c" || Tag == "class" || Tag == "tparam" ||
|
|
|
|
Tag == "param" || Tag == "param[in]" || Tag == "param[out]" ||
|
|
|
|
Tag == "param[in,out]" || Tag == "retval" || Tag == "throw" ||
|
|
|
|
Tag == "throws" || Tag == "link")
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Word contains underscore.
|
|
|
|
// This handles things like snake_case and MACRO_CASE.
|
|
|
|
if (Word.contains('_')) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
// Word contains capital letter other than at beginning.
|
|
|
|
// This handles things like lowerCamel and UpperCamel.
|
|
|
|
// The check for also containing a lowercase letter is to rule out
|
|
|
|
// initialisms like "HTTP".
|
|
|
|
bool HasLower = Word.find_if(clang::isLowercase) != StringRef::npos;
|
|
|
|
bool HasUpper = Word.substr(1).find_if(clang::isUppercase) != StringRef::npos;
|
|
|
|
if (HasLower && HasUpper) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
// FIXME: consider mid-sentence Capitalization?
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::Optional<SpelledWord> SpelledWord::touching(SourceLocation SpelledLoc,
|
|
|
|
const syntax::TokenBuffer &TB,
|
|
|
|
const LangOptions &LangOpts) {
|
|
|
|
const auto &SM = TB.sourceManager();
|
|
|
|
auto Touching = syntax::spelledTokensTouching(SpelledLoc, TB);
|
|
|
|
for (const auto &T : Touching) {
|
|
|
|
// If the token is an identifier or a keyword, don't use any heuristics.
|
|
|
|
if (tok::isAnyIdentifier(T.kind()) || tok::getKeywordSpelling(T.kind())) {
|
|
|
|
SpelledWord Result;
|
|
|
|
Result.Location = T.location();
|
|
|
|
Result.Text = T.text(SM);
|
|
|
|
Result.LikelyIdentifier = tok::isAnyIdentifier(T.kind());
|
|
|
|
Result.PartOfSpelledToken = &T;
|
|
|
|
Result.SpelledToken = &T;
|
|
|
|
auto Expanded =
|
|
|
|
TB.expandedTokens(SM.getMacroArgExpandedLocation(T.location()));
|
|
|
|
if (Expanded.size() == 1 && Expanded.front().text(SM) == Result.Text)
|
|
|
|
Result.ExpandedToken = &Expanded.front();
|
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
FileID File;
|
|
|
|
unsigned Offset;
|
|
|
|
std::tie(File, Offset) = SM.getDecomposedLoc(SpelledLoc);
|
|
|
|
bool Invalid = false;
|
|
|
|
llvm::StringRef Code = SM.getBufferData(File, &Invalid);
|
|
|
|
if (Invalid)
|
|
|
|
return llvm::None;
|
|
|
|
unsigned B = Offset, E = Offset;
|
|
|
|
while (B > 0 && isIdentifierBody(Code[B - 1]))
|
|
|
|
--B;
|
|
|
|
while (E < Code.size() && isIdentifierBody(Code[E]))
|
|
|
|
++E;
|
|
|
|
if (B == E)
|
|
|
|
return llvm::None;
|
|
|
|
|
|
|
|
SpelledWord Result;
|
|
|
|
Result.Location = SM.getComposedLoc(File, B);
|
|
|
|
Result.Text = Code.slice(B, E);
|
|
|
|
Result.LikelyIdentifier =
|
|
|
|
isLikelyIdentifier(Result.Text, Code.substr(0, B), Code.substr(E)) &&
|
|
|
|
// should not be a keyword
|
|
|
|
tok::isAnyIdentifier(
|
|
|
|
IdentifierTable(LangOpts).get(Result.Text).getTokenID());
|
|
|
|
for (const auto &T : Touching)
|
|
|
|
if (T.location() <= Result.Location)
|
|
|
|
Result.PartOfSpelledToken = &T;
|
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
|
2020-02-28 16:25:40 +08:00
|
|
|
llvm::Optional<DefinedMacro> locateMacroAt(const syntax::Token &SpelledTok,
|
2019-07-01 17:26:48 +08:00
|
|
|
Preprocessor &PP) {
|
2020-02-28 16:25:40 +08:00
|
|
|
SourceLocation Loc = SpelledTok.location();
|
2020-02-27 23:02:44 +08:00
|
|
|
assert(Loc.isFileID());
|
2019-07-01 17:26:48 +08:00
|
|
|
const auto &SM = PP.getSourceManager();
|
2020-02-28 16:25:40 +08:00
|
|
|
IdentifierInfo *IdentifierInfo = PP.getIdentifierInfo(SpelledTok.text(SM));
|
2019-07-01 17:26:48 +08:00
|
|
|
if (!IdentifierInfo || !IdentifierInfo->hadMacroDefinition())
|
|
|
|
return None;
|
|
|
|
|
|
|
|
// Get the definition just before the searched location so that a macro
|
2020-02-27 23:02:44 +08:00
|
|
|
// referenced in a '#undef MACRO' can still be found. Note that we only do
|
|
|
|
// that if Loc is not pointing at start of file.
|
|
|
|
if (SM.getLocForStartOfFile(SM.getFileID(Loc)) != Loc)
|
|
|
|
Loc = Loc.getLocWithOffset(-1);
|
|
|
|
MacroDefinition MacroDef = PP.getMacroDefinitionAtLoc(IdentifierInfo, Loc);
|
2019-07-01 17:26:48 +08:00
|
|
|
if (auto *MI = MacroDef.getMacroInfo())
|
[clangd] locateMacroAt handles patched macros
Summary: Depends on D79992.
This patch changes locateMacroAt to perform #line directive substitution
for macro identifier locations.
We first check whether a location is inside a file included through
built-in header. If so we check whether line directive maps it back to
the main file, and afterwards use TokenBuffers to find exact location of
the identifier on the line.
Instead of performing the mapping in locateMacroAt, we could also store
a mapping inside the ParsedAST whenever we use a patched preamble. But
that would imply adding more responsibility to ParsedAST and paying for
the mapping even when it is not going to be used.
====
Go-To-Definition:
Later on these locations are used for serving go-to-definition requests,
this enables jumping to definition inside the preamble section in
presence of patched macros.
=====
Go-To-Refs:
Macro references in main file are collected separetely and stored as a
map from macro's symbol id to reference ranges. Those ranges are
computed inside PPCallbacks, hence we don't have access to TokenBuffer.
In presence of preamble patch, any reference to a macro inside the
preamble section will unfortunately have the wrong range. They'll point
into the patch rather than the main file. Hence during findReferences,
we won't get any ranges reported for those.
Fixing those requires:
- Lexing the preamble section to figure out "real range" of a patched
macro definition
- Postponing range/location calculations until a later step in which we
have access to tokenbuffers.
This patch trades some accuracy in favor of code complexity. We don't do
any patching for references inside the preamble patch but get any
reference inside the main file for free.
Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D80198
2020-05-14 18:26:47 +08:00
|
|
|
return DefinedMacro{
|
|
|
|
IdentifierInfo->getName(), MI,
|
|
|
|
translatePreamblePatchLocation(MI->getDefinitionLoc(), SM)};
|
2019-07-01 17:26:48 +08:00
|
|
|
return None;
|
|
|
|
}
|
|
|
|
|
2019-09-09 20:28:44 +08:00
|
|
|
llvm::Expected<std::string> Edit::apply() const {
|
|
|
|
return tooling::applyAllReplacements(InitialCode, Replacements);
|
|
|
|
}
|
|
|
|
|
|
|
|
std::vector<TextEdit> Edit::asTextEdits() const {
|
|
|
|
return replacementsToEdits(InitialCode, Replacements);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool Edit::canApplyTo(llvm::StringRef Code) const {
|
|
|
|
// Create line iterators, since line numbers are important while applying our
|
|
|
|
// edit we cannot skip blank lines.
|
|
|
|
auto LHS = llvm::MemoryBuffer::getMemBuffer(Code);
|
|
|
|
llvm::line_iterator LHSIt(*LHS, /*SkipBlanks=*/false);
|
|
|
|
|
|
|
|
auto RHS = llvm::MemoryBuffer::getMemBuffer(InitialCode);
|
|
|
|
llvm::line_iterator RHSIt(*RHS, /*SkipBlanks=*/false);
|
|
|
|
|
|
|
|
// Compare the InitialCode we prepared the edit for with the Code we received
|
|
|
|
// line by line to make sure there are no differences.
|
|
|
|
// FIXME: This check is too conservative now, it should be enough to only
|
|
|
|
// check lines around the replacements contained inside the Edit.
|
|
|
|
while (!LHSIt.is_at_eof() && !RHSIt.is_at_eof()) {
|
|
|
|
if (*LHSIt != *RHSIt)
|
|
|
|
return false;
|
|
|
|
++LHSIt;
|
|
|
|
++RHSIt;
|
|
|
|
}
|
|
|
|
|
|
|
|
// After we reach EOF for any of the files we make sure the other one doesn't
|
|
|
|
// contain any additional content except empty lines, they should not
|
|
|
|
// interfere with the edit we produced.
|
|
|
|
while (!LHSIt.is_at_eof()) {
|
|
|
|
if (!LHSIt->empty())
|
|
|
|
return false;
|
|
|
|
++LHSIt;
|
|
|
|
}
|
|
|
|
while (!RHSIt.is_at_eof()) {
|
|
|
|
if (!RHSIt->empty())
|
|
|
|
return false;
|
|
|
|
++RHSIt;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::Error reformatEdit(Edit &E, const format::FormatStyle &Style) {
|
|
|
|
if (auto NewEdits = cleanupAndFormat(E.InitialCode, E.Replacements, Style))
|
|
|
|
E.Replacements = std::move(*NewEdits);
|
|
|
|
else
|
|
|
|
return NewEdits.takeError();
|
|
|
|
return llvm::Error::success();
|
|
|
|
}
|
|
|
|
|
2019-09-25 17:35:38 +08:00
|
|
|
EligibleRegion getEligiblePoints(llvm::StringRef Code,
|
|
|
|
llvm::StringRef FullyQualifiedName,
|
2020-03-06 08:03:26 +08:00
|
|
|
const LangOptions &LangOpts) {
|
2019-09-25 17:35:38 +08:00
|
|
|
EligibleRegion ER;
|
|
|
|
// Start with global namespace.
|
|
|
|
std::vector<std::string> Enclosing = {""};
|
|
|
|
// FIXME: In addition to namespaces try to generate events for function
|
|
|
|
// definitions as well. One might use a closing parantheses(")" followed by an
|
|
|
|
// opening brace "{" to trigger the start.
|
2020-03-06 08:03:26 +08:00
|
|
|
parseNamespaceEvents(Code, LangOpts, [&](NamespaceEvent Event) {
|
2019-09-25 17:35:38 +08:00
|
|
|
// Using Directives only introduces declarations to current scope, they do
|
|
|
|
// not change the current namespace, so skip them.
|
|
|
|
if (Event.Trigger == NamespaceEvent::UsingDirective)
|
|
|
|
return;
|
|
|
|
// Do not qualify the global namespace.
|
|
|
|
if (!Event.Payload.empty())
|
|
|
|
Event.Payload.append("::");
|
|
|
|
|
|
|
|
std::string CurrentNamespace;
|
|
|
|
if (Event.Trigger == NamespaceEvent::BeginNamespace) {
|
|
|
|
Enclosing.emplace_back(std::move(Event.Payload));
|
|
|
|
CurrentNamespace = Enclosing.back();
|
|
|
|
// parseNameSpaceEvents reports the beginning position of a token; we want
|
|
|
|
// to insert after '{', so increment by one.
|
|
|
|
++Event.Pos.character;
|
|
|
|
} else {
|
|
|
|
// Event.Payload points to outer namespace when exiting a scope, so use
|
|
|
|
// the namespace we've last entered instead.
|
|
|
|
CurrentNamespace = std::move(Enclosing.back());
|
|
|
|
Enclosing.pop_back();
|
|
|
|
assert(Enclosing.back() == Event.Payload);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Ignore namespaces that are not a prefix of the target.
|
|
|
|
if (!FullyQualifiedName.startswith(CurrentNamespace))
|
|
|
|
return;
|
|
|
|
|
|
|
|
// Prefer the namespace that shares the longest prefix with target.
|
|
|
|
if (CurrentNamespace.size() > ER.EnclosingNamespace.size()) {
|
|
|
|
ER.EligiblePoints.clear();
|
|
|
|
ER.EnclosingNamespace = CurrentNamespace;
|
|
|
|
}
|
|
|
|
if (CurrentNamespace.size() == ER.EnclosingNamespace.size())
|
|
|
|
ER.EligiblePoints.emplace_back(std::move(Event.Pos));
|
|
|
|
});
|
|
|
|
// If there were no shared namespaces just return EOF.
|
|
|
|
if (ER.EligiblePoints.empty()) {
|
|
|
|
assert(ER.EnclosingNamespace.empty());
|
|
|
|
ER.EligiblePoints.emplace_back(offsetToPosition(Code, Code.size()));
|
|
|
|
}
|
|
|
|
return ER;
|
|
|
|
}
|
|
|
|
|
[clangd] Add isHeaderFile helper.
Summary:
we have a few places using `ASTCtx.getLangOpts().IsHeaderFile` to
determine a header file, but it relies on "-x c-header" compiler flag,
if the compilation command doesn't have this flag, we will get a false
positive. We are encountering this issue in bazel build system.
To solve this problem, we infer the file from file name, actual changes will
come in follow-ups.
Reviewers: sammccall
Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D70235
2019-11-13 23:30:07 +08:00
|
|
|
bool isHeaderFile(llvm::StringRef FileName,
|
|
|
|
llvm::Optional<LangOptions> LangOpts) {
|
|
|
|
// Respect the langOpts, for non-file-extension cases, e.g. standard library
|
|
|
|
// files.
|
|
|
|
if (LangOpts && LangOpts->IsHeaderFile)
|
|
|
|
return true;
|
|
|
|
namespace types = clang::driver::types;
|
|
|
|
auto Lang = types::lookupTypeForExtension(
|
|
|
|
llvm::sys::path::extension(FileName).substr(1));
|
|
|
|
return Lang != types::TY_INVALID && types::onlyPrecompileType(Lang);
|
|
|
|
}
|
|
|
|
|
2020-02-05 19:03:29 +08:00
|
|
|
bool isProtoFile(SourceLocation Loc, const SourceManager &SM) {
|
|
|
|
auto FileName = SM.getFilename(Loc);
|
|
|
|
if (!FileName.endswith(".proto.h") && !FileName.endswith(".pb.h"))
|
|
|
|
return false;
|
|
|
|
auto FID = SM.getFileID(Loc);
|
|
|
|
// All proto generated headers should start with this line.
|
|
|
|
static const char *PROTO_HEADER_COMMENT =
|
|
|
|
"// Generated by the protocol buffer compiler. DO NOT EDIT!";
|
|
|
|
// Double check that this is an actual protobuf header.
|
|
|
|
return SM.getBufferData(FID).startswith(PROTO_HEADER_COMMENT);
|
|
|
|
}
|
|
|
|
|
2017-12-19 20:23:48 +08:00
|
|
|
} // namespace clangd
|
|
|
|
} // namespace clang
|