[committed] libstdc++: Update/streamline Valgrind references

Message ID 20200601150649.35A0333E10@hamza.pair.com
State New
Headers show
Series
  • [committed] libstdc++: Update/streamline Valgrind references
Related show

Commit Message

Gerald Pfeifer June 1, 2020, 3:06 p.m.
Like many sites over the last year(s) valgrind.org has now moved to 
https.  While there, replace the second of two links in the same vicinity 
by a purely textual reference -- easier to maintain, and in particular
also better from a user experience perspective.

Gerald

	* doc/xml/faq.xml: Adjust Valgrind reference and remove another.
	* doc/html/faq.html: Regenerate.
---
 libstdc++-v3/doc/html/faq.html | 4 ++--
 libstdc++-v3/doc/xml/faq.xml   | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

-- 
2.26.2

Comments

Kewen.Lin via Gcc-patches June 1, 2020, 5:33 p.m. | #1
On 01/06/20 17:06 +0200, Gerald Pfeifer wrote:
>Like many sites over the last year(s) valgrind.org has now moved to

>https.  While there, replace the second of two links in the same vicinity

>by a purely textual reference -- easier to maintain, and in particular

>also better from a user experience perspective.


Thanks.

I've also committed a couple more doc improvements, as attached.
commit 258059d91bd0e27cc335312f4558e1b339a2e77d
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Mon Jun 1 16:43:01 2020 +0100

    libstdc++: Document API changes in GCC 10
    
            * doc/xml/manual/evolution.xml: Document deprecation of
            __is_nullptr_t and removal of std::allocator members.
            * doc/html/manual/api.html: Regenerate.

diff --git a/libstdc++-v3/doc/xml/manual/evolution.xml b/libstdc++-v3/doc/xml/manual/evolution.xml
index ab04c1ad272..623d53e7faf 100644
--- a/libstdc++-v3/doc/xml/manual/evolution.xml
+++ b/libstdc++-v3/doc/xml/manual/evolution.xml
@@ -955,11 +955,23 @@ now defaults to zero.
 </itemizedlist>
 </para>
 
+<para>
+  The non-standard <function>std::__is_nullptr_t</function> type trait
+  was deprecated.
+</para>
+
 <para>
   The <classname>std::packaged_task</classname> constructors taking
   an allocator argument are only defined for C++11 and C++14.
 </para>
 
+<para>
+  Several members of <classname>std::allocator</classname> were removed
+  for C++20 mode. The removed functionality has been provided by
+  <classname>std::allocator_traits</classname> since C++11 and that should
+  be used instead.
+</para>
+
 </section>
 
 </section>

commit a1ffe9b6f4d0e2dd9493c5bd669fc5a2ea24a6f9
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Mon Jun 1 16:40:13 2020 +0100

    libstdc++: Fix incorrect Docbook links
    
    The <xref> element creates the link text automatically from the link
    target, rather than using the text node child of the element. This can
    be changed by using an endterm attribute, but it's simpler to just use
    the <link> element instead.
    
            * doc/xml/manual/containers.xml: Replace <xref> with <link>.
            * doc/xml/manual/evolution.xml: Likewise.
            * doc/html/manual/api.html: Regenerate.
            * doc/html/manual/containers.html: Regenerate.

diff --git a/libstdc++-v3/doc/xml/manual/containers.xml b/libstdc++-v3/doc/xml/manual/containers.xml
index 5c9854efbdd..6d568164b47 100644
--- a/libstdc++-v3/doc/xml/manual/containers.xml
+++ b/libstdc++-v3/doc/xml/manual/containers.xml
@@ -25,8 +25,8 @@
   <section xml:id="sequences.list.size" xreflabel="list::size() is O(n)"><info><title>list::size() is O(n)</title></info>
     
    <para>
-     Yes it is, at least using the <xref linkend="manual.intro.using.abi">old
-     ABI</xref>, and that's okay.  This is a decision that we preserved
+     Yes it is, at least using the <link linkend="manual.intro.using.abi">old
+     ABI</link>, and that's okay.  This is a decision that we preserved
      when we imported SGI's STL implementation.  The following is
      quoted from <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/FAQ.html">their FAQ</link>:
    </para>
diff --git a/libstdc++-v3/doc/xml/manual/evolution.xml b/libstdc++-v3/doc/xml/manual/evolution.xml
index 1bd7bb1bb9f..ab04c1ad272 100644
--- a/libstdc++-v3/doc/xml/manual/evolution.xml
+++ b/libstdc++-v3/doc/xml/manual/evolution.xml
@@ -784,8 +784,8 @@ now defaults to zero.
 
 <para>
   Assertions to check function preconditions can be enabled by defining the
-  <xref linkend="manual.intro.using.macros"><symbol>_GLIBCXX_ASSERTIONS</symbol>
-  macro</xref>.
+  <link linkend="manual.intro.using.macros"><symbol>_GLIBCXX_ASSERTIONS</symbol>
+  macro</link>.
   The initial set of assertions are a subset of the checks enabled by
   the Debug Mode, but without the ABI changes and changes to algorithmic
   complexity that are caused by enabling the full Debug Mode.

Patch

diff --git a/libstdc++-v3/doc/html/faq.html b/libstdc++-v3/doc/html/faq.html
index 18407225d7a..967e5f5f348 100644
--- a/libstdc++-v3/doc/html/faq.html
+++ b/libstdc++-v3/doc/html/faq.html
@@ -700,7 +700,7 @@ 
     of a few dozen kilobytes on startup. This pool is used to ensure it's
     possible to throw exceptions (such as <code class="classname">bad_alloc</code>)
     even when <code class="code">malloc</code> is unable to allocate any more memory.
-    With some versions of <a class="link" href="http://valgrind.org/" target="_top"><span class="command"><strong>valgrind</strong></span></a>
+    With some versions of <a class="link" href="https://valgrind.org" target="_top"><span class="command"><strong>valgrind</strong></span></a>
     this pool will be shown as "still reachable" when the process exits, e.g.
     <code class="code">still reachable: 72,704 bytes in 1 blocks</code>.
     This memory is not a leak, because it's still in use by libstdc++,
@@ -710,7 +710,7 @@ 
     </p><p>
     In the past, a few people reported that the standard containers appear
     to leak memory when tested with memory checkers such as
-    <a class="link" href="http://valgrind.org/" target="_top"><span class="command"><strong>valgrind</strong></span></a>.
+    <span class="command"><strong>valgrind</strong></span>.
     Under some (non-default) configurations the library's allocators keep
     free memory in a
     pool for later reuse, rather than deallocating it with <code class="code">delete</code>
diff --git a/libstdc++-v3/doc/xml/faq.xml b/libstdc++-v3/doc/xml/faq.xml
index cf8684e1cea..e419d3c22a0 100644
--- a/libstdc++-v3/doc/xml/faq.xml
+++ b/libstdc++-v3/doc/xml/faq.xml
@@ -993,7 +993,7 @@ 
     of a few dozen kilobytes on startup. This pool is used to ensure it's
     possible to throw exceptions (such as <classname>bad_alloc</classname>)
     even when <code>malloc</code> is unable to allocate any more memory.
-    With some versions of <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://valgrind.org/"><command>valgrind</command></link>
+    With some versions of <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://valgrind.org"><command>valgrind</command></link>
     this pool will be shown as "still reachable" when the process exits, e.g.
     <code>still reachable: 72,704 bytes in 1 blocks</code>.
     This memory is not a leak, because it's still in use by libstdc++,
@@ -1004,7 +1004,7 @@ 
     <para>
     In the past, a few people reported that the standard containers appear
     to leak memory when tested with memory checkers such as
-    <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://valgrind.org/"><command>valgrind</command></link>.
+    <command>valgrind</command>.
     Under some (non-default) configurations the library's allocators keep
     free memory in a
     pool for later reuse, rather than deallocating it with <code>delete</code>