Rebase tests

tests/github/immersive-web/depth-sensing/index.html

@@ -1137,6 +1137,7 @@ <h3 class="heading settled" data-level="3.2" id="xr-cpu-depth-info-section"><spa
   console<c- p>.</c->log<c- p>(</c-><c- u>"Depth at normalized view coordinates (0.25, 0.75) is:"</c-><c- p>,</c->
     depthInMeters<c- p>);</c->
 <c- p>}</c->
+
 </pre>
    </div>
    <h3 class="heading settled" data-level="3.3" id="xr-gpu-depth-info-section"><span class="secno">3.3. </span><span class="content">XRWebGLDepthInformation</span><a class="self-link" href="#xr-gpu-depth-info-section"></a></h3>
@@ -1255,6 +1256,7 @@ <h3 class="heading settled" data-level="3.3" id="xr-gpu-depth-info-section"><spa
 
   <c- c1>// ...</c->
 <c- p>}</c->
+
 </pre>
     <p>The fragment shader that makes use of the depth buffer can be for example:</p>
 <pre class="highlight"><c- k>precision</c-> <c- k>mediump</c-> <c- b>float</c-><c- p>;</c->
@@ -1279,6 +1281,7 @@ <h3 class="heading settled" data-level="3.3" id="xr-gpu-depth-info-section"><spa
 
   gl_FragColor <c- o>=</c-> <c- p>...;</c->
 <c- p>}</c->
+
 </pre>
    </div>
    <h2 class="heading settled" data-level="4" id="results-interpretation"><span class="secno">4. </span><span class="content">Interpreting the results</span><a class="self-link" href="#results-interpretation"></a></h2>

tests/github/jfbastien/papers/source/P0528r1.html

@@ -2165,7 +2165,8 @@ <h2 class="heading settled" data-level="2" id="word"><span class="secno">2. </sp
 implementation-defined value. A compatible implementation-defined value shall be
 used for compare-and-exchange operations' copy of the <code class="highlight"><c- n>expected</c-></code> value.</p>
      <p>As a consequence, the following code is guaranteed to avoid spurious failure:</p>
-<pre class="highlight"><c- k>struct</c-> <c- nc>padded</c-> <c- p>{</c->
+<pre class="highlight">
+<c- k>struct</c-> <c- nc>padded</c-> <c- p>{</c->
   <c- b>char</c-> <c- n>c</c-> <c- o>=</c-> <c- mh>0x42</c-><c- p>;</c->
   <c- c1>// Padding here.</c->
   <c- b>unsigned</c-> <c- n>i</c-> <c- o>=</c-> <c- mh>0xC0DEFEFE</c-><c- p>;</c->
@@ -2176,6 +2177,7 @@ <h2 class="heading settled" data-level="2" id="word"><span class="secno">2. </sp
   <c- n>padded</c-> <c- n>expected</c-><c- p>,</c-> <c- n>desired</c-> <c- p>{</c-> <c- mi>0</c-><c- p>,</c-> <c- mi>0</c-> <c- p>};</c->
   <c- k>return</c-> <c- n>pad</c-><c- p>.</c-><c- n>compare_exchange_strong</c-><c- p>(</c-><c- n>expected</c-><c- p>,</c-> <c- n>desired</c-><c- p>);</c->
 <c- p>}</c->
+
 </pre>
      <p>[<em>Note:</em></p>
      <p>Types which contain bits that sometimes participate in the object’s
@@ -2217,26 +2219,31 @@ <h2 class="heading settled" data-level="2" id="word"><span class="secno">2. </sp
   <c- n>memcpy</c-><c- p>(</c-><c- k>this</c-><c- p>,</c-> <c- o>&amp;</c-><c- n>desired</c-><c- p>,</c-> <c- k>sizeof</c-><c- p>(</c-><c- o>*</c-><c- k>this</c-><c- p>));</c->
 <c- k>else</c->
    <c- n>memcpy</c-><c- p>(</c-><c- n>expected</c-><c- p>,</c-> <c- k>this</c-><c- p>,</c-> <c- k>sizeof</c-><c- p>(</c-><c- o>*</c-><c- k>this</c-><c- p>));</c->
+
 </pre>
     <p>—<em>end note</em>]</p>
     <p>[<em>Example:</em></p>
     <p>The expected use of the compare-and-exchange operations is as follows. The
   compare-and-exchange operations will update <code class="highlight"><c- n>expected</c-></code> when another iteration
   of the loop is needed.</p>
-<pre class="highlight"><c- n>expected</c-> <c- o>=</c-> <c- n>current</c-><c- p>.</c-><c- n>load</c-><c- p>();</c->
+<pre class="highlight">
+<c- n>expected</c-> <c- o>=</c-> <c- n>current</c-><c- p>.</c-><c- n>load</c-><c- p>();</c->
 <c- k>do</c-> <c- p>{</c->
   <c- n>desired</c-> <c- o>=</c-> <c- n>function</c-><c- p>(</c-><c- n>expected</c-><c- p>);</c->
 <c- p>}</c-> <c- k>while</c-> <c- p>(</c-><c- o>!</c-><c- n>current</c-><c- p>.</c-><c- n>compare_exchange_weak</c-><c- p>(</c-><c- n>expected</c-><c- p>,</c-> <c- n>desired</c-><c- p>));</c->
+
 </pre>
     <p>—<em>end example</em>]</p>
     <p>[<em>Example:</em></p>
     <p>Because the expected value is updated only on failure, code releasing the
   memory containing the <code class="highlight"><c- n>expected</c-></code> value on success will work. E.g. list head
   insertion will act atomically and would not introduce a data race in the
   following code:</p>
-<pre class="highlight"><c- k>do</c-> <c- p>{</c->
+<pre class="highlight">
+<c- k>do</c-> <c- p>{</c->
   <c- n>p</c-><c- o>-></c-><c- n>next</c-> <c- o>=</c-> <c- n>head</c-><c- p>;</c-> <c- c1>// make new list node point to the current head</c->
 <c- p>}</c-> <c- k>while</c-> <c- p>(</c-><c- o>!</c-><c- n>head</c-><c- p>.</c-><c- n>compare_exchange_weak</c-><c- p>(</c-><c- n>p</c-><c- o>-></c-><c- n>next</c-><c- p>,</c-> <c- n>p</c-><c- p>));</c-> <c- c1>// try to insert</c->
+
 </pre>
     <p>—<em>end example</em>]</p>
     <p>Implementations should ensure that weak compare-and-exchange operations do not

tests/github/jfbastien/papers/source/P0528r2.html

@@ -2200,26 +2200,31 @@ <h2 class="heading settled" data-level="2" id="word"><span class="secno">2. </sp
   <c- n>memcpy</c-><c- p>(</c-><c- k>this</c-><c- p>,</c-> <c- o>&amp;</c-><c- n>desired</c-><c- p>,</c-> <c- k>sizeof</c-><c- p>(</c-><c- o>*</c-><c- k>this</c-><c- p>));</c->
 <c- k>else</c->
    <c- n>memcpy</c-><c- p>(</c-><c- n>expected</c-><c- p>,</c-> <c- k>this</c-><c- p>,</c-> <c- k>sizeof</c-><c- p>(</c-><c- o>*</c-><c- k>this</c-><c- p>));</c->
+
 </pre>
     <p>—<em>end note</em>]</p>
     <p>[<em>Example:</em></p>
     <p>The expected use of the compare-and-exchange operations is as follows. The
   compare-and-exchange operations will update <code class="highlight"><c- n>expected</c-></code> when another iteration
   of the loop is needed.</p>
-<pre class="highlight"><c- n>expected</c-> <c- o>=</c-> <c- n>current</c-><c- p>.</c-><c- n>load</c-><c- p>();</c->
+<pre class="highlight">
+<c- n>expected</c-> <c- o>=</c-> <c- n>current</c-><c- p>.</c-><c- n>load</c-><c- p>();</c->
 <c- k>do</c-> <c- p>{</c->
   <c- n>desired</c-> <c- o>=</c-> <c- n>function</c-><c- p>(</c-><c- n>expected</c-><c- p>);</c->
 <c- p>}</c-> <c- k>while</c-> <c- p>(</c-><c- o>!</c-><c- n>current</c-><c- p>.</c-><c- n>compare_exchange_weak</c-><c- p>(</c-><c- n>expected</c-><c- p>,</c-> <c- n>desired</c-><c- p>));</c->
+
 </pre>
     <p>—<em>end example</em>]</p>
     <p>[<em>Example:</em></p>
     <p>Because the expected value is updated only on failure, code releasing the
   memory containing the <code class="highlight"><c- n>expected</c-></code> value on success will work. E.g. list head
   insertion will act atomically and would not introduce a data race in the
   following code:</p>
-<pre class="highlight"><c- k>do</c-> <c- p>{</c->
+<pre class="highlight">
+<c- k>do</c-> <c- p>{</c->
   <c- n>p</c-><c- o>-></c-><c- n>next</c-> <c- o>=</c-> <c- n>head</c-><c- p>;</c-> <c- c1>// make new list node point to the current head</c->
 <c- p>}</c-> <c- k>while</c-> <c- p>(</c-><c- o>!</c-><c- n>head</c-><c- p>.</c-><c- n>compare_exchange_weak</c-><c- p>(</c-><c- n>p</c-><c- o>-></c-><c- n>next</c-><c- p>,</c-> <c- n>p</c-><c- p>));</c-> <c- c1>// try to insert</c->
+
 </pre>
     <p>—<em>end example</em>]</p>
     <p>Implementations should ensure that weak compare-and-exchange operations do not
@@ -2258,7 +2263,8 @@ <h2 class="heading settled" data-level="2" id="word"><span class="secno">2. </sp
      <p>Compare-and-exchange acts on an object’s value representation, ensuring that
   padding bits which never participate in the object’s representation are ignored.</p>
      <p>As a consequence, the following code is guaranteed to avoid spurious failure:</p>
-<pre class="highlight"><c- k>struct</c-> <c- nc>padded</c-> <c- p>{</c->
+<pre class="highlight">
+<c- k>struct</c-> <c- nc>padded</c-> <c- p>{</c->
   <c- b>char</c-> <c- n>clank</c-> <c- o>=</c-> <c- mh>0x42</c-><c- p>;</c->
   <c- c1>// Padding here.</c->
   <c- b>unsigned</c-> <c- n>biff</c-> <c- o>=</c-> <c- mh>0xC0DEFEFE</c-><c- p>;</c->
@@ -2269,6 +2275,7 @@ <h2 class="heading settled" data-level="2" id="word"><span class="secno">2. </sp
   <c- n>padded</c-> <c- n>expected</c-><c- p>,</c-> <c- n>desired</c-> <c- p>{</c-> <c- mi>0</c-><c- p>,</c-> <c- mi>0</c-> <c- p>};</c->
   <c- k>return</c-> <c- n>pad</c-><c- p>.</c-><c- n>compare_exchange_strong</c-><c- p>(</c-><c- n>expected</c-><c- p>,</c-> <c- n>desired</c-><c- p>);</c->
 <c- p>}</c->
+
 </pre>
      <p>—<em>end note</em>]</p>
      <p>[<em>Note:</em></p>

tests/github/jfbastien/papers/source/P0907r0.html

@@ -2222,18 +2222,21 @@ <h2 class="heading settled" data-level="2" id="word"><span class="secno">2. </sp
 produce an exception and in which the range of values representable by an <code class="highlight"><c- b>int</c-></code> is <code class="highlight"><c- p>[</c-><c- mi>-32768</c-><c- p>,</c-> <c- o>+</c-><c- mi>32767</c-><c- p>]</c-></code>, the implementation cannot rewrite this expression as</del>
     </p>
     <del>
-<pre class="highlight">  <c- n>a</c-> <c- o>=</c-> <c- p>((</c-><c- n>a</c-> <c- o>+</c-> <c- n>b</c-><c- p>)</c-> <c- o>+</c-> <c- mi>32765</c-><c- p>);</c->
+<pre class="highlight">
+  <c- n>a</c-> <c- o>=</c-> <c- p>((</c-><c- n>a</c-> <c- o>+</c-> <c- n>b</c-><c- p>)</c-> <c- o>+</c-> <c- mi>32765</c-><c- p>);</c->
 </pre>
     </del>
     <del>since if the values for <code class="highlight"><c- n>a</c-></code> and <code class="highlight"><c- n>b</c-></code> were, respectively, -32754 and -15, the sum <code class="highlight"><c- n>a</c-> <c- o>+</c-> <c- n>b</c-></code> would produce an exception while the original expression would not; nor
 can the expression be rewritten either as</del>
     <del>
-<pre class="highlight">  <c- n>a</c-> <c- o>=</c-> <c- p>((</c-><c- n>a</c-> <c- o>+</c-> <c- mi>32765</c-><c- p>)</c-> <c- o>+</c-> <c- n>b</c-><c- p>);</c->
+<pre class="highlight">
+  <c- n>a</c-> <c- o>=</c-> <c- p>((</c-><c- n>a</c-> <c- o>+</c-> <c- mi>32765</c-><c- p>)</c-> <c- o>+</c-> <c- n>b</c-><c- p>);</c->
 </pre>
     </del>
     <del>or</del>
     <del>
-<pre class="highlight">  <c- n>a</c-> <c- o>=</c-> <c- p>(</c-><c- n>a</c-> <c- o>+</c-> <c- p>(</c-><c- n>b</c-> <c- o>+</c-> <c- mi>32765</c-><c- p>));</c->
+<pre class="highlight">
+  <c- n>a</c-> <c- o>=</c-> <c- p>(</c-><c- n>a</c-> <c- o>+</c-> <c- p>(</c-><c- n>b</c-> <c- o>+</c-> <c- mi>32765</c-><c- p>));</c->
 </pre>
     </del>
     <del>since the values for <code class="highlight"><c- n>a</c-></code> and <code class="highlight"><c- n>b</c-></code> might have been, respectively, 4 and -8 or -17

tests/github/jfbastien/papers/source/P0908r0.html

@@ -2122,7 +2122,8 @@ <h2 class="no-num no-toc no-ref" id="contents">Table of Contents</h2>
 classes (and, conditionally, other classes) in C++, calculates the layout
 offset of a member within a class. <code class="highlight"><c- n>offsetof</c-></code> is useful for calculating an
 object pointer given a pointer to one of its members:</p>
-<pre class="highlight"><c- k>struct</c-> <c- nc>link</c-> <c- p>{</c->
+<pre class="highlight">
+<c- k>struct</c-> <c- nc>link</c-> <c- p>{</c->
   <c- p>...</c->
 <c- p>};</c->
 
@@ -2136,23 +2137,27 @@ <h2 class="no-num no-toc no-ref" id="contents">Table of Contents</h2>
   <c- b>size_t</c-> <c- n>l_offset</c-> <c- o>=</c-> <c- n>offsetof</c-><c- p>(</c-><c- n>container</c-><c- p>,</c-> <c- n>l</c-><c- p>);</c->
   <c- k>return</c-> <c- k>reinterpret_cast</c-><c- o>&lt;</c-><c- n>container</c-><c- o>*></c-><c- p>(</c-><c- n>x_address</c-> <c- o>-</c-> <c- n>l_offset</c-><c- p>);</c->
 <c- p>}</c->
+
 </pre>
    <p>This pattern is used in several implementations of intrusive containers, such
 as Linux kernel linked lists (<code class="highlight"><c- k>struct</c-> <c- nc>list_head</c-></code>).</p>
    <p>Unfortunately, although <code class="highlight"><c- n>offsetof</c-></code> works for some unusual
 member-designators, it does not work for pointers to members. This won’t
 compile:</p>
-<pre class="highlight"><c- k>template</c-> <c- o>&lt;</c-><c- k>typename</c-> <c- nc>Container</c-><c- p>,</c-> <c- k>typename</c-> <c- nc>Link</c-><c- p>,</c-> <c- n>Link</c-> <c- p>(</c-><c- n>Container</c-><c- o>::*</c-> <c- n>member</c-><c- p>)</c-><c- o>></c->
+<pre class="highlight">
+<c- k>template</c-> <c- o>&lt;</c-><c- k>typename</c-> <c- nc>Container</c-><c- p>,</c-> <c- k>typename</c-> <c- nc>Link</c-><c- p>,</c-> <c- n>Link</c-> <c- p>(</c-><c- n>Container</c-><c- o>::*</c-> <c- n>member</c-><c- p>)</c-><c- o>></c->
 <c- n>Container</c-><c- o>*</c-> <c- n>generic_container_from_link</c-><c- p>(</c-><c- n>Link</c-><c- o>*</c-> <c- n>x</c-><c- p>)</c-> <c- p>{</c->
   <c- b>uintptr_t</c-> <c- n>x_address</c-> <c- o>=</c-> <c- k>reinterpret_cast</c-><c- o>&lt;</c-><c- b>uintptr_t</c-><c- o>></c-><c- p>(</c-><c- n>x</c-><c- p>);</c->
   <c- b>size_t</c-> <c- n>link_offset</c-> <c- o>=</c-> <c- n>offsetof</c-><c- p>(</c-><c- n>Container</c-><c- p>,</c-> <c- n>member</c-><c- p>);</c-> <c- c1>// error!</c->
   <c- k>return</c-> <c- k>reinterpret_cast</c-><c- o>&lt;</c-><c- n>Container</c-><c- o>*></c-><c- p>(</c-><c- n>x_address</c-> <c- o>-</c-> <c- n>link_offset</c-><c- p>);</c->
 <c- p>}</c->
+
 </pre>
    <p>Programmers currently compute pointer-to-member offsets using <code class="highlight"><c- k>nullptr</c-></code> casts
 (i.e., the incorrect folk implementation of <code class="highlight"><c- n>offsetof</c-></code>, which invokes
 undefined behavior), or by jumping through other hoops:</p>
-<pre class="highlight"><c- k>template</c-> <c- o>&lt;</c-><c- k>typename</c-> <c- nc>Container</c-><c- p>,</c-> <c- k>typename</c-> <c- nc>Link</c-><c- p>,</c-> <c- n>Link</c-> <c- p>(</c-><c- n>Container</c-><c- o>::*</c-> <c- n>member</c-><c- p>)</c-><c- o>></c->
+<pre class="highlight">
+<c- k>template</c-> <c- o>&lt;</c-><c- k>typename</c-> <c- nc>Container</c-><c- p>,</c-> <c- k>typename</c-> <c- nc>Link</c-><c- p>,</c-> <c- n>Link</c-> <c- p>(</c-><c- n>Container</c-><c- o>::*</c-> <c- n>member</c-><c- p>)</c-><c- o>></c->
 <c- n>Container</c-><c- o>*</c-> <c- n>generic_container_from_link</c-><c- p>(</c-><c- n>Link</c-><c- o>*</c-> <c- n>x</c-><c- p>)</c-> <c- p>{</c->
   <c- p>...</c->
   <c- k>alignas</c-><c- p>(</c-><c- n>Container</c-><c- p>)</c-> <c- b>char</c-> <c- n>container_space</c-><c- p>[</c-><c- k>sizeof</c-><c- p>(</c-><c- n>Container</c-><c- p>)]</c-> <c- o>=</c-> <c- p>{};</c->
@@ -2161,23 +2166,28 @@ <h2 class="no-num no-toc no-ref" id="contents">Table of Contents</h2>
       <c- o>-</c-> <c- k>reinterpret_cast</c-><c- o>&lt;</c-><c- b>uintptr_t</c-><c- o>></c-><c- p>(</c-><c- n>fake_container</c-><c- p>);</c->
   <c- p>...</c->
 <c- p>}</c->
+
 </pre>
    <p><code class="highlight"><c- n>offsetof</c-></code> with pointer-to-member member-designators should simply work.
 Modern compilers implement <code class="highlight"><c- n>offsetof</c-></code> using an extension (<code class="highlight"><c- n>__builtin_offsetof</c-></code> in GCC and LLVM), so implementation need not require library changes. To avoid
 ambiguity, we propose this syntax:</p>
-<pre class="highlight"><c- b>size_t</c-> <c- n>link_offset</c-> <c- o>=</c-> <c- n>offsetof</c-><c- p>(</c-><c- n>Container</c-><c- p>,</c-> <c- p>.</c-><c- o>*</c-><c- n>member</c-><c- p>);</c->
+<pre class="highlight">
+<c- b>size_t</c-> <c- n>link_offset</c-> <c- o>=</c-> <c- n>offsetof</c-><c- p>(</c-><c- n>Container</c-><c- p>,</c-> <c- p>.</c-><c- o>*</c-><c- n>member</c-><c- p>);</c->
+
 </pre>
    <h2 class="heading settled" data-level="1" id="qq"><span class="secno">1. </span><span class="content">Questions</span><a class="self-link" href="#qq"></a></h2>
    <p>Must a pointer-to-member expression in an <code class="highlight"><c- n>offsetof</c-></code> member-designator be a
 constant expression (such as a template argument)? The C standard requires
 that “the expression <code class="highlight"><c- o>&amp;</c-><c- p>(</c-><c- n>t</c-><c- p>.</c-><c- n>member</c-><c- o>-</c-><c- n>designator</c-><c- p>)</c-></code> evaluates to an address
 constant,” which might make this code illegal:</p>
-<pre class="highlight"><c- k>struct</c-> <c- nc>container</c-> <c- p>{</c->
+<pre class="highlight">
+<c- k>struct</c-> <c- nc>container</c-> <c- p>{</c->
   <c- b>char</c-> <c- n>array</c-><c- p>[</c-><c- mi>200</c-><c- p>];</c->
 <c- p>};</c->
 
 <c- b>int</c-> <c- n>index</c-> <c- o>=</c-> <c- d>/* dynamic value */</c-><c- p>;</c->
 <c- b>size_t</c-> <c- n>offset</c-> <c- o>=</c-> <c- n>offsetof</c-><c- p>(</c-><c- n>container</c-><c- p>,</c-> <c- n>array</c-><c- p>[</c-><c- n>index</c-><c- p>]);</c->  <c- c1>// questionable</c->
+
 </pre>
    <p>But since several current compilers accept dynamic array indexes, the proposed
 wording allows any pointer to member.</p>