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-03-28 01:47:49 +08:00
|
|
|
#include "Context.h"
|
2018-07-06 03:35:01 +08:00
|
|
|
#include "Logger.h"
|
2019-03-28 01:47:49 +08:00
|
|
|
#include "Protocol.h"
|
2018-07-06 03:35:01 +08:00
|
|
|
#include "clang/AST/ASTContext.h"
|
2018-02-21 10:39:08 +08:00
|
|
|
#include "clang/Basic/SourceManager.h"
|
2018-07-06 03:35:01 +08:00
|
|
|
#include "clang/Lex/Lexer.h"
|
2019-02-01 05:30:05 +08:00
|
|
|
#include "llvm/ADT/None.h"
|
|
|
|
#include "llvm/ADT/StringRef.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"
|
2018-07-06 03:35:01 +08:00
|
|
|
#include "llvm/Support/Path.h"
|
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.
|
|
|
|
template <typename Callback>
|
2019-01-07 23:45:19 +08:00
|
|
|
static bool iterateCodepoints(llvm::StringRef U8, const Callback &CB) {
|
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.
|
|
|
|
// 11111xxx is not valid UTF-8 at all. Assert because it's probably our bug.
|
|
|
|
assert((UTF8Length >= 2 && UTF8Length <= 4) &&
|
|
|
|
"Invalid UTF-8, or transcoding bug?");
|
|
|
|
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)
|
2019-01-07 23:45:19 +08:00
|
|
|
return llvm::make_error<llvm::StringError>(
|
|
|
|
llvm::formatv("Line value can't be negative ({0})", P.line),
|
|
|
|
llvm::errc::invalid_argument);
|
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)
|
2019-01-07 23:45:19 +08:00
|
|
|
return llvm::make_error<llvm::StringError>(
|
|
|
|
llvm::formatv("Character value can't be negative ({0})", P.character),
|
|
|
|
llvm::errc::invalid_argument);
|
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)
|
|
|
|
return llvm::make_error<llvm::StringError>(
|
|
|
|
llvm::formatv("Line value is out of range ({0})", P.line),
|
|
|
|
llvm::errc::invalid_argument);
|
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)
|
2019-01-07 23:45:19 +08:00
|
|
|
return llvm::make_error<llvm::StringError>(
|
2019-03-28 22:37:51 +08:00
|
|
|
llvm::formatv("{0} offset {1} is invalid for line {2}", lspEncoding(),
|
|
|
|
P.character, P.line),
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::errc::invalid_argument);
|
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-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;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool halfOpenRangeContains(const SourceManager &Mgr, SourceRange R,
|
|
|
|
SourceLocation L) {
|
|
|
|
assert(isValidFileRange(Mgr, R));
|
|
|
|
|
|
|
|
FileID BeginFID;
|
|
|
|
size_t BeginOffset = 0;
|
|
|
|
std::tie(BeginFID, BeginOffset) = Mgr.getDecomposedLoc(R.getBegin());
|
|
|
|
size_t EndOffset = Mgr.getFileOffset(R.getEnd());
|
|
|
|
|
|
|
|
FileID LFid;
|
|
|
|
size_t LOffset;
|
|
|
|
std::tie(LFid, LOffset) = Mgr.getDecomposedLoc(L);
|
|
|
|
return BeginFID == LFid && BeginOffset <= LOffset && LOffset < EndOffset;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool halfOpenRangeTouches(const SourceManager &Mgr, SourceRange R,
|
|
|
|
SourceLocation L) {
|
|
|
|
return L == R.getEnd() || halfOpenRangeContains(Mgr, R, L);
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::Optional<SourceRange> toHalfOpenFileRange(const SourceManager &Mgr,
|
|
|
|
const LangOptions &LangOpts,
|
|
|
|
SourceRange R) {
|
|
|
|
auto Begin = Mgr.getFileLoc(R.getBegin());
|
|
|
|
if (Begin.isInvalid())
|
|
|
|
return llvm::None;
|
|
|
|
auto End = Mgr.getFileLoc(R.getEnd());
|
|
|
|
if (End.isInvalid())
|
|
|
|
return llvm::None;
|
|
|
|
End = Lexer::getLocForEndOfToken(End, 0, Mgr, LangOpts);
|
|
|
|
|
|
|
|
SourceRange Result(Begin, End);
|
|
|
|
if (!isValidFileRange(Mgr, Result))
|
|
|
|
return llvm::None;
|
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::StringRef toSourceCode(const SourceManager &SM, SourceRange R) {
|
|
|
|
assert(isValidFileRange(SM, R));
|
|
|
|
bool Invalid = false;
|
|
|
|
auto *Buf = SM.getBuffer(SM.getFileID(R.getBegin()), &Invalid);
|
|
|
|
assert(!Invalid);
|
|
|
|
|
|
|
|
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) {
|
|
|
|
llvm::StringRef Code = SM.getBuffer(SM.getMainFileID())->getBuffer();
|
|
|
|
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())};
|
|
|
|
return {ReplacementRange, R.getReplacementText()};
|
|
|
|
}
|
|
|
|
|
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
|
|
|
|
// (getCurrentWorkingDirectory) is a symlink./ We always want to the real
|
|
|
|
// 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"
|
|
|
|
if (const DirectoryEntry *Dir = SourceMgr.getFileManager().getDirectory(
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::sys::path::parent_path(FilePath))) {
|
|
|
|
llvm::SmallString<128> RealPath;
|
|
|
|
llvm::StringRef DirName = SourceMgr.getFileManager().getCanonicalName(Dir);
|
|
|
|
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-25 23:14:03 +08:00
|
|
|
bool isRangeConsecutive(const Range &Left, const Range &Right) {
|
2018-08-13 16:23:01 +08:00
|
|
|
return Left.end.line == Right.start.line &&
|
|
|
|
Left.end.character == Right.start.character;
|
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
FileDigest digest(llvm::StringRef Content) {
|
2018-11-28 00:08:53 +08:00
|
|
|
return llvm::SHA1::hash({(const uint8_t *)Content.data(), Content.size()});
|
|
|
|
}
|
|
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
2019-01-28 22:01:55 +08:00
|
|
|
format::FormatStyle getFormatStyleForFile(llvm::StringRef File,
|
|
|
|
llvm::StringRef Content,
|
|
|
|
llvm::vfs::FileSystem *FS) {
|
|
|
|
auto Style = format::getStyle(format::DefaultFormatStyle, File,
|
|
|
|
format::DefaultFallbackStyle, Content, FS);
|
|
|
|
if (!Style) {
|
|
|
|
log("getStyle() failed for file {0}: {1}. Fallback is LLVM style.", File,
|
|
|
|
Style.takeError());
|
|
|
|
Style = format::getLLVMStyle();
|
|
|
|
}
|
|
|
|
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-04-11 17:36:36 +08:00
|
|
|
llvm::StringMap<unsigned> collectIdentifiers(llvm::StringRef Content,
|
|
|
|
const format::FormatStyle &Style) {
|
|
|
|
SourceManagerForFile FileSM("dummy.cpp", Content);
|
|
|
|
auto &SM = FileSM.get();
|
|
|
|
auto FID = SM.getMainFileID();
|
|
|
|
Lexer Lex(FID, SM.getBuffer(FID), SM, format::getFormattingLangOpts(Style));
|
|
|
|
Token Tok;
|
|
|
|
|
|
|
|
llvm::StringMap<unsigned> Identifiers;
|
|
|
|
while (!Lex.LexFromRawLexer(Tok)) {
|
|
|
|
switch (Tok.getKind()) {
|
|
|
|
case tok::identifier:
|
|
|
|
++Identifiers[Tok.getIdentifierInfo()->getName()];
|
|
|
|
break;
|
|
|
|
case tok::raw_identifier:
|
|
|
|
++Identifiers[Tok.getRawIdentifier()];
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return Identifiers;
|
|
|
|
}
|
|
|
|
|
2017-12-19 20:23:48 +08:00
|
|
|
} // namespace clangd
|
|
|
|
} // namespace clang
|