[Strict memory safety] Provide argument-specific diagnostics for calls #81120
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.
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.
…e" in _SwiftifyImport expansions We need to improve on the macro so it doesn't generate unnecessary "unsafe" expressions.
…alls We've been missing this case forever, but it hadn't come up until we performed "unsafe" checking on calls.
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.
Check for unsafe constructs in all modes, so that we can emit the "unsafe does not cover any unsafe constructs" warning consistently. One does not need to write "unsafe" outside of strict memory safety mode, but if you do... it needs to cover unsafe behavior.
DougGregor
requested review from
hborla,
xedin,
ahoppen,
bnbarham,
CodaFi,
hamishknight,
rintaro,
ktoso,
a team,
tshortli and
slavapestov
as code owners
|
@swift-ci please test |
|
@swift-ci please test source compatibility |
|
@swift-ci please smoke test macOS |
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.
Similar to what we do for 'throws' checking, perform argument-specific checking for unsafe call arguments. This provides more detailed failures:
It also means that we won't complain for
nilorOptional.nonearguments 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.