https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85665
--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to Roland Illig from comment #3) > (In reply to Jonathan Wakely from comment #2) > > It might be better to report multiple bugs, one per target backend, so that > > the relevant target maintainers are informed. > > Oh, I tried that last year. Of the 113 bugs I reported, 41 are still open. That's a shame. As Manu said, the ones in target-specific code are often only seen by maintainers of that target, not reviewed by the global reviewers or the diagnostics maintainers. On the plus side, some of these diagnostics are probably only rarely seen by users, and not on widely-used targets. > Therefore I thought I'd try a different approach this time. Understandable. Thank you for persisting with trying to fix these kind of issues. You're likely to have more success if you simply send a patch with fixes to gcc-patc...@gcc.gnu.org, CCing the diagnostics maintainers. They can then review your suggested fixes and commit the whole patch to fix everything at once. Even better would be to get write access to SVN and fix them yourself (getting approval for anything that isn't an "obvious fix" as per https://gcc.gnu.org/svnwrite.html#policies under "Free for all"). > Since it's only about the wording of the diagnostics, it should be possible > to handle them all in a few commits, rather than splitting the work onto 12 > people. > > > To avoid similar problems in future, I wonder if a weekly email detailing > > any new or modified diagnostics could be produced automatically. The > > diagnostics maintainers (and anybody else interested) could look over it and > > ensure that we use correct grammar, punctuation, and style. > > Does this mean you already have diagnostics maintainers? Yes, see the MAINTAINERS file. > That would be bad > because then they should have caught many of these typos already. Only if they review every target-specific patch to see if it has changes for diagnostic messages. They're busy people and have lots of other things to do. Maintainers of target backends are trusted to make changes to the subsystems they maintain. > There were > only 53 new strings to translate, and 12 of them contain mistakes. > > Instead of pushing this task to humans, I still think an automatic process > is much more efficient since it doesn't overlook the most commonly occurring > patterns. Having human proof readers in addition is nice, too. But having > the existing rules codified in a linter program is more important. I agree that would be great, but it needs somebody to do the work. An imperfect solution would be as I described, to create a weekly summary of all changes to diagnostics, which human reviewers could check through once per week and catch these kind of errors before the release.
