Skip to content

Fix thousands of typos across hundreds of files. #74983

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

Closed
wants to merge 1 commit into from
Closed

Fix thousands of typos across hundreds of files. #74983

wants to merge 1 commit into from

Conversation

Sajjon
Copy link
Contributor

@Sajjon Sajjon commented Jul 5, 2024

Fix thousands of typos across hundreds of files.

Might contain some breaking ones, I might need help identifying which ones to revert.

I've used the awesome CLI tool typos to create this PR in combination with a couple of hours of manual work to sort between false positives, and some "weak true positives" (using command typos -w the cli tool will automatically change files for "strong" positives, but for some typos it is "less sure" about, it will not make any changes on disc, but output those in the terminal as probable typos, "weak positives" I call those, some of which are true, some of which are false).

I will remove the _typos.toml config file before merging this PR (and possibly other PRs "split out" from this, if we go with the "batch" approach).

N.B. I've done a lot of manual work apart from using the typos cli tool, which have taken many hours, e.g. git added some true positives of some files, but ignored some false positives in the same files, and then "typos ignored" those files. The implications of this is that if you were to run the same version of typos with the _typos.toml config file, you would NOT get the same result, some typos would be missed.

I did it like this since many files contained lots of specific false positives, where it made no sense to add those strings to extended identifiers list.

@AnthonyLatsis
Copy link
Collaborator

Do you mind breaking this up into several PRs so that it is hundreds of typos over tens of files? It will be easier to review for us, and you will be less likely to catch a conflict or change request on a given PR.

@Sajjon
Copy link
Contributor Author

Sajjon commented Jul 5, 2024

Do you mind breaking this up into several PRs so that it is hundreds of typos over tens of files? It will be easier to review for us, and you will be less likely to catch a conflict or change request on a given PR.

@AnthonyLatsis sure I could do that, will take me some time to change into that though (I'm on vacation now and have limited time available).

EDIT:
Perhaps 10 PRs with 53 changed filed each would be reasonable ?

@Sajjon
Copy link
Contributor Author

Sajjon commented Jul 5, 2024

@rjmccall you reviewed my PR swiftlang/swift-evolution#2479 (comment)

Any input on this one, and if you want me to chunk it up into several PRs, if so, how many?

@AnthonyLatsis
Copy link
Collaborator

AnthonyLatsis commented Jul 5, 2024

Perhaps 10 PRs with 53 changed filed each would be reasonable ?

You can surely do that, but even 4 PRs with up to 400 additions should be fine.

@@ -37,7 +37,7 @@ let pyramidTemplate: [Int] = (1...pH) + (1...pH).reversed()
// A^R - reversed array A, + - array concatenation operator,
// A indices are in range 1...A.length.
// define adjacent pyramid as A + A^R + A + A^R,
// defne adjacent pyramid hight as A[A.length].
// defne adjacent pyramid height as A[A.length].

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

defne -> define?

@@ -0,0 +1,263 @@
[files]
Copy link
Contributor Author

@Sajjon Sajjon Jul 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the config file for the awesome CLI tool typos I've used to create this PR.

I will remove it before merging this PR (and possibly other PRs "split out" from this, if we go with the "batch" approach).

N.B. I've done a lot of manual work apart from using the typos cli tool, which have taken many hours, e.g. git added some true positives of some files, but ignored some false positives in the same files, and then "typos ignored" those files. The implications of this is that if you were to run the same version of typos with this config file, you would NOT get the same result, some typos would be missed. I did it like this since many files contained lots of specific false positives, where it made no sense to add those strings to extended identifiers list.

EDIT: this was relevant info, copied to PR description.

@@ -1181,7 +1181,7 @@ information when inlined.
The function is a compiler generated thunk.
::

sil-function-attribute ::= '[dynamically_replacable]'
sil-function-attribute ::= '[dynamically_replaceable]'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I regret to inform you that this is correctly documenting the actual attribute.

Copy link
Contributor

@rjmccall rjmccall left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would suggest breaking it up into groups that a reviewer could reasonably scan through in about 5 minutes. I got down to RegionAnalysis.h before I started losing focus and needed a break.

@@ -7497,12 +7497,12 @@ ERROR(wrap_invalid_attr_added_by_access_note, none,

ERROR(cannot_default_generic_parameter_inferrable_from_another_parameter, none,
"cannot use default expression for inference of %0 because it "
"is inferrable from parameters %1",
"is inferable from parameters %1",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While "inferable" is a more common spelling, "inferrable" is used in some published works:

Screenshot 2024-07-05 at 2 28 19 PM

Swift is consistent enough in its use of "inferrable" that I'd be inclined to keep it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

reverted all inferrable -> inferable changes

@@ -357,15 +357,15 @@ class RegionAnalysisValueMap {
public:
RegionAnalysisValueMap(SILFunction *fn) : fn(fn) { }

/// Returns the value for this instruction if it isn't a fake "represenative
/// Returns the value for this instruction if it isn't a "fake" representative
Copy link
Contributor

@beccadax beccadax Jul 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The change to quotation marks here is incorrect, although the change to spelling is fine. (The same goes for later changes in this file.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is consistent with the rest in the file. Many "fake" occurrences. But i will revert/take another look!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

@@ -742,7 +742,7 @@ \section{Associated Types}\label{critical pairs}
\arrow[u, Rightarrow, "\ttgp{0}{0}.(\assocsym{P}{A}.\assocsym{Q}{B}\Rightarrow\assocsym{P}{A}.\texttt{B})"']&&
\end{tikzcd}
\]
Note that this was an overlap of the first kind, so rule (7) is now marked \index{left-simplified rule}\textbf{left-simplified}. Thus, rule (*8) completely supercedes rule (7). Rule (*8) survives minimization and maps to the requirement $\ConfReq{\ttgp{0}{0}.[P]A.[Q]B}{R}$, which appears in the generic signature that we output for this protocol extension:
Note that this was an overlap of the first kind, so rule (7) is now marked \index{left-simplified rule}\textbf{left-simplified}. Thus, rule (*8) completely supersedes rule (7). Rule (*8) survives minimization and maps to the requirement $\ConfReq{\ttgp{0}{0}.[P]A.[Q]B}{R}$, which appears in the generic signature that we output for this protocol extension:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OED indicates that supercede is permissible. It is no longer "standard" but it is still a correct spelling.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine with treating this as a typo. There's no good reason to use non-standard spellings, even if they were previously accepted.

Copy link
Contributor

@beccadax beccadax left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These changes are good, but they aren't so good that they don't need to be reviewed carefully, and this PR is much too large to review in one go.

I'd recommend you try to break this up into individual PRs by compiler subsystem (e.g. each include/ folder and its matching lib/ folder, plus any changes in other files that were forced by changes in the include/ folder) so that each PR is focused enough to find an appropriate set of reviewers for it.

@Sajjon
Copy link
Contributor Author

Sajjon commented Jul 6, 2024

@rjmccall

I would suggest breaking it up into groups that a reviewer could reasonably scan through in about 5 minutes. I got down to RegionAnalysis.h before I started losing focus and needed a break.

@beccadax

I'd recommend you try to break this up into individual PRs by compiler subsystem (e.g. each include/ folder and its matching lib/ folder, plus any changes in other files that were forced by changes in the include/ folder) so that each PR is focused enough to find an appropriate set of reviewers for it.

I'm doing just that, it will be ~20 PRs. I'm dividing them up in:

  • Benchmark
  • docs
  • stdlib
  • SwiftCompilerSources
  • test, multiple batches:
    • test/ide
    • test/SourceKit
    • test/SILOptimizer
    • test/SILGen
    • test/IRGen
    • test/Interop
    • test/MISC
  • lib, multiple batches, work in progress
  • include, multiple batches, work in progress

While doing so, I'm applying the suggestions/corrections you have already reviewed.

I need one more day.

If it is helpful, I can create an "epic issue" for this, with links to all PRs?

I will probably close this PR once I've opened the other PRs.

Any input? Or sounds good?

@compnerd
Copy link
Member

compnerd commented Jul 6, 2024

I think that doing the lib and include simultaneously is better - the headers are associated with the libraries, and so the reviewers are going to be the same and sending them together makes more sense as the same area is being looked at.

@Sajjon
Copy link
Contributor Author

Sajjon commented Jul 7, 2024

@compnerd @beccadax @rjmccall @AnthonyLatsis @Lancelotbronner I'm closing this PR in favour of tracking issue: #75022 which links to 14 PRs

@Sajjon Sajjon closed this Jul 7, 2024
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.

6 participants