When `-enable-lazy-typecheck` is specified, serialization may be expected to
run on an AST containing invalid declarations since type checking may happen
on-demand, during serialization, in this mode. If the declarations that are
invalid are not skipped, then the compiler is likely to crash when attempting
to serialize them. Now, invalid declarations are skipped and an error is
emitted at the end of serialization to note that serialization failed.
Additionally, a new `-Rmodule-serialization` flag can be specified to request
more detailed information about module serialization failures. This would be
useful in a situation where lazy typechecking does not produce any diagnostic
for some reason, but module serialization fails and more information is
therefore required to debug.
Resolves rdar://123260476
By default package decls are treated as resilient, similar to public (non-frozen).
This PR adds support to allow direct access to package decls at use site if opted-in.
Requires the loaded module to be a binary module in the same package.
Resolves rdar://121626315
Add a `-min-runtime-version` option that can be used to avoid problems
when building on Linux and Windows where because the runtime isn't
part of the OS, availability doesn't solve the problem of trying to
build the compiler against an older runtime.
Also add functions to IRGen to make it easy to test feature
availability using both the runtime version and the existing Darwin
availability support.
rdar://121522431
Until stdlib can be built with noncopyable generics, stdlib types
can appear as ~Escapable and ~Copyable, leading to invalid inference.
Use a flag to test implicit lifetime dependence
Instead of providing a default value for `UnavailableDeclOptimizationMode`,
track it with an optional that defaults to `None`. This way the default
behavior can vary contextually while still honoring an explicit option passed
in on the command line.
Partially resolves rdar://121344690
Obsolete the `-enable-swift3-objc-inference` option and related options by
removing support for inferring `@objc` attributes using Swift 3 rules.
Automated migration from Swift 3 has not been supported by the compiler for
many years.
Merge `$<Feature>` and `hasFeature` implementations.
- `$<Feature>` did not support upcoming language features.
- `hasFeature` did not support promoted language features and also
didn't take into account `Options` in `Features.def`.
Remove `Options` entirely, it was always one of three cases:
- `true`
- `langOpts.hasFeature`
- `hasSwiftSwiftParser`
Since `LangOptions::hasFeature` should always be used anyway, it's no
longer necessary. `hasSwiftSwiftParser` can be special cased when adding
the default promoted language features (by removing those features).
Resolves rdar://117917456.
Now that the diagnostics are automatically errors in Swift 6, we don't need an
`-enable-conformance-availability-errors` flag to control whether unavailable
conformances are diagnosed as errors. Nobody was using the flag so it should be
safe to remove.
Part of rdar://88210812
Redirecting file system can canonicalize the file path before forwarding
the path to IncludeTreeFileSystem, which is a simplied FS that can only
intepret the paths that has been seen by dep-scanner. Since all files
that need redirecting already added to underlying FS via DepScan, there
is no need for such layer when compiling using clang-include-tree.
rdar://119727344
Currently, `-direct-clang-cc1-module-build` and `-only-use-extra-clang-opts`
have to be passed together for clang importer creation to succeed.
Missing either will result in error. Simplified the swift-frontend flags
by removing `-only-use-extra-clang-opts` and let
`-direct-clang-cc1-module-build` to do both.
These search paths will not get used during Swift module compilation and can only hinder module sharing among different targets.
Resolves rdar://119217774
Generalize the existing `-playground-high-performance` flag into a set of options that control various aspects of the "playground transformation" in Sema.
This commit adds the first two of those controllable parts of the transform, matching what the existing flag already controls (scope entry/exit and function arguments), but in an extensible way. The intent is for this to be a scalable way to control a larger set of upcoming options.
So instead of a single flag, we represent the playground transform options as a set of well-defined choices, with a new `-playground-option` flag to individually enable or disable those options (when prefixed with "No", the corresponding option is instead disabled). Enabling an already-enabled option or disabling an already-disabled option is a no-op.
For compatibility, the existing `-playground-high-performance` flag causes "expensive" transforms to be disabled, as before. We can also leave it as a useful shorthand to include or exclude new options even in the future, based on their cost. There is a comment on the old function indicating that new code should use the more general form, but it remains for clients like LLDB until they can switch over.
The machinery for implementing the playground options is similar to how `Features.def` works, with a new `PlaygroundOptions.def` that defines the supported playground transform options. Each playground definition specifies the name and description, as well as whether the option is enabled by default, and whether it's also enabled in the "high performance" case.
Adding a new option in the future only requires adding it to `PlaygroundOptions.def`, deciding whether it should be on or off by default, deciding whether it should also be on or off in `-playground-high-performance` mode, and checking for its presence from the appropriate places in `PlaygroundTransform.cpp`.
Note that this is intended to control the types of user-visible results that the invoker of the compiler wants, from an externally detectable standpoint. Other flags, such as whether or not to use the extended form of the callbacks, remain as experimental features, since those deal with the mechanics and not the desired observed behavior.
rdar://109911673
Add a new flag to enable package interface loading.
Use the last value of package-name in case of dupes.
Rename PrintInterfaceContentMode as InterfaceMode.
Update diagnostics.
Test package interface loading with various scenarios.
Test duplicate package-name.
The current implementation of `-application-extension` has a problem that affects the generation of ObjC headers for regular Swift modules.
The primary purpose of `-application-extension` is to prevent the use of unavailable APIs in app extensions. However, it has an impact on the generation of -Swift.h headers and exposes Swift's internal declarations to ObjC. This behavior is appropriate for mixed modules that are not consumed externally, such as app extensions, but it fails to address the situation when a module is not an extension itself but is consumed by the extension (c90cd11).
To resolve this issue while maintaining the desired behavior, we can introduce a new flag for this particular use-case.
With the growing popularity of using Features, I think it's important to
ensure our Features querying set is as fast as possible. In particular,
we sometimes may end up putting a feature check in a hot function, so
the `contains` overhead is important.
While I haven't done *any* measurements to verify this, I think a
`llvm::SmallSet<Feature, 2>` is slower than a FixedBitSet. For the
former, if the set grows more than the constant size, it switches over
to using a `std::set`. Setting the size to `numFeatures()` is not
particularly attractive or possible, because `SmallSet` is limited to a
size of 32 to be considered small, as it uses linear search over a
SmallVector to service a `contains` query.
Meanwhile, a FixedBitSet has a small constant factor overhead for
querying if the element is contained: two divisions by a
constant power-of-two, a bit shift, and a memory-read / compare. I think
that'll beat a SmallSet in all cases.
Conflicts:
- `lib/AST/TypeCheckRequests.cpp` renamed `isMoveOnly` which requires
a static_cast on rebranch because `Optional` is now a `std::optional`.
By default the compiler will now replace the bodies of unavailable functions
with stubs that call `_diagnoseUnavailableCodeReached()` instead.
Resolves rdar://116019744
Using `-Rmodule-api-import` the compiler prints a remark about the
import bringing in every decl used in public function signatures or
inlinable code. It also remarks on the source of conformances where they
are used and the source of typealias underlying types.
An existing test (Frontend/skip-function-bodies.swift) was designed under the
assumption that multiple `-debug-forbid-typecheck-prefix` arguments were
already supported, and as a result the test was not actually asserting what it
was written to assert.
Macro implementations can come from various locations associated with
different search paths. Add a frontend flag `-Rmacro-loading` to emit
a remark when each macro implementation module is resolved, providing
the kind of macro (shared library, executable, shared library loaded
via the plugin server) and appropriate paths. This allows one to tell
from the build load which macros are used.
Addresses rdar://110780311.
