forked from swiftlang/swift
-
Notifications
You must be signed in to change notification settings - Fork 30
Merge main 2022-06-09 #4635
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Merge main 2022-06-09 #4635
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
* InterfaceGen reports a primary associated type as a reference to the 'associatedtype' declaration * CursorInfo on a primary associated type returns information of the 'associatedtype' declaration rdar://93275458
…ng` and `Swift.String` This fixes a dangling pointer issue when creating a `Swift.String` from `std::string`. Also fixes a warning: ``` warning: variable 's' was never mutated; consider changing to 'let' constant var s = SILBasicBlock_debugDescription(bridged) ~~~ ^ let ``` rdar://92963081 rdar://93053488
…OOLS` mode Some code in SwiftCompilerSources, especially the parts that use C++ interop, triggers bugs in older versions of the Swift compiler. To make sure that `HOSTTOOLS` builds don't produce obscure compiler errors or crashes, let's require a relatively new Swift compiler for `HOSTTOOLS` build.
When we encounter an input or output with an unknown extension 'TY_INVALID', still produce valid JSON specifying the type as "unknown" instead of either crashing or producing malformed JSON. Resolves rdar://94348593
Precedence groups should be suggested only at * After colon in operator decls * After 'higherThan:' or 'lowerThan:' in precedence group decls rdar://76977760
…h more than one element
This test was temporarily disabled while Remote Mirror was being upgraded to handle task escalation, but it works now. rdar://94454729
When initializing an actor, job, or task, use _swift_instantiateInertHeapObject to have the OS's libswiftCore set up the object's refcounts field, to ensure we get a valid initial state. There is no equivalent for immortal objects, but by a stroke of luck the new representation for immortal refcounts happens to set the immortal bit in the old representation. rdar://93087343
This detects a bug unique to the oldest back-deployment targets for Swift concurrency, where Tasks were getting created with an incorrect bit pattern that made them immortal. Verifies that rdar://93087343 has been fixed.
TypeConverter doesn't know by itself what SILModule it's currently lowering on behalf of, so the existing code forming the TypeExpansionContext for opaque types incorrectly set the isWholeModule flag to always false. This created a miscompile when a public API contained a closure that captured a value involving private types from another file in the same module because of mismatched type expansion contexts inside and outside the closure. Fixes rdar://93821679
Previously we gave them the same SIL linkage as the method, then changed the LLVM IR linkage to 'internal' (which is roughly equivalent to SIL 'private') in IRGen. This would crash in the SIL verifier if an @objc method was '@_alwaysEmitIntoClient'. While such a combination of attributes is silly since '@objc' methods are intrinsically part of the ABI, we should not crash in this case. The simplest fix is to just set the linkage to private at the SIL level, avoiding the IRGen hack entirely.
…rency-task-leak
…ray-literals [Sema] Allow TreatArrayLiteralAsDictionary fix to handle literals with more than one element
[Test] Reenable reflect_task.swift on Darwin.
`cxxString` might get deallocated immediately after `c_str()` call, which would mean that the pointer passed to `String(cString:)` points to invalid memory. We haven't actually seen this, but let's preemptively add an explicit `withExtendedLifetime` call to avoid running into this in the future.
SIL: @objc thunks should have private SIL linkage
…encegroup-rdar76977760 [CodeCompletion] Don't suggest precedence groups in expr/type position
…ownExtensions [Parseable Output] Generate valid output for files of unknown types
…angling-ptr [cxx-interop] Fix a potential dangling pointer in `String(cxxString:)`
…inux [cxx-interop] Enable C++ stdlib overlay on Linux
Property wrappers trigger initializer synthesis. Synthesized initializers should not be re-typechecked when encountered e.g. while re-solving closure with a different contextual type. Resolves: swiftlang#59294 Resolves: rdar://94506352
Fixes rdar://94552302
…i386 Fix test/IRGen/abitypes.swift for i386-watchos
… a friend so we can invoke that method. The only place outside of SILType that uses getRawASTType() is in SILPrinter. It is really an inner detail of SILType that we don't want to expose. With that in mind, in this commit we: 1. Made SILType::getRawASTType() private. 2. Forward declared SILPrinter in SILType.h. We don't define it so no one can use it, but the declaration still lets us make it a friend class of SILType (allowing SILPrinter to still access getRawASTType()).
…e explicitly about move only wrapper and not move only itself. Specifically: * isMoveOnly() -> isMoveOnlyWrapped() * asMoveOnly() -> addingMoveOnlyWrapper() * withoutMoveOnly() -> removingMoveOnlyWrapper() * copyMoveOnly() -> copyingMoveOnlyWrapper() This is just pure renaming to resolve confusion from the reader.
…oncurrency-path-fix [Testing] Use the SDK name for the back-deployment concurrency library path
…ral mode We resolve protocol typealiases to DependentMemberTypes because the Requirement Machine treats them as rewrite rules. However, it doesn't do this for typealiases in protocol extensions. Fixes rdar://problem/94150249.
…ects an invariant violation
…nt type of a subject type sometimes If you have generic parameters <T, U> and requirements of the form: - T : P - T == ConcreteType<U> - T.[P]U : SomeClass - T.[P]U : SomeProto And furthermore SomeClass does not conform to SomeProto, we can't leave `T.[P]U : SomeClass` unsubstituted; we still have to replace `T` with `ConcreteType<U>` to transform the latter two requirements into: - U : SomeClass - U : SomeProto "Concrete contraction" is easily the hackiest part of the Requirement Machine; I need to come up with a more principled solution for the problem that it solves sooner or later. Fixes rdar://problem/94150249.
Revert: SIL: @objc thunks should have private SIL linkage
…-linux Revert "Merge pull request swiftlang#58983 from apple/egorzhdan/cxx-overlay-linux"
…bjc-thunk-linkage"" This reverts commit 2007d65.
…k-linkage Reapply "SIL: @objc thunks should have private SIL linkage"
…ion-check [SwiftCompilerSources][build] Require recent Swift compiler in `HOSTTOOLS` mode
…ng-init [cxx-interop][SwiftCompilerSources] Fix conversion between `std::string` and `Swift.String`
…te-contraction-fix RequirementMachine: Concrete contraction needs to substitute the parent type of a subject type sometimes
…td::string` and `Swift.String`" This reverts commit be711e3.
…rivate-type SILGen: Carry WMO of type lowering context to closure captures.
…ft-string-init Revert "[cxx-interop][SwiftCompilerSources] Fix conversion between `std::string` and `Swift.String`"
I believe this was causing CMake to get built for the test case and make the test case take ~5min on Linux instead of ~15sec.
…type-rdar93275458 [SourceKit] Update for primary associated types
…8aaf324a1d402ad5d6803b4 [move-only] Two small fixes
Fix abitypes.swift on arm64e-ios
…d-lld-test [test] Explicitly specify --cmake %cmake for build_lld.test
[CSClosure] Fix handling of property wrapped pattern bindings
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.