`module.map` as a module map name has been discouraged since 2014, and
Clang will soon warn on its usage. This patch renames all instances of
`module.map` in the Swift tests to `module.modulemap` in preparation
for this change to Clang.
rdar://106123303
The following program crashed when compiled with the Swift 5.7 and 5.8 compilers:
```
@available(macOS 12, *)
@_backDeploy(before: macOS 99)
public func foo<T>(_ t: __owned T) {
print("foo")
}
class C {
deinit {
print("deinit")
}
}
foo(C())
print("done")
```
```
> ./test
foo
deinit
[1] 49162 segmentation fault ./test
```
The root cause is that generated SIL for the back deployment thunk for `foo(_:)` included its own `destroy_addr` instruction for the value of `t`, but didn't copy the parameter before passing it to the real function implementation which also destroys the value. The fix is to forward ownership of the parameter values to the called function, which causes cleanup generation to be skipped.
Resolves rdar://104436515
If the emission of a function is delayed via `emitOrDelayFunction()`, then the function is recorded on a list of delayed functions. If the delayed function is later referenced, then the function moves from the delayed list to the "forced" list which will cause it to actually be emitted later. The implementation of `emitOrDelayFunction()` had a bug when called twice for the same delayable function - it would emit that function prematurely if the function moved to the forced list between the two invocations. Later, during forced function emission a multiple definitions of symbol diagnostic would be emitted since the function was not empty.
This issue could be triggered by `@_backDeploy` functions that have auxilary delayable helper functions (e.g. defer blocks). SILGen visits `@_backDeploy` functions twice (once for the copy of the function emitted into the client and once for the resilient copy of the function) so `emitOrDelayFunction()` is called twice for each of the helper functions and the helper functions could become referenced between the two calls.
The fix is to check for an existing entry in the forced functions list before delaying or emitting a delayable function.
Resolves rdar://102909684
Per Swift Evolution feedback, back deployed functions should be allowed to be inlinable, even though this means that the version of the function in the library may not always be exectued when it is otherwise available.
Resolves rdar://102792806
The `call` argument to `diagnoseDeclAsyncAvailability()` may be `nullptr` when the structure of the AST prevents `getEnclosingApplyExpr()` from finding the enclosing apply. The diagnostics implementation introduced with https://github.com/apple/swift/pull/60663 needs to tollerate this, similar to the rest of `diagnoseDeclAsyncAvailability()`.
Resolves rdar://100862513
We used to attach this diagnostic to the implicit decl. Now, attach it to the enclosing decl and offer an extra note that states the availability of the implicit declaration that is at conflict with the availability of the enclosing scope.
rdar://74513654
The `__future__` we relied on is now, where the 3 specific things are
all included [since Python 3.0](https://docs.python.org/3/library/__future__.html):
* absolute_import
* print_function
* unicode_literals
* division
These import statements are no-ops and are no longer necessary.
APIs with a variety of function signatures (inout parameters, throwing, generic, existential parameters and return values, etc.) are exercised to verify SILGen for these cases.
• There is now one access note success remark and fix-it per declaration, not per attribute/modifier.
• Failure remarks have been rephrased to better emphasize the cause of the failure.
• The wording of other access note remarks and notes have been changed to follow a similar formula.
Implicitly add the @completionHandlerAsync attribute for ObjCMethodDecl
that have a completion handler. Adds a link from the non-async to the
async function for use in diagnostics and refactorings.
Resolves rdar://74665226
This commit adds an ObjCReason::ExplicitlyObjCByAccessNote value which diagnoses invalid uses, but using remarks instead of errors so that the failures don’t block builds even with -warnings-as-errors enabled.
This commit also adds annotations to attr/attr_objc.swift to generate a ton of access note test cases from it. In this commit, many of these test cases don’t pass yet. Subsequent commits will fix these bugs.
Availability macros passed via the frontend flag -define-availability
should be accepted by @_originallyDefinedIn where they behave as they do
in @available.
rdar://72354787
This affects module interfaces, interface generation in sourcekitd, and
diagnostics. Also fixes a fixit that was assuming the 'OSX' spelling when
computing the source range to replace.
Resolves rdar://problem/64667960
The tests for the @main and @_originallyDefinedIn attributes were
insufficiently general to get decent platform coverage. Generalize
them to at least run on iOS, with appropriate %target-run'ification.
To correctly call designated super class initializers the designated
intializer (and not the allocator) is dynamically replaceable.
Convenience allocators are dynamically replaceable as before.
We weren't doing much validation when dynamically replacing storage
declarations, and has an assert() that should be an error. Clean up this
area a bit, dealing with simple ambiguities (i.e., there are two
properties or subscripts with different type signatures; pick the
matching one) and reporting an error when there is a true ambiguity.
Fixes rdar://problem/46737657.
Sema would directly check for the presence of the @objcMembers attribute,
and inherit it from the immediate superclass in validateDecl().
We don't want validateDecl() to have side effects like this and this was
already a problem, because it would not inherit the attribute transitively
in some cases.
Instead, add a ClassDecl::hasObjCMembers() method that walks over all
ancestors and caches the result.
<rdar://problem/46420252>
<rdar://problem/46548531> Extend @available to support PackageDescription
This introduces a new private availability kind "_PackageDescription" to
allow availability testing by an arbitary version that can be passed
using a new command-line flag "-swiftpm-manifest-version". The semantics
are exactly same as Swift version specific availability. In longer term,
it maybe possible to remove this enhancement once there is
a language-level availability support for 3rd party libraries.
Motivation:
Swift packages are configured using a Package.swift manifest file. The
manifest file uses a library called PackageDescription, which contains
various settings that can be configured for a package. The new additions
in the PackageDescription APIs are gated behind a "tools version" that
every manifest must declare. This means, packages don't automatically
get access to the new APIs. They need to update their declared tools
version in order to use the new API. This is basically similar to the
minimum deployment target version we have for our OSes.
This gating is important for allowing packages to maintain backwards
compatibility. SwiftPM currently checks for API usages at runtime in
order to implement this gating. This works reasonably well but can lead
to a poor experience with features like code-completion and module
interface generation in IDEs and editors (that use sourcekit-lsp) as
SwiftPM has no control over these features.
Completely mechanical changes:
- Explicit @objc in a few places
- Some imported APIs changed
- For the mix-and-match tests, just test version 4/5 instead of 3/4
This function (actually checkAccess) was relying on some implicit
assumptions that aren't actually valid in all cases. When they're not,
just fall back to a slower but more correct implementation; when they
are, assert that the two implementations get the same answer. This
allows us to get rid of adjustAccessLevelForProtocolExtension (see
previous commit), though unfortunately not all of the associated hack.
The diff is bigger than I'd like because it includes moving functions
from NameLookup.cpp into Decl.cpp, but most of those didn't change.
- checkAccess only changed in the one if branch for protocols
- ValueDecl::isAccessibleFrom just added the assertion
- AbstractStorageDecl::isSetterAccessibleFrom did not change
No expected functionality change.
One minor revision: this lifts the proposed restriction against
overriding a non-open method with an open one. On reflection,
that was inconsistent with the existing rule permitting non-public
methods to be overridden with public ones. The restriction on
subclassing a non-open class with an open class remains, and is
in fact consistent with the existing access rule.
Otherwise, people subclassing NSView will accidentally call NSView.print
when they're trying to call Swift.print.
rdar://problem/18309853
Swift SVN r30334
