Re: [wwwdocs] [PATCH 0/4] Fix various typos
In case it's helpful, I've included copies of the patches as attachments (as well as a single patch that is all of these changes merged together). --Poke On Tue, Mar 22, 2022 at 12:50 PM Pokechu22 wrote: > > While working on a separate patch, I found several typos on the website. > I have only looked within the htdocs directory, not its subdirectories. > > These are individual patches per file, since that seemed reasonable to me. > > I believe this is a small enough change that I do not need to go through > copyright assignment or DCO certification (if I had supplied a list of > files and line numbers, I suspect anyone else would have made the same > patches). I would rather remain pseudonymous. > > I've sent these patches using gmail's web interface since I have had > bad experiences setting up command-line mailing. Hopefully they have > not been mangled by it. > > --Poke 0001-branch-closing-Fix-various-typos.patch Description: Binary data 0002-codingconventions-Fix-various-typos.patch Description: Binary data 0004-contribute-Fix-various-typos.patch Description: Binary data 0003-codingrationale-Fix-various-typos.patch Description: Binary data 0001-Fix-various-typos.patch Description: Binary data
Re: [PATCH] c++: call complete_type after performing auto deduction [PR80351]
On Thu, Mar 24, 2022 at 1:53 PM Jason Merrill wrote: > Thanks! For future reference, the patch doesn't apply easily because > gmail wrapped lines; for sending patches via gmail you'll need to use > attachments. Or you can use another MUA, or git send-email. This time > I fixed the wrapping by hand, but that's a pain (especially since > there's no "try again" flag to git am). Thanks. I was vaguely aware that gmail did something wrong, but I thought that enabling plain-text mode was enough to work around it. It might be useful to add that information to the contributing webpage. I've attached a copy of the patch here in case anyone else wants to test it without dealing with the mangling. Out of curiosity, do you know if this issue could have impacted anything beyond the false warning? I had previously determined that ensure_literal_type_for_constexpr_object completes the type, so for constexpr variables it wouldn't have caused any further issues, but I discovered that regular const variables were also affected later on (and possibly other unused variables could be affected, but non-const ones would trigger the warning normally). > Also, like other DCO projects, we can't normally accept pseudonymous > contributions. But as you say in the PR, this patch is trivial enough > that I'm content to apply it myself; I want to make some adjustments anyway. Also out of curiosity, what do you want to adjust with it? I'd like to know in case it's relevant for any other patch that I submit (though there probably won't be a situation where I'm writing another patch for a while). Lastly, I'd appreciate my pseudonym being credited (at least as a co-author) in the final patch, but I get that the patch being trivial enough that no credit is needed is why it's possible for it to be submitted pseudonymously in the first place, so if there's a policy that prohibits doing so that's fine. The more important thing is that the bug gets fixed :) --Poke > Currently GCC 12 development is in the regression fixes only stage, so > I'll queue this for GCC 13. > > Thanks again, > Jason > 0001-c-call-complete_type-after-performing-auto-deduction.patch Description: Binary data
[PATCH] c++: call complete_type after performing auto deduction [PR80351]
When cp_finish_decl calls cp_apply_type_quals_to_decl on a const auto or
constexpr auto variable, the type might not be complete the first time
(this happened when auto deduces to an initializer_list).
cp_apply_type_quals_to_decl removes the const qualifier if the type is
not complete, which is appropriate for grokdeclarator, on the assumption
that the type will be complete when called by cp_finish_decl.
Tested on x86_64 Ubuntu under WSL1 by bootstrapping and comparing results
from 24d51e749570dcb85bd43d3b528f58ad6141de26 with results from this
change. As far as I can tell, this fixes Wunused-var-38.C and
Wunused-var-39.C without regressions.
(Wunused-var-37.C passed before this change.)
gcc/cp/ChangeLog:
PR c++/80351
* decl.cc (cp_finish_decl): Call complete_type after performing
auto deduction.
gcc/testsuite/ChangeLog:
PR c++/80351
* g++.dg/warn/Wunused-var-37.C: New test.
* g++.dg/warn/Wunused-var-38.C: New test.
* g++.dg/warn/Wunused-var-39.C: New test.
---
gcc/cp/decl.cc | 2 +-
gcc/testsuite/g++.dg/warn/Wunused-var-37.C | 64 ++
gcc/testsuite/g++.dg/warn/Wunused-var-38.C | 16 ++
gcc/testsuite/g++.dg/warn/Wunused-var-39.C | 16 ++
4 files changed, 97 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/warn/Wunused-var-37.C
create mode 100644 gcc/testsuite/g++.dg/warn/Wunused-var-38.C
create mode 100644 gcc/testsuite/g++.dg/warn/Wunused-var-39.C
diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
index 34d9dad9fb0..e382b8ad218 100644
--- a/gcc/cp/decl.cc
+++ b/gcc/cp/decl.cc
@@ -8098,7 +8098,7 @@ cp_finish_decl (tree decl, tree init, bool
init_const_expr_p,
TREE_TYPE (decl) = error_mark_node;
return;
}
- cp_apply_type_quals_to_decl (cp_type_quals (type), decl);
+ cp_apply_type_quals_to_decl (cp_type_quals (complete_type (type)), decl);
}
if (ensure_literal_type_for_constexpr_object (decl) == error_mark_node)
diff --git a/gcc/testsuite/g++.dg/warn/Wunused-var-37.C
b/gcc/testsuite/g++.dg/warn/Wunused-var-37.C
new file mode 100644
index 000..54e76ac4e11
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Wunused-var-37.C
@@ -0,0 +1,64 @@
+// Tangentially to PR c++/80351
+// { dg-do compile { target c++17 } }
+// { dg-options "-Wunused-variable" }
+#include
+
+// Warnings:
+static int int_s1 = 0; // { dg-warning "defined but not used" }
+static int int_s2 = 0; // { dg-warning "defined but not used" }
+inline static intint_is1 = 0; // { dg-warning "defined but not used" }
+inline static intint_is2 = 0; // { dg-warning "defined but not used" }
+// No warnings:
+constexpr static int int_cs1 = 0; // { dg-bogus "defined but not used" }
+constexpr static int int_cs2 = 0; // { dg-bogus "defined but not used" }
+int int_1 = 0; // { dg-bogus "defined but not used" }
+int int_2 = 0; // { dg-bogus "defined but not used" }
+inline int int_i1 = 0; // { dg-bogus "defined but not used" }
+inline int int_i2 = 0; // { dg-bogus "defined but not used" }
+constexpr intint_c1 = 0; // { dg-bogus "defined but not used" }
+constexpr intint_c2 = 0; // { dg-bogus "defined but not used" }
+
+// Warnings:
+static auto int_as1 = 0; // { dg-warning "defined but not used" }
+static auto int_as2 = 0; // { dg-warning "defined but not used" }
+inline static autoint_ais1 = 0; // { dg-warning "defined but not used" }
+inline static autoint_ais2 = 0; // { dg-warning "defined but not used" }
+// No warnings:
+constexpr static auto int_acs1 = 0; // { dg-bogus "defined but not used" }
+constexpr static auto int_acs2 = 0; // { dg-bogus "defined but not used" }
+auto int_a1 = 0; // { dg-bogus "defined but not used" }
+auto int_a2 = 0; // { dg-bogus "defined but not used" }
+inline auto int_ai1 = 0; // { dg-bogus "defined but not used" }
+inline auto int_ai2 = 0; // { dg-bogus "defined but not used" }
+constexpr autoint_ac1 = 0; // { dg-bogus "defined but not used" }
+constexpr autoint_ac2 = 0; // { dg-bogus "defined but not used" }
+
+// Warnings:
+static std::initializer_list il_s1 = {0, 1}; // {
dg-warning "defined but not used" }
+static std::initializer_list il_s2 = {0, 1}; // {
dg-warning "defined but not used" }
+inline static std::initializer_listil_is1 = {0, 1}; // {
dg-warning "defined but not used" }
+inline static std::initializer_listil_is2 = {0, 1}; // {
dg-warning "defined but not used" }
+// No warnings:
+constexpr static std::initializer_list il_cs1 = {0, 1}; // {
dg-bogus "defined but not used" }
+constexpr static std::initializer_list il_cs2 = {0, 1}; // {
dg-bogus "defined but not used" }
+std::initializer_list il_1 = {0, 1}; // {
dg-bogus "defined but not used" }
+std::initializer_list il_2 = {0, 1}; //
[wwwdocs] [PATCH 4/4] contribute: Fix various typos
--- htdocs/contribute.html | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/htdocs/contribute.html b/htdocs/contribute.html index c0223738..2d04b1f0 100644 --- a/htdocs/contribute.html +++ b/htdocs/contribute.html @@ -267,7 +267,7 @@ characters. The classifier identifies the type of contribution, for example a patch, an RFC (request for comments) or a committed patch (where -approval is not necessary. The classifier should be written in upper +approval is not necessary). The classifier should be written in upper case and surrounded with square brackets. This is the only component of the e-mail subject line that will not appear in the commit itself. The classifier may optionally contain a version number (vN) and @@ -297,7 +297,7 @@ followed by a colon. For example, Some large components may be subdivided into sub-components. If -the subcomponent name is not disctinct in its own right, you can use the +the subcomponent name is not distinct in its own right, you can use the form component/sub-component:. Series identifier @@ -327,7 +327,7 @@ the commit message so that Bugzilla will correctly notice the commit. If your patch relates to two bugs, then write [PRn, PRm]. For multiple bugs, just cite the most relevant one in the summary and use an -elipsis instead of the second, or subsequent PR numbers; list all the +ellipsis instead of the second, or subsequent PR numbers; list all the related PRs in the body of the commit message in the normal way. It is not necessary to cite bugs that are closed as duplicates of @@ -352,7 +352,7 @@ together. If you submit a new version of a patch series, then you should start a new email thread (don't reply to the original patch series). This avoids email threads becoming confused between discussions of the -first and subsequent revisions of the patch set. Your cover leter +first and subsequent revisions of the patch set. Your cover letter (0/nnn) should explain clearly what has been changed between the two patch series. Also state if some of the patches are unchanged between revisions; this saves maintainers having to re-review the -- 2.25.1
[wwwdocs] [PATCH 3/4] codingrationale: Fix various typos
--- htdocs/codingrationale.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/htdocs/codingrationale.html b/htdocs/codingrationale.html index 0b44f1da..f523f3e2 100644 --- a/htdocs/codingrationale.html +++ b/htdocs/codingrationale.html @@ -18,7 +18,7 @@ Inlining functions has a potential cost in object size, -working set size, compile time, and debuggablity. +working set size, compile time, and debuggability. These costs should not be borne without some evidence that the inlining pays for itself. @@ -155,7 +155,7 @@ Wide use of implicit conversion can cause some very surprising results. C++03 has no explicit conversion operators, -and hence using them cannot avoid suprises. +and hence using them cannot avoid surprises. Wait for C++11. -- 2.25.1
[wwwdocs] [PATCH 2/4] codingconventions: Fix various typos
--- htdocs/codingconventions.html | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/htdocs/codingconventions.html b/htdocs/codingconventions.html index e4d30510..86b63b89 100644 --- a/htdocs/codingconventions.html +++ b/htdocs/codingconventions.html @@ -141,7 +141,7 @@ a large batch of changes. supported formats: a/b/c/ChangeLog, a/b/c/ChangeLog:, a/b/c/ (where ChangeLog file lives in the folder), \ta/b/c/ and a/b/c pr_entry - bug report reference example: \tPR component/12345 -changelog_file - a modified file mentined in a ChangeLog: +changelog_file - a modified file mentioned in a ChangeLog: supported formats: \t* a/b/c/file.c:, \t* a/b/c/file.c (function):, \t* a/b/c/file1.c, a/b/c/file2.c: changelog_file_comment - line that follows a changelog_file with description of changes in the file; must start with \t @@ -153,7 +153,7 @@ a large batch of changes. Format rules -git_description - optional; ends right before one of the other compoments is found +git_description - optional; ends right before one of the other components is found committer_timestamp - optional; when found before a changelog_file, then it is added to each changelog entry additional_author - optional @@ -1022,7 +1022,7 @@ intended to last a long time. Complex hierarchies are to be avoided. Take special care with multiple inheritance. -On the rare occasion that using mulitple inheritance is indeed useful, +On the rare occasion that using multiple inheritance is indeed useful, prepare design rationales in advance, and take special care to make documentation of the entire hierarchy clear. (In particular, multiple inheritance can be an acceptable way of combining -- 2.25.1
[wwwdocs] [PATCH 1/4] branch-closing: Fix various typos
--- htdocs/branch-closing.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/htdocs/branch-closing.html b/htdocs/branch-closing.html index c36ad1ab..15fb90e3 100644 --- a/htdocs/branch-closing.html +++ b/htdocs/branch-closing.html @@ -54,7 +54,7 @@ is listed in "Known to work" or "Known to fail" as applicable. If the bug is a regression that is not fixed on all subsequent release branches and on trunk then it needs to remain open. Remove the version number of the branch being closed from the summary (for -example, change "[7/8 Regression]" to "[8 Regression]". If the +example, change "[7/8 Regression]" to "[8 Regression]"). If the milestone is not set, or is set to a version from the branch being closed, set it to the version number of the next release from the next oldest release branch. -- 2.25.1
[wwwdocs] [PATCH 0/4] Fix various typos
While working on a separate patch, I found several typos on the website. I have only looked within the htdocs directory, not its subdirectories. These are individual patches per file, since that seemed reasonable to me. I believe this is a small enough change that I do not need to go through copyright assignment or DCO certification (if I had supplied a list of files and line numbers, I suspect anyone else would have made the same patches). I would rather remain pseudonymous. I've sent these patches using gmail's web interface since I have had bad experiences setting up command-line mailing. Hopefully they have not been mangled by it. --Poke
