[Bug translation/79618] prevent missing space in multiline string literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79618 --- Comment #10 from Eric Gallager --- (In reply to Martin Sebor from comment #9) > It doesn't. -Wformat-diag runs after adjacent string literals have been > concatenated. Detecting these kinds of issues would mean enhancing the > preprocessor. ...so it sounds like we still need Roland's linter, then.
[Bug translation/79618] prevent missing space in multiline string literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79618 --- Comment #9 from Martin Sebor --- It doesn't. -Wformat-diag runs after adjacent string literals have been concatenated. Detecting these kinds of issues would mean enhancing the preprocessor.
[Bug translation/79618] prevent missing space in multiline string literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79618 Eric Gallager changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #8 from Eric Gallager --- (In reply to Roland Illig from comment #7) > Created attachment 46269 [details] > linter for string literals > > The attached linter detects: > > * multiline string literals that have the space at the start of the line > instead of the end of the line. > > (In the whole GCC source there are 800 instances of "prev" " curr" and 5500 > instances of "prev " "curr". Therefore there's a clear preference towards > having the space always at the end.) > > * multiline string literals in which neither has a space at the boundary > > * multiline string literals in which both have a space at the boundary > > These checks are not 100% perfect, they need manual inspection. But at least > they show where the possible bugs are. Martin, does -Wformat-diag detect all of these, too?
[Bug translation/79618] prevent missing space in multiline string literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79618 --- Comment #7 from Roland Illig --- Created attachment 46269 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46269=edit linter for string literals The attached linter detects: * multiline string literals that have the space at the start of the line instead of the end of the line. (In the whole GCC source there are 800 instances of "prev" " curr" and 5500 instances of "prev " "curr". Therefore there's a clear preference towards having the space always at the end.) * multiline string literals in which neither has a space at the boundary * multiline string literals in which both have a space at the boundary These checks are not 100% perfect, they need manual inspection. But at least they show where the possible bugs are.
[Bug translation/79618] prevent missing space in multiline string literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79618 Eric Gallager changed: What|Removed |Added Blocks|40883 | --- Comment #6 from Eric Gallager --- (In reply to Roland Illig from comment #5) > Agreed. > > I myself cannot remove it from the list of trivial bugs though. OK I have now. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883 [Bug 40883] [meta-bug] Translation breakage with trivial fixes
[Bug translation/79618] prevent missing space in multiline string literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79618 --- Comment #5 from Roland Illig --- Agreed. I myself cannot remove it from the list of trivial bugs though.
[Bug translation/79618] prevent missing space in multiline string literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79618 --- Comment #4 from Eric Gallager --- (In reply to David Malcolm from comment #2) > Good idea. > > We can't do it at run-time from inside the diagnostics subsystem, as the > line-breaking information is lost when the literal is compiled. > > So from an implementation POV, I believe this would have to happen inside > xgettext when it scans the sources to create .pot files, so that it can > enforce one of the variants described in comment #1 (presumably as a new > --check option to xgettext). > > In theory, we could do it with a compiler plugin that detects such strings, > but given that xgettext is scanning the strings already, presumably this > would be better implemented as an xgettext test. > > Alternatively, I guess we could implement some kind of preprocessing hack to > run when generating the .pot files, but presumably other projects would find > this useful, so it seems to make more sense as an xgettext feature. none of these solutions sound very trivial; I don't think this bug meets the "with trivial fixes" criterion for the meta-bug it's now blocking.
[Bug translation/79618] prevent missing space in multiline string literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79618 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-09-29 CC||egallager at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Eric Gallager --- (In reply to David Malcolm from comment #2) > Good idea. > So, confirmed then.
[Bug translation/79618] prevent missing space in multiline string literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79618 David Malcolm changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org --- Comment #2 from David Malcolm --- Good idea. We can't do it at run-time from inside the diagnostics subsystem, as the line-breaking information is lost when the literal is compiled. So from an implementation POV, I believe this would have to happen inside xgettext when it scans the sources to create .pot files, so that it can enforce one of the variants described in comment #1 (presumably as a new --check option to xgettext). In theory, we could do it with a compiler plugin that detects such strings, but given that xgettext is scanning the strings already, presumably this would be better implemented as an xgettext test. Alternatively, I guess we could implement some kind of preprocessing hack to run when generating the .pot files, but presumably other projects would find this useful, so it seems to make more sense as an xgettext feature.
[Bug translation/79618] prevent missing space in multiline string literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79618 --- Comment #1 from Roland Illig --- Furthermore, the space should either be always at the end of the line or always at the beginning of the next line. Currently both variants are used.
