[6.2] [Strict memory safety] Provide argument-specific diagnostics for calls #81125
+479
−190
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
When we look through a "self" application while decomposing a function call in effects checking, keep track of whether we did so. Use this to ensure that we get the right parameter types when looking at the "self" application vs. the outer call. This has always been wrong, but the async/throws effects don't ever matter for the innermost application (i.e., for `x.m`), so the inconsistency didn't come up. (cherry picked from commit 0b264e2)
Similar to what we do for 'throws' checking, perform argument-specific checking for unsafe call arguments. This provides more detailed failures: ``` example.swift:18:3: warning: expression uses unsafe constructs but is not marked with 'unsafe' [#StrictMemorySafety] 16 | x.f(a: 0, b: 17, c: nil) 17 | 18 | x.f(a: 0, b: 17, c: &i) | | `- note: argument 'c' in call to instance method 'f' has unsafe type 'UnsafePointer<Int>?' | `- warning: expression uses unsafe constructs but is not marked with 'unsafe' [#StrictMemorySafety] 19 | unsafeF() 20 | } ``` It also means that we won't complain for `nil` or `Optional.none` arguments passed to unsafe types, which eliminates some false positives, and won't complain about unsafe result types when there is a call---because we'd still get complaints later about the actually-unsafe bit, which is using those results. Fixes rdar://149629670. (cherry picked from commit ee9487b)
…a call effect (cherry picked from commit 050a514)
…e" in _SwiftifyImport expansions We need to improve on the macro so it doesn't generate unnecessary "unsafe" expressions. (cherry picked from commit 81b68e5)
…alls We've been missing this case forever, but it hadn't come up until we performed "unsafe" checking on calls. (cherry picked from commit 60f7d20)
These should not be escalated to errors when other strict memory safety warnings are, because they aren't safety issues. They could go into a separate group along with the corresponding try and await diagnostics. (cherry picked from commit 02e1d11)
|
@swift-ci please test |
|
For anyone looking closely, I dropped the last commit from the main PR, because I don't want to do the extra "unsafe" effects checking on 6.2 unless strict memory safety is enabled. |
nkcsgexi
approved these changes
Apr 28, 2025
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.
nilnot be considered safe (reducing false positives), and makes it okay to call a function returning an unsafe type if there are no unsafe arguments. (The use of the return value will trigger issues when appropriate).tryandawaitunexpressions). This will remove some warnings under strict memory safety mode, but otherwise should have no effect.