Add flag `-load-resolved-plugin` to load macro plugin, which provides a
pre-resolved entry into PluginLoader so the plugins can be loaded based
on module name without searching the file system. The option is mainly
intended to be used by explicitly module build and the flag is supplied
by dependency scanner.
Today ParenType is used:
1. As the type of ParenExpr
2. As the payload type of an unlabeled single
associated value enum case (and the type of
ParenPattern).
3. As the type for an `(X)` TypeRepr
For 1, this leads to some odd behavior, e.g the
type of `(5.0 * 5).squareRoot()` is `(Double)`. For
2, we should be checking the arity of the enum case
constructor parameters and the presence of
ParenPattern respectively. Eventually we ought to
consider replacing Paren/TuplePattern with a
PatternList node, similar to ArgumentList.
3 is one case where it could be argued that there's
some utility in preserving the sugar of the type
that the user wrote. However it's really not clear
to me that this is particularly desirable since a
bunch of diagnostic logic is already stripping
ParenTypes. In cases where we care about how the
type was written in source, we really ought to be
consulting the TypeRepr.
This change refactors the top-level dependency scanning flow to follow the following procedure:
Scan():
1. From the source target under scan, query all imported module identifiers for a *Swift* module. Leave unresolved identifiers unresolved. Proceed transitively to build a *Swift* module dependency graph.
2. Take every unresolved import identifier in the graph from (1) and, assuming that it must be a Clang module, dispatch all of them to be queried in-parallel by the scanner's worker pool.
3. Resolve bridging header Clang module dpendencies
4. Resolve all Swift overlay dependencies, relying on all Clang modules collected in (2) and (3)
5. For the source target under scan, use all of the above discovered module dependencies to resolve all cross-import overlay dependencies
Occasionally, when the Swift compiler emits a diagnostic for a construct
that was imported from C++ we get a diagnostic with unknown location.
This is a bad user experience. It is particularly bad with the
borrow-checker related diagnostics. This patch extends the source
location importing to declarations in ClangImporter. There are some
invariants enforced by the Swift compile, e.g., a source range is
comprised of two valid source locations or two invalid ones. As a
result, this patch adds approximate source locations to some separators
like braces or parens that are not maintained by Clang. Having slightly
incorrect ranges in this case is better than emitting unknown source
locations.
If the feature is enabled, base the requirement for the underscored
accessors on the availability of the non-underscored accessors. If the
(non-underscored) accessor's was available earlier than the feature,
interpret that to mean that the underscored version was available in
that earlier version, and require the underscored version. The goal is
to ensure that the ABI is preserved, so long as the simplest migration
is done (namely, deleting the underscores from the old accessors).
For modify2, cache the required-ness in the same way that it is cached
for modify.
Whether read2/modify2 are required will not always be identical to
whether read/modify are required. Add separate prediates for the
former. For now, duplicate the latter's implementation.
In #58965, lookup for custom derivatives in non-primary source files was
introduced. It required triggering delayed members parsing of nominal types in
a file if the file was compiled with differential programming enabled.
This patch introduces `CustomDerivativesRequest` to address the issue.
We only parse delayed members if tokens `@` and `derivative` appear
together inside skipped nominal type body (similar to how member operators
are handled).
Resolves#60102
Add the necessary compiler-side logic to allow
the regex parsing library to hand back a set of
features for a regex literal, which can then be
diagnosed by ExprAvailabilityWalker if the
availability context isn't sufficient. No tests
as this only adds the necessary infrastructure,
we don't yet hand back the features from the regex
parsing library.
Currently, we do not support exporting zero-sized value types from Swift
to C++. It needs some work on our end as these types are not part of the
lowered signature. In the meantime, this PR makes sure that common (but
not all) zero sized types are properly marked as unavailable. This is
important as the proper diagnostic will give users a hint how to work
around this problem. Moreover, it is really easy to hit this when
someone is experimenting with interop, so it is important to not have a
cryptic failure mode.
rdar://138122545
`Builtin.FixedArray<let N: Int, T: ~Copyable & ~Escapable>` has the layout of `N` elements of type `T` laid out
sequentially in memory (with the tail padding of every element occupied by the array). This provides a primitive
on which the standard library `Vector` type can be built.
Implement a query that returns the `AvailabilityContext` for a given
`SourceLoc` and `DeclContext`. Re-implement the existing type checker query
that just returns an `AvailabilityRange` on top of the new query.
Make the pointer to uniqued storage an implementation detail of an
`AvailabilityContext` value. This way clients of `AvailabilityContext` don't
need to think about pointers and can have access to mutating operations on a
context when appropriate.
On Windows, we run into the following situation when running SourceKit-LSP tests:
- The SDK is located at `S:\Program Files\Swift\Platforms\Windows.platform\Developer\SDKs\Windows.sdk` with `S:` being a substitution drive
- We find `Swift.swiftmodule` at `S:\Program Files\Swift\Platforms\Windows.platform\Developer\SDKs\Windows.sdk\usr\lib\swift\windows\Swift.swiftmodule`
- Now, to check if `Swift.swiftmodule` is a system module, we take the realpath of the SDK, which resolves the substitution drive an results in something like `C:\Users\alex\src\Program Files\Swift\Platforms\Windows.platform\Developer\SDKs\Windows.sdk`
- Since we don’t take the realpath of `Swift.swiftmodule`, we will assume that it’s not in the SDK, because the SDK’s path is on `C:` while `Swift.swiftmodule` lives on `S:`
To fix this, we also need to check if a module’s real path is inside the SDK.
Fixesswiftlang/sourcekit-lsp#1770
rdar://138210224
