Merge main 2021-03-18 #2876
Merged
Merge main 2021-03-18 #2876
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
I am putting these tests into a new `Sanitizers/tsan` subfolder so we can keep the same test file name (avoid need for `tsan-` prefix). This should increase the chance that changes to the tests make it to the TSan duplicate. I will move and rename existing sanitizer tests (including ASan) tests to keep consistency in a follow-up PR.
This is useful during debugging when manually running the test.
I have identified the following conceptual synchronization points at which task data and computation can cross thread boundaries. We need to model these in TSan to avoid false positives: Awaiting an async task (`AsyncTask::waitFuture`), which has two cases: 1) The task has completed (`AsyncTask::completeFuture`). Everything that happened during task execution "happened before" before the point where we access its result. We synchronize on the *awaited* task. 2) The task is still executing: the current execution is suspended and the waiting task is put into the list of "waiters". Once the awaited task completes, the waiters will be scheduled. In this case, we synchronize on the *waiting* task. Note: there is a similar relationship for task groups which I still have to investigate. I will follow-up with an additional patch and tests. Actor job execution (`swift::runJobInExecutorContext`): Job scheduling (`swift::swift_task_enqueue`) precedes/happens before job execution. Also all job executions (switching actors or suspend/resume) are serially ordered. Note: the happens-before edge for schedule->execute isn't strictly needed in most cases since scheduling calls through to libdispatch's `dispatch_async_f`, which we already intercept and model in TSan. However, I am trying to model Swift Task semantics to increase the chance of things to continue to work in case the "task backend" is switched out. rdar://74256733
Add tests that check that TSan detects true positives in simple examples for both actors and async tasks.
This reverts commit 1e3de35.
…standalone executable
…wSyntaxNode to RecordedOrDeferredNode
Both makeDeferredLayout and recordRawSyntax were looping over the children, but only one loop is necessary.
If the source is empty, the start of the copied buffer is a nullptr which doesn't live inside the SyntaxArena's bump allocator. Thus the assert inside `setHotUseMemoryArea` fails.
This furthere reduces the size of ParsedRawSyntaxNode, as well as for intermediate data structures using in SyntaxParseActions, improving syntax parsing performance.
…longs to key path component result
…arify its meaning New name is `isInKeyPathComponent` since it's implemeneted as a check for presence of `KeyPathComponent` element in the locator that covers every sub-element contained in a key path component as well.
It was added for staging; but that has been completed.
rdar://74051287
…ence, member type has been bound before base type If member has been bound before the base and the base was incorrect at that (e.g. fallback to default `Any` type), then we need to re-activate all of the constraints associated with this member reference otherwise some of the constraints could be left unchecked in inactive state. This is especially important for key path expressions because `key path` constraint can't be retired until all components are simplified. Resolves: SR-13364 Resolves: rdar://66706980 Resolves: rdar://74711236
This shortens -Onone lifetimes. To eliminate ARC traffic, the optimizer reorders object destruction. This changes observable program behavior. If a custom deinitializer produces side effects, code may observe those side effects earlier after optimization. Similarly, code that dereferences a weak reference may observe a 'nil' reference after optimization, while the unoptimized code observed a valid object. Developers have overwhelmingly requested that object lifetimes have similar behavior in -Onone and -O builds in order to find and diagnose program bugs involving weak references and other lifetime assumptions. Enabling the copy propagation at -Onone is simply a matter of flipping a switch. -Onone runtime and code size will improve. By design, copy propagation, has no direct affect on compile time. It will indirectly improve optimized compile times, but in debug builds, it simply isn't a factor. To support debugging, a "poison" flag was (in prior commits) added to new destroy_value instructions generated by copy propagation. When OwnershipModelEliminator lowers destroy_value [poison] it will generate new debug_value instructions with a “poison” flag. These additional poison stores to the stack could increase both code size and -Onone runtime. rdar://75012368 (-Onone compiler support for early object deinitialization with sentinel dead references)
…ver-new rdar://75275788
The scheme uses 'Tw' followed by the index--the number of non-constant async partial applies that have been thunked in the function.
…al_value Delete all reference count instructions on a global_value if the only other uses are projections (ref_element_addr and ref_tail_addr).
We don't need to initialize the global object if it's never used for something which can access the object header. This let's e.g. lookup-tables to be compiled with zero Array-overhead. rdar://59874359
…availability [SymbolGraph] don't filter out symbols if their availability was for a platform-agnostic target rdar://74670284
…ask_handle_cancellation
…conditional-requirement-inference GSB: Narrow scope of conditional requirement inference
…rement implied a redundant requirement Recall the meaning of an explicit requirement here: - If the requirement is part of a root SCC, it is redundant unless it is the 'best' requirement from that root SCC. - If the requirement is part of a non-root SCC, it is always redundant. Instead of computing the set of redundant requirements, we build a mapping. The value in the mapping stores the set of root requirements that imply the given redundant requirement. This mapping is computed by traversing the graph from each root, recording which components can be reached from each root. For now, I'm using this to fix rdar://problem/65263302. After fixing that bug, this will also allow us to radically simplify the various callers of checkConstraintList().
…lass-conformance [Runtime] Fixed shared cache protocol conformance lookup with subclasses.
…undant conformance requirements
When constructing a generic signature, any redundant explicit requirements
are dropped from the final signature.
We would assume this operation is idempotent, that is, building a new
GenericSignatureBuilder from the resulting minimized signature produces
an equivalent GenericSignatureBuilder to the original one.
Unfortunately, this is not true in the case of conformance requirements.
Namely, if a conformance requirement is made redundant by a superclass
or concrete same-type requirement, then dropping the conformance
requirement changes the canonical type computation.
For example, consider the following:
public protocol P {
associatedtype Element
}
public class C<O: P>: P {
public typealias Element = O.Element
}
public func toe<T, O, E>(_: T, _: O, _: E, _: T.Element)
where T : P, O : P, O.Element == T.Element, T : C<E> {}
In the generic signature of toe(), the superclass requirement 'T : C<E>'
implies the conformance requirement 'T : P' because C conforms to P.
However, the presence of the conformance requirement makes it so that
T.Element is the canonical representative, so previously this signature
was minimized down to:
<T : C<E>, O : P, T.Element == O.Element>
If we build the signature again from the above requirements, then we
see that T.Element is no longer the canonical representative; instead,
T.Element canonicalizes as E.Element.
For this reason, we must rebuild the signature to get the correct
canonical type computation.
I realized that this is not an artifact of incorrect design in the
current GSB; my new rewrite system formalism would produce the same
result. Rather, it is a subtle consequence of the specification of our
minimization algorithm, and therefore it must be formalized in this
manner.
We used to sort-of do this with the HadAnyRedundantRequirements hack,
but it was both overly broad (we only need to rebuild if a conformance
requirement was implied by a superclass or concrete same-type
requirement) and not sufficient (when rebuilding, we need to strip any
bound associated types from our requirements to ensure the canonical
type anchors are re-computed).
Fixes rdar://problem/65263302, rdar://problem/75010156,
rdar://problem/75171977.
[Diagnostics] Check whether missing conformance could be fixed by using `.rawValue`
…ping. Without this, we'll end up accepting invalid conversions when there is a global actor-qualified function type in a non-top-level structural position.
[ConstraintSystem] Teach `getFunctionArgApplyInfo` about `inout` expr…
We'll get a real mangling soon; this is a temporary hack.
Throwing functions pass the error result in `swiftself` to the resume partial function. Therefore, `() async -> ()` to `() async throws -> ()` is not ABI compatible. TODO: go through remaining failing IRGen async tests and replace the illegal convert_functions.
Update Swift version to 5.5
…ion-type-conversion
…-without-redundant-conformances GSB: Formalize the old hack where we rebuild a signature that had redundant conformance requirements
Instead of looking at the requirements before passing them off to
the GSB, let's look at the difference between the final signature
and the original signature.
This makes the checks more accurate, for example we want to
detect that 'E' was specialized in the below:
@_specialize(where S == Set<String>)
public func takesSequenceAndElement<S, E>(_: S, _: E)
where S : Sequence, E == S.Element {}
Add test case for rethrows functions with defaulted throwable argument functions
…leanup Sema: Clean up @_specialize diagnostics
…-copy-ctor [cxx-interop] Bail earlier when importing invalid records.
…_abi IRGen: async error ABI
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.