Previously, requests would fail silently by returning an empty struct
in the response.
With this change, responses will properly report fail with the internal
error.
When sanitizing the documentation comments for synthesized extensions,
we expect some text like "<declaration>extension". This isn't the case
when use-facing attributes are present.
rdar://50913510
This lets us make some more assumptions in the next commit, but I
think it's also just a nice cleanup to /not/ allow random predicates
here.
There were three callers of this API:
- PrintAST, which was using PrintOptions::shouldPrint but /also/
incorrectly notifying listeners that a declaration would be skipped.
- (IDE) Interface generation, which uses PrintOptions::shouldPrint to
count how many "inherits" there will be.
- SwiftDocSupport's reportRelated, which does no filtering at all.
Creating a PrintOptions here is a little more expensive, but still.
No intended functionality change.
The llvm::ArrayRef constructor should be passed the actual length of the
resulting string, not MAX_PATH, else the StringRef that results has an
incorrect length of MAX_PATH.
Previously, requests would fail silently by returning an empty struct
in the response.
With this change, responses will properly report fail with the internal
error.
In addition to brace statements (previously handled), several other
statements allow a trailing closure (return, yield, throw). Also fix the
handling of statements nested within expressions for closures - both
single-expression bodies and brace statements.
This also fixes a particular regression caused by single-expression
function bodies where we would fail to expand to a trailing closure when
a function body only contained a single expression.
rdar://50227500
CMake supports the notion of installation components. Right now we have some
custom code for supporting swift components. I think that for installation
purposes, it would be nice to use the CMake component system.
This should be a non-functional change. We should still only be generating
install rules for targets and files in components we want to install, and we
still use the install ninja target to install everything.
Previously, requests would fail silently by returning an empty struct
in the response.
With this change, responses will properly report fail with the internal
error.
Ensure the various entity walkers handle the implicit subscript
reference correctly (usually by ignoring it) and fall through to the
underlying declarations.
rdar://49028895
When building the implicit subscript expression, set the "implicit" bit
correctly and pass it through in the indexer so that we get implicit
refernces to the subscript. This would be useful for e.g. searching for
all uses of the dynamic subscript.
add_sourcekit_default_compiler_flags was invoking
_add_variant_link_flags and getting link flags but not actually using
the link_libraries or library_search_directories. In android builds,
this means that the correct libc++ is not being linked against.
When we build incrementally, we produce "partial swiftmodules" for
each input source file, then merge them together into the final
compiled module that, among other things, gets used for debugging.
Without this, we'd drop @_implementationOnly imports and any types
from the modules that were imported during the module-merging step
and then be unable to debug those types
This is an attribute that gets put on an import in library FooKit to
keep it from being a requirement to import FooKit. It's not checked at
all, meaning that in this form it is up to the author of FooKit to
make sure nothing in its API or ABI depends on the implementation-only
dependency. There's also no debugging support here (debugging FooKit
/should/ import the implementation-only dependency if it's present).
The goal is to get to a point where it /can/ be checked, i.e. FooKit
developers are prevented from writing code that would rely on FooKit's
implementation-only dependency being present when compiling clients of
FooKit. But right now it's not.
rdar://problem/48985979
...in preparation for me adding a third kind of import, making the
existing "All" kind a problem. NFC, except that I did rewrite the
ClangModuleUnit implementation of getImportedModules to be simpler!
This is needed as SwiftSyntaxParser also needs to be built with clang as
it uses blocks unconditionally. However, building with cl provides much
better diagnostics and debugging as well as a significantly faster
build (~15-20% faster) as well as a faster compiler.
Extend the support for single-expression closures to handle
single-expression functions of all kinds. This allows, e.g.
func foo() -> MyEnum { .<here> }
to complete members of `MyEnum`.
SourceKit uses libdispatch for concurrency. Unfortunately, libdispatch
requires clang due to extensions. Switch to `clang-cl` or `clang` as
appropriate when building with a non-clang based host compiler.
In particular, the dependency on blocks (and certain attributes) makes
porting libdispatch to cl infeasible.
