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!
This patch allows SourceKit to generate the interface for a given type specified by its mangled name.
Type interface is refined decl printing with type parameters localized and unusable members hidden.
Required field:
"key.request": "source.request.editor.open.interface.swifttype"
"key.usr": the mangled name of the given type.
Cursor info requires access to the underlying AST, which is not
thread-safe. This manifest as crashes when performing concurrent
cursor-info requests on the same generated interface. We already
prevented concurrent cursor-infos on regular Swift files by using the
ASTManager, but generated interfaces use the InterfaceGenContext which
may use either an ASTUnit or its own internal CompilerInstance.
rdar://problem/27311624
This enables testing asyncronous requests on platforms that support it
(currently you need blocks support to call sourcekitd_send_request).
The implementation performs all -async requests and then at the end
handles all the responses in the order they were performed (possibly
blocking until they complete).
Also add a -dont-print-request flag to avoid printing request objects;
printing is fairly slow and makes it much harder to hit timing-sensitive
races, etc.
Typically, users jump to type-specific interface from a member of that type, for
instance, a.getSomething(). To generate the interface, we need to report the USR
of the container type of "getSomething()", which is the USR for the type of a,
when cursor info is requested for this function call.
The mangled name of the type is identical to those for debugger. These
mangled names allow us to reconstruct the type from AST and generate interface
specifically for that type.
Related rdar://27306890
SourceKit invariantly expands the last argument in a function call as trailing closure,
if it is of function type. However, there are situations when inline closures
are preferred; for example, when the last argument is not the only closure in the function
call. This patch modifies SourceKit so that when the argument contains multiple closures,
the last argument is expanded as inline closure.
Showing only the conforming associated types provides
little information to doc viewers. This patch digs the
underlying type of an associated type to report the
conformance info of those.
This adds a narrow special case in code-completion for control-flow-like
methods such as DispatchQueue().sync that are () -> (), to add a new
completion where the trailing closure is immediately expanded rather
than having to invoke placeholder expansion as a second step.
rdar://problem/26628804
Setting this value is equivalent to setting:
include_directories(${CMAKE_CURRENT_BINARY_DIR} ${CMAKE_CURRENT_SOURCE_DIR})
in all subdirectories. Since these are all macros, this means that we are adding to the configuration
path the root swift directory. There is no reason to do this and will result in
confusion/bugs in the future.
rdar://26154980
This eliminates us setting an LLVM_ prefixed variable in a situation where there is
a viable alternative.
We want to eliminate as many of these as possible since they can cause conflicts
with variables set in LLVMConfig.cmake.
I also added some convenience tablegen functions in AddSwiftTableGen.cmake and
changed all tblgen users to use that instead.
rdar://26154980
Darwin can use the XPC implementation of this even for the in-proc library
build, this alternative implementation is need for Linux where XPC services
are not available.
This implementation is derived from the existing XPC one but replaces XPC
services' object model with a basic class hierarchy providing
reference-counted objects for the value types and collections that
compose the sourcekitd API's request and response types.
`_WIN32` indicates if we are targeting Windows or not. Directly use that macro
rather than `LLVM_ON_WIN32` used by LLVM. This makes it easier to port the
code.
The index may be at the end of the ArrayRef of chunks if the completion
ends with a simple parameter with no type annotation. Check that the
index is in-bounds before adding text.
rdar://problem/26273906
Surface these results in the codecomplete code path (they're already
there in the codecomplete.open code path) so we can use them from IDEs.
For now, just use ad-hoc filtering to show them when the type matches
(or there is no expected type). Ideally we would make this filtering
configurable like we do in the codecomplete.open code path.
rdar://problem/25836544
