Members of an @objcMembers context previous had implicit @objc attributes, but
now don't (possibly because of the request evaluator changes?). This updates the
output of sourcekitd's 'index' request to act as if they still had implicit
@objc attributes on them for compatibility.
Resolves rdar://problem/48140265
This request collects the types of all expressions in a source file after type checking.
To fulfill this task, the client must provide the path to the Swift source file under
type checking and the necessary compiler arguments to help resolve all dependencies.
Request:
{
<key.request>: (UID) <source.request.expression.type>,
<key.sourcefile>: (string) // Absolute path to the file.
<key.compilerargs>: [string*] // Array of zero or more strings for the compiler arguments,
// e.g ["-sdk", "/path/to/sdk"]. If key.sourcefile is provided,
// these must include the path to that file.
}
Response:
{
<key.printedtypebuffer>: (string) // A text buffer where all expression types are printed to.
<key.expression_type_list>: (array) [expr-type-info*] // A list of expression and type
}
expr-type-info ::=
{
<key.expression_offset>: (int64) // Offset of an expression in the source file
<key.expression_length>: (int64) // Length of an expression in the source file
<key.type_offset>: (int64) // Offset of the printed type of the expression in the printed type buffer
<key.type_length>: (int64) // Length of the printed type of the expression in the printed type buffer
}
rdar:://35199889
In addition to capturing more detailed preprocessor info, the
DetailedPreprocessorRecord option sets the clang module format to 'raw'
rather than the default 'object'. Sourcekitd doesn't link the code
generation libs, which it looks like the default 'object' format requires,
so it sets this option to true. The subinvocation generated when loading a
module from a .swiftinterface file still used the default prior to this
change though, so it would end up crashing sourcekitd.
This change sets the DetailedProccessorRecord option if the DetailedRecord
option is set on the preprocessor options of parent context's clang module
loader. This fixes interface generation crashing for modules that only have
a .swiftinterface file.
rdar://problem/43906499
`source.request.conformingmethods` is a new SourceKit request which
receives a source position and a list of protocol namses, returns a list
of methods whose return type conforms to the requested protocols.
rdar://problem/44699573
SourceKit document structure request used to crash if if there's inititalizer
with single named parameter with `@IBAction` attribute.
This used to happen because
ConstructorDecl::isObjCZeroParameterWithLongSelector() requires
interface type of the parameter but the constructor doesn't have it at
this stage.
This change fixes that by not vending ObjC name for
constructor or destructors.
rdar://problem/47426948
This is a new SourceKit request which receives a position in the source
file, returns possible expected types and their members which can be
referenced by "implicit member expression" syntax.
Instead of creating syntax nodes directly, modify the parser to invoke an abstract interface 'SyntaxParseActions' while it is parsing the source code.
This decouples the act of parsing from the act of forming a syntax tree representation.
'SyntaxTreeCreator' is an implementation of SyntaxParseActions that handles the logic of creating a syntax tree.
To enforce the layering separation of parsing and syntax tree creation, a static library swiftSyntaxParse is introduced to compose the two.
This decoupling is important for introducing a syntax parser library for SwiftSyntax to directly access parsing.
Redesigns the `SwiftLang.parse` API to accommodate a format parameter which can be used to request a ByteTree-serialized syntax tree instead of JSON-serialized. This gives us a convenient way to use the fastest currently available combination of tools for parsing a file into a syntax tree.
The new API only accepts paths, not source buffers, and returns JSON as `Data` instead of `String`, which are both better directions in the long run. The format type is extensible so that it can easily be extended to support "direct" parsing into a SyntaxSourceFile.
Deprecated wrapper methods with the old names and signatures are still available for any existing clients.
With this change, you will no longer receive
"error when parsing the compiler arguments". Instead, you will
receive the underlying error, like
"error: unable to load output file map 'output_file_map.json': No such file or directory"
`-fblocks` is a core driver option now, so it can be used with both the GCC
style driver as well as the cl style driver. Simplify the logic for the
handling of this option.
When debugging Objective-C or C++ code on Darwin, the debug info
collected by dsymutil in the .dSYM bundle is entirely
self-contained. It is possible to debug a program, set breakpoints and
print variables even without having the complete original source code
or a matching SDK available. With Swift, this is currently not the
case. Even though .dSYM bundles contain the binary .swiftmodule for
all Swift modules, any Clang modules that the Swift modules depend on,
still need to be imported from source to even get basic LLDB
functionality to work. If ClangImporter fails to import a Clang
module, effectively the entire Swift module depending on it gets
poisoned.
This patch is addressing this issue by introducing a ModuleLoader that
can ask queries about Clang Decls to LLDB, since LLDB knows how to
reconstruct Clang decls from DWARF and clang -gmodules producxes full
debug info for Clang modules that is embedded into the .dSYM budle.
This initial version does not contain any advanced functionality at
all, it merely produces an empty ModuleDecl. Intertestingly, even this
is a considerable improvement over the status quo. LLDB can now print
Swift-only variables in modules with failing Clang depenecies, and
becuase of fallback mechanisms that were implemented earlier, it can
even display the contents of pure Objective-C objects that are
imported into Swift. C structs obviously don't work yet.
rdar://problem/36032653
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
