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.
...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!
...and remove the option. This is ~technically~ CLI-breaking because
Swift 5 shipped this as a hidden driver option, but it wouldn't have
/done/ anything in Swift 5, so I think it's okay to remove.
Note that if a parseable interface (.swiftinterface) and a binary
interface (.swiftmodule) are both present, the binary one will still
be preferred. This just /allows/ parseable interfaces to be used.
rdar://problem/36885834
The client usually cares about a subset of all expressions. A way to differentiate
them is by the protocols these expressions' types conform to. This patch allows
the request to add a list of protocol USRs so that the response only includes those
interested expressions that conform to any of the input protocols.
We also add a field to the response for each expression type to indicate the
conforming protocols names that were originally in the input list.
When an empty list of protocol USRs are given, we report all expressions' types
in the file like the old behavior.
rdar://35199889
"Fixes" <rdar://problem/30680565> -- the "reconstruct_type_from_mangled_name_invalid"
test has been disabled since 2017, and the output has changed a fair bit. But the
FIXMEs have been addressed and it can reconstruct the associated type and
type alias now, and there's no harm in re-enabling it now.
This is libIDE side implementation for collecting all type information in a source
file. When several expression share the same source range, we always report the
type of the outermost expression.
rdar://35199889
We were checking the parent invocation's DiagnosticEnginer rather than the
subinstance's to determine if there were any errors building the module, which
meant we would fail to load the module if there were errors prior to the import
statement in the importing file.
This also meant code completion would fail to load the module, because it always
emits a bogus error in order to mark the AST as erroneous so that different
parts of the compiler (e.g. the verifier) have less strict assumptions.
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
We were checking the parent invocation's DiagnosticEnginer rather than the
subinstance's to determine if there were any errors building the module, which
meant we would fail to load the module if there were errors prior to the import
statement in the importing file.
This also meant code completion would fail to load the module, because it always
emits a bogus error in order to mark the AST as erroneous so that different
parts of the compiler (e.g. the verifier) have less strict assumptions.
rdar://problem/43906499
There was only one remaining usage other than in testing tools.
Note that when a declaration mangling was passed in, the old entry
point would (try to) return the type of the declaration.
The new entry point no longer has this behavior. I changed the
bridging-header-first test to run lldb-moduleimport-test with
-decl-from-mangled instead of -type-from-mangled-old to preserve
the behavior of the test.
Also, I removed test/DebugInfo/DumpTypeFromMangledName.swift
completely. This test only covered a handful of cases, and a bunch
of them were declaration manglings rather than type manglings.
The new tests in test/TypeDecoder/ are much more comprehensive.
TypeContextInfo is for new SourceKit request which receives source
location, and returns context type and members which can be referenced
by "implicit member expression" syntax.
Implement that as a code completion callbacks.
Module references get indexed as a 'module' symbol; they get USRs similar to how clang would assign a USR for a module reference.
JIRA: https://bugs.swift.org/browse/SR-8677
But not even that much uglier; at all three call sites this will save
an allocation, and for the most important one (SourceKit) we can now
avoid creating a temporary CompilerInvocation just to copy into a
longer-lived one.
With this change, Driver no longer depends on Frontend, which means...
well, slightly faster builds of the compiler itself, but not much
else.
Most of this patch is just removing special cases for materializeForSet
or other fairly mechanical replacements. Unfortunately, the rest is
still a fairly big change, and not one that can be easily split apart
because of the quite reasonable reliance on metaprogramming throughout
the compiler. And, of course, there are a bunch of test updates that
have to be sync'ed with the actual change to code-generation.
This is SR-7134.
The recommended way forward is to use the SyntaxClassifier on the Swift
side.
By removing the C++ SyntaxClassifier, we can also eliminate the
-force-libsyntax-based-processing option that was used to bootstrap
incremental parsing and would generate the syntax map from a syntax
tree.
For now, the accessors have been underscored as `_read` and `_modify`.
I'll prepare an evolution proposal for this feature which should allow
us to remove the underscores or, y'know, rename them to `purple` and
`lettuce`.
`_read` accessors do not make any effort yet to avoid copying the
value being yielded. I'll work on it in follow-up patches.
Opaque accesses to properties and subscripts defined with `_modify`
accessors will use an inefficient `materializeForSet` pattern that
materializes the value to a temporary instead of accessing it in-place.
That will be fixed by migrating to `modify` over `materializeForSet`,
which is next up after the `read` optimizations.
SIL ownership verification doesn't pass yet for the test cases here
because of a general fault in SILGen where borrows can outlive their
borrowed value due to being cleaned up on the general cleanup stack
when the borrowed value is cleaned up on the formal-access stack.
Michael, Andy, and I discussed various ways to fix this, but it seems
clear to me that it's not in any way specific to coroutine accesses.
rdar://35399664
Introduce some metaprogramming of accessors and generally prepare
for storing less-structured accessor lists.
NFC except for a change to the serialization format.
instead of using name and decl context.
The advantages of this approach are three-fold:
- This is necessary to support inlined generic functions.
- We can retire the debugger-specific type name manfgling mode for archetypes.
- This saves 270kb of debug information in the x86_64 libSwiftCore.dylib alone.
<rdar://problem/38306256>
The importer in particular depends on the stdlib and the Foundation
overlay being successfully loaded, so if anything /can't/ be loaded
we have to assume that trying to walk a module's decls will result
in a crash.
rdar://problem/37540394
Tiny start-up time optimization noticed while looking at how we do
PrettyStackTraceProgram. Also add PrettyStackTraceProgram to a few
more of our testing tools, via the new PROGRAM_START macro.
Before this patch, we have one flag (KeepSyntaxInfo) to turn on two syntax
functionalities of parser: (1) collecting parsed tokens for coloring and
(2) building syntax trees. Since sourcekitd is the only consumer of either of these
functionalities, sourcekitd by default always enables such flag.
However, empirical results show (2) is both heavier and less-frequently
needed than (1). Therefore, separating the flag to two flags makes more
sense, where CollectParsedToken controls (1) and BuildSyntaxTree
controls (2).
CollectingParsedToken is always enabled by sourcekitd because
formatting and syntax-coloring need it; however BuildSyntaxTree should
be explicitly switched on by sourcekitd clients.
resolves: rdar://problem/37483076
Before conditional conformances, the archetypes in conformance
extensions (i.e. extension Foo: SomeProtocol) were equivalent to those
in the type decl, with the same protocol bounds and so on. The code for
printing "synthesized" members relied on this fact. This commit teaches
that code to deal with archetypes in the conditional conformance
extension when required.
Fixes rdar://problem/36553066 and SR-6930.
[ClangImporter] Make sure that headers from the bridging header are considered 'isBeforeInTranslationUnit' compared to headers imported from swift code
