Pass '-fbuild-session-timestamp' and '-fmodules-validate-once-per-build-sessio'
to ClangImporter so that module validation happens only once for the
SourceKit lifetime.
rdar://problem/59567281
Replace it with the "legacy semantic queries" bit. The remaining client
of this bit is SourceKit, which appears to require this bit be set
conditionally so certain semantic property wrapper requests return
a sentinel value.
We should migrate these requests to a syntactic interface as soon as
possible.
rdar://60516325
Remove the `EvaluateConditionals` flags from the
parser, and instead query the source file.
This commit also changes ParserUnit such that it
doesn't evaluate #if conditions by default, as
none of its clients appear to require it. The
only client that wasn't explicitly disabling #if
evaluation and is processing the resulting AST is
swift-indent, so this commit also adds a test to
ensure it continues to work correctly with #if
decls.
Move the global PersistentParserState from
the CompilerInstance to the source file that code
completion is operating on, only hooking up the
state when it's needed. This will help make it
easier to requestify source file parsing.
[ASTPrinter] When printing a property wrapper attribute name for the fully annotated declaration, make sure that it is wrapped within the `syntaxtype.attribute.name` tag
This reverts commit beb8ecd8cc. Add a
workaround for the dependency issue.
It is unclear why `sourcekitd` is getting added improperly as a
dependency on `lib/sourcekitd.framework/sourcekitd`. This workaround
adjusts the dependency such that we end up with a dependency on
`lib/sourcekitd.framework/Versions/A/sourcekitd` as an order-only
dependency. This should fix the compile issue. I am unable to
reproduce this issue with the `add_library` usage for adding a Swift
library. This allows us to cleave the host and target libraries, and so
the workaround is sufficient to make progress and the problem will be
resolved with the migration towards CMake for handling the dependencies.
When a “separately imported overlay” is added to a SourceFile, two things happen:
1. The direct import of the underlying module is removed from getImports*() by default. It is only visible if the caller passes ImportFilterKind:: ShadowedBySeparateOverlay. This means that non-module-scoped lookups will search _OverlayModule before searching its re-export UnderlyingModule, allowing it to shadow underlying declarations.
2. When you ask for lookupInModule() to look in the underlying module in that source file, it looks in the overlays instead. This means that UnderlyingModule.foo() can find declarations in _OverlayModule.
This moves the swift-lang library out of the tools/SourceKit directory
and into the stdlib directory. As it stands, the library required that
the standard library and the SDK overlay was being built. This is
implicitly done when building the stdlib subdirectory. Furthermore, it
had an odd tie between the flags for Swift and SourceKit which now have
the logic separated. This clearly delineates the host and target
components in the repository.
We used to compute the mangled name in other cases, but document structure is
a syntactic request and can't guarantee that the class/protocol we're getting
the mangled name of is valid in any way so it often breaks assumptions in the
mangler and causes it to crash. It's not clear if the runtime_name is actually
being used anymore, so this change restricts reporting it to just the cases
where we don't need to mangle.
rdar://problem/40956377
Now
* NotApplicable: The result is not relevant for type relation (e.g.
keywords, and overloads)
* Unknown: the relation was not calculated (e.g. cached results), or the
context type is unknown.
* Invalid: The result type is invalid for this context (i.e. 'Void' for
non-'Void' context)
* Unrelated: The result type has no relation to the context type
* Convertible: The result type is convertible to the context type
* Identical: The result type is identical to the context type
