Skip to content

[6.0][sending] Fix a bunch of issues around suppressing sending #74068

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 7 commits into from
Jun 3, 2024

Conversation

gottesmm
Copy link
Contributor

@gottesmm gottesmm commented May 31, 2024

Explanation: This fixes a bunch of issues with the suppression of sending that I found recently while working on enabling sending on APIs in the Concurrency library. I felt it stood enough on its own that it made sense to just submit it separately as one functional change. Some notes:

  1. I fixed a bug that was sort of a general problem with the current way we printed suppression checks: we wouldn't print a compiler(>=5.3) if we had a requirement check and then a suppressed check since it was assumed that compiler(>=5.3) only did a compiler check and so we did not need to repeat it since we already did the check earlier. What it actually additionally does is prevents failures due to parsing failures in the if block. So we really need it in both places. This is especially important when suppressing sending since sending is not parsed well by earlier compilers.
  2. I found that we were not suppressing sending used in fields of Nominal Types.
  3. I found that we were not suppressing sending used in arguments of an initializer.

Radars:

  • rdar://129045783

Original PRs:

Risk: Low. Just affects sending.
Testing: Added tests to the test suite.
Reviewer: N/A

gottesmm added 7 commits May 31, 2024 14:47
…ble features to guard against parser errors.

The code here was assuming that if we already emitted a compiler guard for
non-Suppressable features, we could avoid doing it for suppressable
features. The problem with this is that compiler() does more than just check for
compiler versions... it also tells the compiler that parser errors in the if
block should be ignored when if evaluates to false.

rdar://129045783
(cherry picked from commit 521a70f)
…NominalTypes.

These already worked... I am just adding the code coverage before I fix a
different issue in the next commit. This will make it clearer what I am actually
fixing in the next commit when one reads the tests.

(cherry picked from commit 97710b4)
…notes.

rdar://129045783
(cherry picked from commit 14c4576)
… to inits.

rdar://129045783
(cherry picked from commit 11f86a5)
… out an increasing ID for all suppressed statements.

I am using this to better test out suppression statements. I am finding that
FileCheck runs into issues with some of the '#if' lines I am trying to match. I
am able to use this option with my asserts only test to uniquely identify a '#if
...' statement and thus have the pattern matching work. I needed this to get the
test in the next commit to pass testing.

(cherry picked from commit f7bbbbe)
(cherry picked from commit af82326)
@gottesmm gottesmm requested a review from a team as a code owner May 31, 2024 23:16
@gottesmm
Copy link
Contributor Author

@swift-ci test

@gottesmm gottesmm merged commit f39041d into swiftlang:release/6.0 Jun 3, 2024
5 checks passed
@gottesmm gottesmm deleted the release/6.0-rdar129045783 branch June 3, 2024 16:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants