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
If enabled using the environment variable
SOURCEKIT_INCREMENTAL_PARSE_VALIDATION, the incrementally parsed syntax
tree will be compared to the from-scratch parsing syntax tree. If they
differ a warning is emitted and log files showing the difference written
to a temporary directory.
Since compiler arguments are processed by Driver, arbitrary filename
passed as 'request.name' (e.g. "", "-1", etc.) may cause problems.
Using '-' guarantees successful initialization of 'CompilerInvocation'.
rdar://problem/40646921
rdar://problem/40955808
With more options coming for incremental syntax parsing, the list of
arguments will grow way to large and unhandy, so just extract them into
one common struct.
Disable the sanitizers and code coverage when building a swift
invocation for the purpose of collecting diagnostics.
This should speed up diagnostic generation and reduce exposure to
compiler bugs.
rdar://40955900
When adding to the AST consumer queue, keep track of the snapshots
expected and only run such AST consumers when a new enough AST is built.
Progress is ensured because we always run the AST consumer that
triggered the build.
This prevents cases where enqueuing a consumer during an AST build has
different behaviour than enqueuing it after the AST has finished.
rdar://40340631
Introduce some metaprogramming of accessors and generally prepare
for storing less-structured accessor lists.
NFC except for a change to the serialization format.
Validation of the input side of FunctionTypeRepr was previously being done in Sema because of expression folding. If we instead push the invariant that the input TypeRepr should always be a TupleTypeRepr into the AST a number of nice cleanups fall out:
- The SIL Parser no longer accepts Swift 2-style type declarations
- Parse is more cleanly able to reject invalid FunctionTypeReprs
- Clients of the AST can be assured the input type is always a TupleType so we can flush Swift 2 hacks
Calling '@objc optional func' requires '?' or '!' after its name. When
completing method calls for them, 'key.sourcetext' should have '?'
whereas 'key.name' shouldn't.
Note that we deliberately do not use optional type name for
'key.typename'. This is consistent with optional chain '?.<propertyName>'
behavior.
rdar://problem/37904574
Refactors the diagnostic code to be run whenever a compilation
notification has been started and there are diagnostics available in the
consumer. This allows us to capture diagnostics on all exit paths, and
specifically when code-completion fails because of invalid arguments.
Note: the editor.open code path still doesn't report invalid arguments
because it fails before even trying to create an AST.
... instead of overriding it after the driver is done. This improves
the fidelity of anything that looks at the resource directory inside the
driver or frontend argument parsing. In particular, it fixes an issue
where sourcekit requests would fail if they included the -sanitize=
option because the driver would fail to find the runtime libraries.
Even though this should be *more correct* for all uses, in the
interests of understanding all possible immediate effects of this
change, I manually audited all the code that looks at the resource
directory in between when it is parsed as and argument and when
createCompilerInvocation returns. I claim that the only changes are:
1. The sanitizer library check that we wanted to change
2. The DWARFDebugFlags, which are for IRGen so don't affect SourceKit
3. The Migrator data paths, which also don't affect SourceKit
For now, I put the -resource-dir option at the end of the arguments so
that it overrides any existing option, which mimics how it behaved
before. We might want to move it to the beginning so that we honour a
user-provided resource directory, but that should be a separate change.
rdar://40147839
