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.
Also rename it to `getExplicitReturnStmts` for clarity and have it
take a `SmallVector` out parameter instead as a small optimization and
to discourage use of this new method as an alternative to
`AnyFunctionRef::bodyHasExplicitReturnStmt`.
Lifetime dependencies will now be represented with @lifetime attribute in the language.
dependsOn is a type modifier and was represented as a LifetimeDependentTypeRepr in the AST.
I am deleting dependsOn syntax parsing support and retaining LifetimeDependentTypeRepr support.
We may want to represent lifetime dependencies in a function type with a type attribute in the future.
If we use a decl attribute instead, then support for LifetimeDependentTypeRepr can be deleted.
With the upcoming `MemberImportVisibility` feature enabled, code built with Cxx
interop also enabled could be rejected by the compiler with cryptic errors
about the `__ObjC` module not being imported. This is the result of a
surprising implementation detail of Cxx interop. When importing C++ namespaces
and their members, the Clang importer puts these declarations in the Clang
header import module (a.k.a. the bridging header module, `__ObjC`). C++
namespaces don't have a logical modular home in the Swift AST because they can
span multiple modules, so it's understandable why this implementation was
chosen. However, the concrete members of namespaces also get placed in the
`__ObjC` module too, and this really confuses things.
To work around this idiosyncrasy of Cxx interop, I've introduced
`Decl::getModuleContextForNameLookup()` which returns the module that a
declaration would ideally belong to if Cxx interop didn't have this behavior.
This alternative to `Decl::getModuleContext()` is now used everywhere that
`MemberImportVisibility` rules are enforced to provide consistency.
Additionally, I found that I also had to further special-case the header import
module for Cxx interop because it turns out that there are some additional
declarations, beyond imported namespaces, that also live there and need to be
implicitly visible in every source file. The `__ObjC` module is not implicitly
imported in source files when Cxx interop is enabled, so these declarations are
not deemed visible under normal name lookup rules. When I tried to add an
implicit import of `__ObjC` when Cxx interop is enabled, it broke a bunch
tests. So for now, when a decl really belongs to the `__ObjC` module in Cxx
interop mode, we just always allow it to be referenced.
This Cxx interop behavior really needs a re-think in my opinion, but that will
require larger discussions.
Resolves rdar://136600598.
The generality of the `AvailabilityContext` name made it seem like it
encapsulates more than it does. Really it just augments `VersionRange` with
additional set algebra operations that are useful for availability
computations. The `AvailabilityContext` name should be reserved for something
pulls together more than just a single version.
ValueDecl::isInterfacePackageEffectivelyPublic is used to check if a package decl in
interface file can be skipped for typecheck; if the decl is inlinable and in public or
private interface, it should be allowed to skip. This PR adds a missing check which
looks up the Interface source kind.
Resolves rdar://135388095
Back off treating local lets of tuple type as "initializable", expanding
on the narrow carve-out from #74133. Without this, we would reject local
lets of tuple type that are initialized piecemeal.
Fixes rdar://135028163.
Some requirement machine work
Rename requirement to Value
Rename more things to Value
Fix integer checking for requirement
some docs and parser changes
Minor fixes
Replace the existing C++ implementation of extractInlinableText with
a new implementation based on swift-syntax. It uses SwiftIfConfig to
remove inactive regions (with a special mode), and a new compiler-only
entrypoint in the library to remove comments and `#sourceLocation`.
Allow any declaration to be marked with `@unsafe`, meaning that it
involves unsafe code. This also extends to C declarations marked with
the `swift_attr("unsafe")` attribute.
Under a separate experimental flag (`DisallowUnsafe`), diagnose any
attempt to use an `@unsafe` declaration or any unsafe language feature
(such as `unowned(unsafe)`, `@unchecked Sendable`). This begins to
define a "safe" mode in Swift that prohibits memory-unsafe constructs.
