This patch changes the syntax map data structure it uses to be offset based
rather than line/col based in order to avoid calling getLineAndColumn for the
start and end offset of every token. This removes the 30% of time spent in
getLineAndColumn for this request in large files (rdar://problem/28965123).
The logic for returning the affected range and the token ranges to highlight
following an edit also made several assumptions that no longer hold. This
patch changes it to compare the syntax maps from before and after the edit,
find the first mismtaching tokens from the start and end of the syntax maps
and return the tokens in that range (adjusted to line boundaries). This fixes
syntax highlighting issues with interpolated multi-line strings
(rdar://problem/32148117) and block comments.
With the above changes the per-keystroke time spent for syntax highlighting
(with sematic info disabled) dropped from ~80ms to just under 50ms for a
12KLOC file.
We saw this test crash once, but the stack trace was eaten by FileCheck
because we are consuming stderr. Now if the test fails it should dump
the full output, which should include the stack trace.
Use this to remove the last bit of the hack to suppres noescape on setter
arguments. Add a more comprehensive test of noescape's interaction with
accessors.
As we do with "where" clauses, print the "inheritance" clauses of
protocols and associated type declarations using the requirement
signature of the protocol rather than the "inherited" list.
This patch allows Parser to generate a refined token stream to satisfy tooling's need. For syntax coloring, token stream from lexer is insufficient because (1) we have contextual keywords like get and set; (2) we may allow keywords to be used as argument labels and names; and (3) we need to split tokens like "==<". In this patch, these refinements are directly fulfilled through parsing without additional heuristics. The refined token vector is optionally saved in SourceFile instance.
With broken code you can end up with non-postfix completions when
searching for inner operators, which you never want because you end up
creating compound results like "fooUIColor".
rdar://problem/34145229
I noticed in a follow-up patch that if you just swiftc without passing Onone
these flags are not set and sometimes happen to default to right thing ... or
not; as can be seen by the test cases modified. For example, at Onone we are
supposed to include an extra swift module "SwiftOnoneSupport".
When completing in an if/while/guard statement condition that expects a
boolean, add the code-completion type relation for Bool. We already had
this for repeat-while.
rdar://problem/26509084
...which didn't do the right thing in the presence of ModuleMacro,
depending on the order the macros were referenced. Already covered by
test/ClangImporter/macros.swift, but it actually seems to improve the
behavior of some of the SourceKit tests as well.
Continuing rdar://problem/32199805, which is just "get macros working
with clang::ModuleMacro".
For normal completions it behaves the same as PostfixExprBeginning, but
it provides a hook for clients to provide a custom completion for this
position. For example, you might want to a x ..< y snippet in this
position.
rdar://problem/29910383
When using completion options that will allow the lone "." completion,
provide that result when in contexts that expect an enum type. Note:
this is a crappy approximationg for whether the type can have "implicit
member expression" syntax, since uninhabited enums should not support
it, and many non-enum types should. However, it is currently expensive
to compute the accurate answer and this approximation is good enough for
some clients.
rdar://problem/31260505
I failed to merge the upstream changes to swift-corelibs-foundation at the same
time as I merged that #9806, and it broke on linux. Going to get it right this
time.
