forked from apple/swift
-
Notifications
You must be signed in to change notification settings - Fork 28
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
[pull] swiftwasm from main #5292
Merged
Merged
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
Type aliases for plain protocols should resolve as opaque types with implicit some feature flag Fixes rdar://101403690
…d opaque result type Fixes apple#63291.
…osition syntax error Fixes apple#62518
Follow-up to apple#63505 Since, when the type is not stated, a variable assumes the type of its initializer that enables out-of-scope variables to be nested inside of some other concrete type i.e. Optional. Resolves: apple#63455
… emit diagnostics for ref_element_addr and global_addr.
…sumable semantics. rdar://104874497
…ref_element_addr.
As part of this I also had to change how we emit global_addr in SILGenLValue. Specifically, only for noncopyable types, we no longer emit a single global_addr at the beginning of the function (in a sense auto-CSEing) and instead always emit a new global_addr for each access. The reason why we do this is that otherwise, access base visitor will consider all accesses to the global to be for the same single access. In contrast, by always emitting the global_addr each time, we provide a new base for each access allowing us to emit the diagnostics that we want to. rdar://102794400
…5f9a72f66f06c7cc9cc [move-only] Teach the checker how to handle ref_element_addr and global_addr with assignable_but_not_consumable semantics
[Sema] Fix Issue apple#63291 by aligning error messages for failure to infer generic parameter and opaque result type
…ro-locations Don't annotate entities not in the primary buffer
Changed 'protocols' to 'type constraints' for obsoleted protocol composition syntax error
…fects. Exclusive argument -> argument effects cannot appear because such an effect would involve a store which is not permitted for exclusive escapes.
… effects * Disallow stores in the return -> argument path. When walking up in the EscapeUtils, it's allowed to follow stores. Therefore stores wouldn't be handled correctly. * Also make sure that there is a return -> argument path at all Fixes a wrong address-escaping effect in case the called function copies an indirect argument to a newly created object. rdar://105133434
…guments This is the only apply instruction where address arguments actually can "escape"
When walking up we shouldn't end up at a load where followLoads is false, because going from a (non-followLoads) address to a load always involves a class indirection. There is one exception: loading a raw pointer
[move-only] Add sil-verify-all to all tests.
…he OS stdlib or back deployment stdlib.
…ntaxPrinter for reuse
… offset into the vtable for classes deriving from resilient classes
…it-some [NameLookup] Type Aliases should resolve as opaque
* update to argument parser 1.2.0 * Apply suggestions from code review
EscapeUtils: fix some bugs related to `followLoads`
…hecker Teach the related-id checker to ignore things from other buffers
…erify [Macros] Harden discriminator verification and macro expansion mangling
…test behind `requires=asserts`
…_client-unsupported-back-deployment [Test] Mark objc_implementation_swift_client unsupported when using the OS stdlib or back deployment stdlib.
[CSGen] Detect nested out-of-scope variables in recursive declarations
[interop][SwiftToCxx] fix vtable offset computation & dispatch virtual Swift methods using a relative offset into the vtable for classes deriving from resilient classes
[Compile Time Constant Extraction] Guard Runtime Metadata Attributes test behind `requires=asserts`
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.
See Commits and Changes for more details.
Created by pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )