Merge main 2020-10-20 #2037
Merged
Merge main 2020-10-20 #2037
Conversation
This file contains 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
…hared libraries This was presumably added as a backup, in case the libraries in a toolchain couldn't be found, but will not work well, so take it out.
- Enforce types of continuations and resume/error BBargs for await - Can't access the continuation again or exit the function mid-suspend
While inferring bindings, let's record not only the fact that current type variable is a subtype of some other type variable but track constraint which establishes this relationship.
Instead of recording all of the binding "sources" let's only record subtype, supertype and equivalence relationships which didn't materialize as bindings (because other side is a type variable). This is the only information necessary to infer transitive bindings and protocol requirements.
Implements iterative protocol requirement inference through
subtype, conversion and equivalence relationships.
This algorithm doesn't depend on a type variable finalization
order (which is currently the order of type variable introduction).
If a given type variable doesn't yet have its transitive protocol
requirements inferred, algorithm would use iterative depth-first
walk through its supertypes and equivalences and incrementally
infer transitive protocols for each type variable involved,
transferring new information down the chain e.g.
T1 T3
\ /
T4 T5
\ /
T2
Here `T1`, `T3` are supertypes of `T4`, `T4` and `T5`
are supertypes of `T2`.
Let's assume that algorithm starts at `T2` and none of the involved
type variables have their protocol requirements inferred yet.
First, it would consider supertypes of `T2` which are `T4` and `T5`,
since `T5` is the last in the chain algorithm would transfer its
direct protocol requirements to `T2`. `T4` has supertypes `T1` and
`T3` - they transfer their direct protocol requirements to `T4`
and `T4` transfers its direct and transitive (from `T1` and `T3`)
protocol requirements to `T2`. At this point all the type variables
in subtype chain have their transitive protocol requirements resolved
and cached so they don't have to be re-inferred later.
This is necessary in order to have access to private members of a `ConstraintSystem` for testing purposes, such as logic related to potential binding computation.
…e variable This mimics what `determineBestBindings` does but without sorting.
… inference In situations like: `$T0 <convertible> $T1` `$T1 <conforms to> P` `$T0` should know about `P` as a transitive protocol requirement.
…l inference Let all of the members of the equivalence class be represented by the first type variable encountered during the depth-first walk. This means that supertypes are inferred from the members and all of the transitive protocol requirements are distributed among the members upon return back to the "representative".
...and avoid reallocation. This is immediately necessary for LICM, in addition to its current uses. I suspect this could be used by many passes that work with addresses. RLE/DSE should absolutely migrate to it.
Change ProjectionIndex for ref_tail_addr to std::numeric_limits<int>::max(); This is necessary to disambiguate the tail elements from ref_element_addr field zero.
To clarify and unify logic, improve precision, and behave consistently with other code that does the same thing.
Things that have come up recently but are somewhat blocked on this: - Moving AccessMarkerElimination down in the pipeline - SemanticARCOpts correctness and improvements - AliasAnalysis improvements - LICM performance regressions - RLE/DSE improvements Begin to formalize the model for valid memory access in SIL. Ignoring ownership, every access is a def-use chain in three parts: object root -> formal access base -> memory operation address AccessPath abstracts over this path and standardizes the identity of a memory access throughout the optimizer. This abstraction is the basis for a new AccessPathVerification. With that verification, we now have all the properties we need for the type of analysis requires for exclusivity enforcement, but now generalized for any memory analysis. This is suitable for an extremely lightweight analysis with no side data structures. We currently have a massive amount of ad-hoc memory analysis throughout SIL, which is incredibly unmaintainable, bug-prone, and not performance-robust. We can begin taking advantage of this verifably complete model to solve that problem. The properties this gives us are: Access analysis must be complete over memory operations: every memory operation needs a recognizable valid access. An access can be unidentified only to the extent that it is rooted in some non-address type and we can prove that it is at least *not* part of an access to a nominal class or global property. Pointer provenance is also required for future IRGen-level bitfield optimizations. Access analysis must be complete over address users: for an identified object root all memory accesses including subobjects must be discoverable. Access analysis must be symmetric: use-def and def-use analysis must be consistent. AccessPath is merely a wrapper around the existing accessed-storage utilities and IndexTrieNode. Existing passes already very succesfully use this approach, but in an ad-hoc way. With a general utility we can: - update passes to use this approach to identify memory access, reducing the space and time complexity of those algorithms. - implement an inexpensive on-the-fly, debug mode address lifetime analysis - implement a lightweight debug mode alias analysis - ultimately improve the power, efficiency, and maintainability of full alias analysis - make our type-based alias analysis sensistive to the access path
Add a flag: enable-accessed-storage-dump-uses
Add AccesssedStorage::compute and computeInScope to mirror AccessPath. Allow recovering the begin_access for Nested storage. Adds AccessedStorage.visitRoots().
Compute 'isLet' from the VarDecl that is available when constructing AccessedStorage so we don't need to recover the VarDecl for the base later. This generally makes more sense and is more efficient, but it will be necessary when we look past class casts when finding the reference root.
[Index] Don't report extensions with nothing to index
Add an AccessPath abstraction and formalize memory access
The "bridging-std-string" section contained a typo in the C++ header example, compared to the imported Swift header.
…version-compatibility
[linux] remove absolute rpath of /usr/lib/swift/linux added to many shared libraries
…ion location indicates the user may intend to write them later.
func foo(a: Int, b: Int) {}
func foo(a: String) {}
// Int and String should both be valid, despite the missing argument for the
// first overload since the second arg may just have not been written yet.
foo(a: <complete here>
func bar(a: (Int) -> ()) {}
func bar(a: (String, Int) -> ()) {}
// $0 being of type String should be valid, rather than just Int, since $1 may
// just have not been written yet.
bar { $0.<complete here> }
Try to pass an explicit target to these tests so more exotic hosts do the right thing. rdar://70175753
This fixes a recent source compatibility regression. Fixes <rdar://problem/70445751>.
…erence [CSBindings] Implement transtive protocol requirement inference
…/result are equivalent to applied function
Unfortunately, OutputFileMap does not normalize input names when it is constructing keys. Instead, keys to the map are formed by appending the entry's value directly onto the working directory with the test host's path separator convention. On Windows, the tests here were using UNIX-style path separators when passing inputs to the Driver, so the key was "C:\Path\To\File\A.swift" But the input path to the driver was "C:\Path\To\File/A.swift" To work around this - and to ultimately make the test slightly more portable - just use relative paths to the input files since we've already changed directories to the working directory before we run these driver commands.
…fier SIL: Verify invariants of async_continuation instructions.
…hen-type-checking-for-completion
…-types-are-equal [ConstraintSystem] Record trailing choice match choice when arguments…
…on-check-source-compat Sema: Allow duplicate internal parameter names on protocol requirements
…r-8456 Add regression test for https://bugs.swift.org/browse/SR-8456
Correct a path in the Windows build instructions
Switch To target-swiftc_driver
…ge-main-2020-10-20
MaxDesiatov
reviewed
Oct 20, 2020
| ./utils/webassembly/ci.sh | ||
| env: | ||
| SKIP_XCODE_VERSION_CHECK: 1 |
There was a problem hiding this comment.
Xcode 12.2 Beta 3 is going to be included in GHA images soon after actions/runner-images#1851 is merged, so maybe we should wait until then and turn off the check?
There was a problem hiding this comment.
I want to merge this as soon as possible to avoid making diff large if CI will pass before actions/runner-images#1851 merged. And I'm not sure the virtual-environments PR will be merged quickly.
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.