Merge main 2021-02-18 #2763
Merged
Merge main 2021-02-18 #2763
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add a general heuristic that options ending in -path expect an argument. Remove such options from the explicit is_arg_param list and sort it to simplify maintenance. Recognize -target-sdk-version.
There is a known issue with module interfaces where a type with the same name as a module will disrupt references to types in that module. Fully fixing it will require a new language feature (SR-898) which is not yet available. In the meantime, module interfaces support a workaround flag (“-Xfrontend -module-interface-preserve-types-as-written”) which prints an alternate form that usually works. However, you have to know to add this flag, and it’s not obvious because nothing breaks until a compiler tries to consume the affected module interface (or sometimes even one of its clients). This commit emits a warning during module interface emission whenever the module interface either imports a type with the same name as the module being built, or declares a type with the same name as a visible module. This lets the user know that the type may cause problems and they might need to implement a workaround.
Previously, the error stored in the async context was of type SwiftError *. In order to enable the context to be callee released, make it indirect and change its type to SwiftError **. rdar://71378532
This makes it much easier to remove adjacencies when constraint is retracted from the bindings.
This needs llvm-project PR 2481.
…peAliasDecl with a dependent underlying type Fixes https://bugs.swift.org/browse/SR-11639 / rdar://problem/56466696
Rather than skipping non-definitions, we should just check whether we've already seen this decl. This not only fixes the specific problem with class templates but also is a more general fix for other sub decls.
diag::warning_module_shadowing_may_break_module_interface was *enormous* but still described the problem too tersely to convey everything that was needed. Instead, reference a bug report that describes the problem and its workarounds in more detail.
In OSSA, there is no reason for the cond_br instruction to take arguments. In OSSA utilities, we have two types of block arguments: terminator results and phis. cond_br arguments don't fit into either one of these categories. Supporting them would be prohibitively complex. In fact, I have no idea model it. I have already made the assumption in several places that we don't support cond_br args. It would be impossible to test all the code that makes this assumption, so even if we wanted to support cond_br args, they would always be broken in practice. Simply mark them illegal in the SILVerifier and make sure no OSSA passes generate them.
This only runs on OSSA now, so I am deleting the non-OSSA tests and put in an early bail out since there are some tests that have not been updated yet for OSSA, that run the diagnostic passes, but for which this pass never kicked in on. NOTE: I also while updating the tests noticed a bunch were assuming load_borrow like semantics. So I updated them with that in mind and implemented support in the pass for that.
…s open_existental_box, store_borrow. These both are already classified as interior pointers. Thus, we would have already handled them at the top of the loop where we handle interior pointer operands.
…t dest. A store_borrow is a manner to temporarily "borrow" a guaranteed value into memory for purposes like reabstraction. To make this safer in OSSA, we treat a store_borrow's result as an interior pointer into the stored guaranteed value, causing all uses of that result to be validated as being within the lifetime of the guaranteed value. NOTE: This is not the complete store_borrow verification story. We also will verify that the memory that is being store_borrowed into is not written to while the store_borrow's result is live.
Just didn't see one. Now we have added to our proof collection a test case where the store_borrow's result has a use after the end of the source object's lifetime.
…store_borrow. The store_borrow's result is a sub-interior pointer that ensures that any uses of the interior pointer are within the lifetime of the borrowed value that is being stored. But fundamentally this is just embedding lifetime ownership on def-use edges and once ossa is lowered the result is just the destination address. So it makes sense to include the uses of the result of the store_borrow as the dest's uses.
I didn't find one in the file, so I added it.
Add the following mangling rule: ``` global ::= global generic-signature? 'TJV' AUTODIFF-FUNCTION-KIND INDEX-SUBSET 'p' INDEX-SUBSET 'r' // autodiff derivative vtable thunk ``` Resolves rdar://74340331.
…th weak references.
The DiagnoseLifetimeIssuesPass pass prints a warning if an object is stored to a weak property (or is weakly captured) and destroyed before the property (or captured reference) is ever used again.
This can happen if the programmer relies on the lexical scope to keep an object alive, but copy-propagation can shrink the object's lifetime to its last use.
For example:
func test() {
let k = Klass()
// k is deallocated immediately after the closure capture (a store_weak).
functionWithClosure({ [weak k] in
// crash!
k!.foo()
})
}
Unfortunately this pass can only catch simple cases, but it's better than nothing.
rdar://73910632
…le-entry-thunks
…_supend_async [IRGen] Use the result polymorphic coro.suspend.async intrinsic
OSSA: Disable cond_br arguments
…ssues SILOptimizer: add a diagnostics pass to warn about lifetime issues with weak references.
…add-fix [cxx-interop] Skip already-imported sub decls.
…olved-dmt-fix GSB: An unresolved DependentMemberType might resolve to a concrete TypeAliasDecl with a dependent underlying type
Often, this API is used for its side effects and nobody cares about the handle.
The proper fix is tracked by rdar://problem/74359824.
…-partial-apply
…generic SILGen: Handle pseudogeneric completion-handler-based async APIs.
… SIL entities and use it to properly invalidate global variables/witness tables when we delete them. Otherwise, one runs into memory corruption. I ran into this while enabling ossa on the stdlib for non-Darwin platforms. Hopefully we do not regress on this again when someone adds more optzns that eliminate these since I added a big NOTE to warn people to do it and implemented support even for the entities we do not support deleting at the SIL level... yet.
…leteTask-convention [Runtime] Fix calling convention of async function.
…ons-in-invalid-result-builder [Sema][CodeCompletion] Allow empty case statement bodies in the result builder transform...
I believe these code paths could only be reached by re-typechecking invalid code in the old CSDiag implementation.
…and mangle them.
Differentiability witnesses are now keyed by the original function name, the differentiability kind, and the autodiff config.
Updated SIL syntax:
```
differentiability-kind ::= 'forward' | 'reverse' | 'normal' | 'linear'
sil-differentiability-witness ::=
'sil_differentiability_witness'
sil-linkage?
'[' differentiability-kind ']'
'[' 'parameters' sil-differentiability-witness-function-index-list ']'
'[' 'results' sil-differentiability-witness-function-index-list ']'
generic-parameter-clause?
sil-function-name ':' sil-type
sil-differentiability-witness-body?
sil-instruction ::=
'differentiability_witness_function'
'[' sil-differentiability-witness-function-kind ']'
'[' differentiability-kind ']'
'[' 'parameters' sil-differentiability-witness-function-index-list ']'
'[' 'results' sil-differentiability-witness-function-index-list ']'
generic-parameter-clause?
sil-function-name ':' sil-type
```
```console
sil_differentiability_witness [reverse] [parameters 0 1] [results 0] <T where T: Differentiable> @foo : <T> $(T) -> T
differentiability_witness_function [vjp] [reverse] [parameters 0] [results 0] <T where T: Differentiable> @foo : $(T) -> T
```
New mangling:
```swift
global ::= global generic-signature? 'WJ' DIFFERENTIABILITY-KIND INDEX-SUBSET 'p' INDEX-SUBSET 'r' // differentiability witness
```
```console
$s13test_mangling3fooyS2f_S2ftFWJrSpSr ---> reverse differentiability witness for test_mangling.foo(Swift.Float, Swift.Float, Swift.Float) -> Swift.Float with respect to parameters {0} and results {0}
```
Resolves rdar://74380324.
For now, this is NFC, but it lays the groundwork for implementing 'reasync'.
The body is not type checked, so we check effects on it anyway.
…SSA as well. I had to fix a memory corruption bug (see previous commit) to land this. But now that it is fixed, we are ready!
…utoclosure Revert "[SR-12033] [Sema] Do not allow inferring defaultable closure `() -> $T` for autoclosure arguments result"
When running in the allow errors mode (-experimental-allow-module-with-compiler-errors), modules may contain invalid declarations. The rest of the compiler pipeline, however, expects to have valid declarations unless diagnostics have emitted an error. Emit an error while deserializing to maintain this assumption. Note that these errors will not have a useful location, unless there's a corresponding `.swiftsourceinfo`. This isn't a problem for the intended use case in IDEs, where diagnostics outside the current file would be ignored anyway. Since reading declarations is lazy, SILGen (and thus SIL diagnostics) can still run as long as any invalid declarations weren't referenced in the compiling module. Resolves rdar://74325388
Sema: Start abstracting out the 'effect' in rethrows-checking logic
…impl [stdlib] Make MutableCollection.partition(by:) implementation inlinable
…9f5031a505217e7d7aba8dc [ownership] On non-Darwin platforms, serialize the stdlib in OSSA form.
…le-type-cleanup Sema: Remove some unreachable code from CSApply
…t-closure Add support for @Concurrent attribute on closures.
[Serialization] Emit an error on deserializing an invalid declaration
|
@swiftwasm/toolchain-team we need to cherry-pick ff78f61 to 5.4 branch also. if you have time could you do that? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.