Manually specifying range length is laborious and error-prone; this
commit adds an argument -end-pos=Line:Column to specify the end
position of a given range under test.
Like cursor-info, range info (""source.request.cursorinfo"") answers some
questions clients have for a code snippet under selection, for instance, the type of a selected
expression. This commit implements this new quest kind and provides two
simple information about the selected code: (1) the kind of the
snippet, currently limited to single-statement and expression; and (2)
the type of the selected expression. Gradually, we will enrich the
response to provide more insight into the selected code snippet.
Sorry -- I meant to include this with the previous commit. LLVM is
moving away from llvm::sys:TimeValue in favor of std::chrono. For consistency
with LLVM, I used the new llvm::sys::TimePoint type in most places.
There are a few places, like the SourceKit files modified here, where it
makes more sense to use std::chrono directly.
LLVM SVN r284681 replaced `LLVM_FUNCTION_NAME` with `__func__` as all supported
compilers support that keyword now. The holdout was MSVC, and swift requires
clang, so this is always supported. NFC.
Previously, document structure responses were created using XPC
dictionaries, but this forced deserialization of the large nested
dictionaries no matter what the access pattern was. The new format uses
our custom buffer machinery, and only deserializes dictionaries that are
actually needed.
The performance improvement is around 25% for an editor.open, and 35-40%
for an editor.replacetext request in the large files I've tested. The
performance improvements are in serialization (inside the service),
deserialization (client), and disposal of the response object (client).
rdar://problem/28789756
Reset Darwin specific CMake variables to match the correct
SDK and architecture. This is needed when cross compiling, or we'll end up with
conflicting SDK and architectures.
Remove unused variable SOURCEKIT_GLOBAL_DEPLOYMENT_TARGET_FLAGS.
llvm r283043 and possibly other recent changes switch to use StringRef
instead of char* pointers. Update Swift to match. In some cases, this is
a clear improvement. It would be good to assess the impact on memory use,
particularly for the Filename component of source locations.
Note that the change to SILLocation::isNull fixes an apparent bug where
the location was treated as null when the filename was *not* null.
There was a ton of complicated logic here to work around
two problems:
- Same-type constraints were not represented properly in
RequirementReprs, requiring us to store them in strong form
and parse them out when printing type interfaces.
- The TypeBase::getAllGenericArgs() method did not do the
right thing for members of protocols and protocol extensions,
and so instead of simple calls to Type::subst(), we had
an elaborate 'ArchetypeTransformer' abstraction repeated
in two places.
Rewrite this code to use GenericSignatures and
GenericFunctionType instead of old-school GenericParamLists
and PolymorphicFunctionType.
This changes the code completion and AST printer output
slightly. A few of the changes are actually fixes for cases
where the old code didn't handle substitutions properly.
A few others are subjective, for example a generic parameter
list of the form <T : Proto> now prints as <T where T : Proto>.
We can add heuristics to make the output whatever we want
here; the important thing is that now we're using modern
abstractions.
Now that I am going to be adding an IN_SWIFT_COMPONENT argument, I need to do
this to distinguish the concepts of an LLVM_COMPONENT and a SWIFT_COMPONENT.
One minor revision: this lifts the proposed restriction against
overriding a non-open method with an open one. On reflection,
that was inconsistent with the existing rule permitting non-public
methods to be overridden with public ones. The restriction on
subclassing a non-open class with an open class remains, and is
in fact consistent with the existing access rule.
Currently if you type in a malformed `pos` argument it responds with:
wrong pos format, it should be '<line>:<column'
After the change it responds with:
wrong pos format, it should be '<line>:<column>'
- Make the Demangle header match the other headers in the doc (e.g.,
double hash)
- Add a table of contents that is sorted alphabetically by request key
with a link to the header in the document
What I've implemented here deviates from the current proposal text
in the following ways:
- I had to introduce a FunctionArrowPrecedence to capture the parsing
of -> in expression contexts.
- I found it convenient to continue to model the assignment property
explicitly.
- The comparison and casting operators have historically been
non-associative; I have chosen to preserve that, since I don't
think this proposal intended to change it.
- This uses the precedence group names and higherThan/lowerThan
as agreed in discussion.
'fileprivate' is considered a broader level of access than 'private',
but for now both of them are still available to the entire file. This
is intended as a migration aid.
One interesting fallout of the "access scope" model described in
758cf64 is that something declared 'private' at file scope is actually
treated as 'fileprivate' for diagnostic purposes. This is something
we can fix later, once the full model is in place. (It's not really
/wrong/ in that they have identical behavior, but diagnostics still
shouldn't refer to a type explicitly declared 'private' as
'fileprivate'.)
As a note, ValueDecl::getEffectiveAccess will always return 'FilePrivate'
rather than 'Private'; for purposes of optimization and code generation,
we should never try to distinguish these two cases.
This should have essentially no effect on code that's /not/ using
'fileprivate' other than altered diagnostics.
Progress on SE-0025 ('fileprivate' and 'private')
C++ atomic's fetch_sub returns the previous value, where we want to
check the new value. This was causing massive memory leaks in SourceKit.
For ThreadSafeRefCountedBase, just switch to the one in LLVM that's
already correct. We should move the VPTR one to LLVM as well and then
we can get rid of this header.
rdar://problem/27358273
The high weight on semantic context turns out to give a lot of
unreasonable completions on common types. For example
[0].ma<here>
was suggesting withUnsafeMutable... over map.
rdar://problem/27393776
The ArchetypeTransformer isn't actually limited to transforming archetypes
but can transform arbitrary types. Thus, we can rename it to TypeTransformer
In sourcekitdInProc, we were doing a by-ref capture of a block that
didn't live as long as the asyncronous callback. Fix it by capturing
by-copy.
Found by ASan!
