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
This library is already supplied by the LLVM CMake config, so adding it here
sometimes causes the CommandLine option parser to fail, as it registers the
same option twice.
This should repair the Windows build after #29451. The quoting
behaviour was incorrect and was constructing an invalid compiler
invocation. Solve the issue by using `target_include_directories`
instead. However, since this needs the target, hoist the flag
computation to the local sites. This replicates more logic because of
the custom build trying to replicate the CMake build logic in CMake.
Use specific operations for setting the compile flags, link flags,
linked libraries, and library search paths. This allows us to use CMake
more effectively, simplifies the logic, and will ensure that flags are
not duplicated.
When doing header interface generation, we interpret clang command-line
arguments in `initInvocationByClangArguments` and attempt to setup a
matching Swift compiler invocation. One important argument is the module
cache, but clang will only interpret `-fmodules-cache-path` if modules
are enabled (typically with `-fmodules`). While the header itself might
not need modules, Swift will import its own shims module and during
testing this needs to honour lit's provided cache. So we add -fmodules
in sourcekitd-test anytime we add -fmodules-cache-path.
rdar://58836540
