-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[FixIt]: Diagnostic for use of plain protocol name in type position suggests some or any #74197
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
[FixIt]: Diagnostic for use of plain protocol name in type position suggests some or any #74197
Conversation
marking as ready for an intial review |
Thanks for the reminder, and please do not hesitate to ping me or other code owners once every 2 weeks if your PR stagnates. Have you run any relevant tests locally? If not, please do in subsequent rounds. As a first step, I am going to run a smoke test for you. Shall it fail, please find the test failures in the console output of the job run and try to address them accordingly. Reach out any time. P.S. What happened to the previous PR? |
@swift-ci please smoke test Linux |
I think I ran the tests locally a while ago and it passed. The command I ran is below:
Not sure if that is enough/what is needed to be ran. EDIT: I just ran the command below and am getting the same errors as the jenkins build.
From the jenkins logs, the error is here. It has to do with pieces of code that I did not touch at all, so I am not sure why that fails. Could it be because my branch is out of date from
I think I messed up the branch and ended up pushing to my |
@AnthonyLatsis ping |
@swift-ci please smoke test |
@swift-ci please smoke test Linux |
I checked out main and pulled the latest code as well as ran utils/update-checkout. I merged main into this feature branch to update everything. However, when I re run the build on the main branch, I get no errors. I seem to get errors when running updates on this feature branch and can't understand why. Usually running an entire clean build works, but it isn't anymore.
|
That must be the failure from #74197 (comment) (an assertion failure when building the standard library). |
@AnthonyLatsis any tips on squashing commits? When I want to run |
This means You were doing an interactive rebase ( |
Yes, Wouldn't the hash I want to rebase the rest onto be |
To rebase basically means to replay a commit range on top of a base commit. A rebase will never modify the original commit range. It will replay clones instead. The beauty of the interactive mode is that it allows one to act upon the commits being replayed, such as to edit or squash them. This is how you rewrite history. The general form is:
The range is half-open (this is important to keep in mind): Now to the practical part. Consider the following tree:
We want to squash
This can be done by interactively rebasing # or 'git rebase -i main' for short.
git rebase -i --onto main main feature
Replacing
This is a good occasion to recall that a rebase does not touch the original commits. I simply omitted them in the previous diagram, where |
I forgot you have merge commits in the mix. Merge commits make rebasing a lot more nuanced. Please drop them before squashing (you should be able to do so by running |
0bc3a04
to
86adffa
Compare
ready for a review again!! @AnthonyLatsis |
@swift-ci please smoke test macOS |
@saehejkang Time to debug some failures. Sorry for the hold-up. Hint: The current change is purely additive. Also, the condition you specify for the new diagnostic is looser than the condition for the old one. |
I assume I am missing a check for |
You are, but the current diagnosis is already wrapped in an appropriate |
closing as I am no longer working on the issue |
Changes Made
fixits
when appropriatesome
keywordResolves #68284