Close a bunch of issues related to removed components as resolved

Author: timsong-cpp

xml/issue2478.xml

@@ -1,7 +1,7 @@
 <?xml version='1.0' encoding='UTF-8' standalone='no'?>
 <!DOCTYPE issue SYSTEM "lwg-issue.dtd">
 
-<issue num="2478" status="New">
+<issue num="2478" status="Resolved">
 <title>Unclear how <tt>wstring_convert</tt> uses <tt>cvtstate</tt></title>
 <section><sref ref="[depr.conversions.string]"/></section>
 <submitter>Jonathan Wakely</submitter>
@@ -18,6 +18,8 @@ to the member functions? "Otherwise it shall be left unchanged"
 implies a copy is used, but if that's really what's intended there are
 simpler ways to say so.
 </p>
+
+<note>2025-11-10 Resolved by the removal of <tt>wstring_convert</tt> via paper <paper num="P2872R3"/> in Tokyo, 2024. Status changed: New &rarr; Resolved.</note>
 </discussion>
 
 <resolution>

xml/issue2479.xml

@@ -1,7 +1,7 @@
 <?xml version='1.0' encoding='UTF-8' standalone='no'?>
 <!DOCTYPE issue SYSTEM "lwg-issue.dtd">
 
-<issue num="2479" status="New">
+<issue num="2479" status="Resolved">
 <title>Unclear how <tt>wbuffer_convert</tt> uses <tt>cvtstate</tt></title>
 <section><sref ref="[depr.conversions.buffer]"/></section>
 <submitter>Jonathan Wakely</submitter>
@@ -13,11 +13,12 @@
 How does <tt>wbuffer_convert</tt> use the <tt>cvtstate</tt> member?
 <p/>
 Is the same conversion state object used for converting both the get
-and put areas? That means a read which runs out of bytes halfway 
-through a multibyte character will leave some shift state in cvtstate, 
-which would then be used by a following write, even though the shift 
+and put areas? That means a read which runs out of bytes halfway
+through a multibyte character will leave some shift state in cvtstate,
+which would then be used by a following write, even though the shift
 state of the get area is unrelated to the put area.
 </p>
+<note>2025-11-10 Resolved by the removal of <tt>wbuffer_convert</tt> via paper <paper num="P2872R3"/> in Tokyo, 2024. Status changed: New &rarr; Resolved.</note>
 </discussion>
 
 <resolution>

xml/issue2480.xml

@@ -1,7 +1,7 @@
 <?xml version='1.0' encoding='UTF-8' standalone='no'?>
 <!DOCTYPE issue SYSTEM "lwg-issue.dtd">
 
-<issue num="2480" status="New">
+<issue num="2480" status="Resolved">
 <title>Error handling of <tt>wbuffer_convert</tt> unclear</title>
 <section><sref ref="[depr.conversions.buffer]"/></section>
 <submitter>Jonathan Wakely</submitter>
@@ -16,6 +16,7 @@ characters before a conversion error be available to the users of the
 <tt>wbuffer_convert</tt> and/or the internal <tt>streambuf</tt>, or does a conversion
 error lose information?
 </p>
+<note>2025-11-10 Resolved by the removal of <tt>wbuffer_convert</tt> via paper <paper num="P2872R3"/> in Tokyo, 2024. Status changed: New &rarr; Resolved.</note>
 </discussion>
 
 <resolution>

xml/issue2481.xml

@@ -1,7 +1,7 @@
 <?xml version='1.0' encoding='UTF-8' standalone='no'?>
 <!DOCTYPE issue SYSTEM "lwg-issue.dtd">
 
-<issue num="2481" status="New">
+<issue num="2481" status="Resolved">
 <title><tt>wstring_convert</tt> should be more precise regarding "byte-error string" etc.</title>
 <section><sref ref="[depr.conversions.string]"/></section>
 <submitter>Jonathan Wakely</submitter>
@@ -10,8 +10,8 @@
 
 <discussion>
 <p>
-Paragraph 4 of <sref ref="[depr.conversions.string]"/> introduces <tt>byte_err_string</tt> 
-as "a byte string to display on errors". What does display mean? The string is returned 
+Paragraph 4 of <sref ref="[depr.conversions.string]"/> introduces <tt>byte_err_string</tt>
+as "a byte string to display on errors". What does display mean? The string is returned
 on error, it's not displayed anywhere.
 <p/>
 Paragraph 14 says "Otherwise, if the object was constructed with a
@@ -32,6 +32,7 @@ not.
 <p/>
 All the same issues apply to the <tt>wide_err_string</tt> member.
 </p>
+<note>2025-11-10 Resolved by the removal of <tt>wstring_convert</tt> via paper <paper num="P2872R3"/> in Tokyo, 2024. Status changed: New &rarr; Resolved.</note>
 </discussion>
 
 <resolution>

xml/issue2507.xml

@@ -1,10 +1,7 @@
 <?xml version='1.0' encoding='UTF-8' standalone='no'?>
-<!DOCTYPE issue SYSTEM "lwg-issue.dtd" [ 
-  <!ENTITY hellip "&#x2026;">
-  <!ENTITY mdash  "&#x2014;">
-] >
+<!DOCTYPE issue SYSTEM "lwg-issue.dtd">
 
-<issue num="2507" status="New">
+<issue num="2507" status="Resolved">
 <title><tt>codecvt_mode</tt> should be a bitmask type</title>
 <section><sref ref="[depr.locale.stdcvt]"/></section>
 <submitter>Jonathan Wakely</submitter>
@@ -34,6 +31,7 @@ or as a minimal fix we provide an overloaded <tt>operator|</tt> that returns
 the right type.
 </p>
 
+<note>2025-11-10 Resolved by the removal of <tt>codecvt_mode</tt> via paper <paper num="P2871R3"/> in Kona, 2023. Status changed: New &rarr; Resolved.</note>
 </discussion>
 
 <resolution>

xml/issue3095.xml

@@ -1,7 +1,7 @@
 <?xml version='1.0' encoding='utf-8' standalone='no'?>
 <!DOCTYPE issue SYSTEM "lwg-issue.dtd">
 
-<issue num="3095" status="New">
+<issue num="3095" status="Resolved">
 <title><tt>strstreambuf</tt> refers to nonexistent member of <tt>fpos</tt>, <tt>fpos::offset</tt></title>
 <section><sref ref="[depr.strstreambuf.virtuals]"/></section>
 <submitter>Billy O'Neal III</submitter>
@@ -11,20 +11,22 @@
 <discussion>
 <p>
 <tt>strstreambuf</tt> refers to a nonexistent member function of <tt>fpos</tt> in the specification of the member function
-<tt>seekpos</tt>, <sref ref="[depr.strstreambuf.virtuals]"/>/18 (emphasize mine): 
+<tt>seekpos</tt>, <sref ref="[depr.strstreambuf.virtuals]"/>/18 (emphasize mine):
 </p>
 <blockquote><p>
 For a sequence to be positioned, if its next pointer is a null pointer, the positioning operation fails.
 Otherwise, the function determines <tt>newoff</tt> from <span style="color:#C80000;font-weight:bold"><tt>sp.offset()</tt></span>:
 </p></blockquote>
 <p>
-The intent is clearly to get the corresponding <tt>streamoff</tt> from the <tt>fpos</tt>, as p19 says "the resultant 
-offset <tt>newoff</tt> (of type <tt>off_type</tt>)". The mechanism to make that conversion is a normal explicit conversion, 
+The intent is clearly to get the corresponding <tt>streamoff</tt> from the <tt>fpos</tt>, as p19 says "the resultant
+offset <tt>newoff</tt> (of type <tt>off_type</tt>)". The mechanism to make that conversion is a normal explicit conversion,
 as indicated in the last row of the table in [fpos.operations].
 </p>
 
 <note>2018-06-18 after reflector discussion</note>
 <p>Priority set to 4</p>
+
+<note>2025-11-10 Resolved by the removal of <tt>strstreambuf</tt> via paper <paper num="P2867R2"/> in Tokyo, 2024. Status changed: New &rarr; Resolved.</note>
 </discussion>
 
 <resolution>

xml/issue3109.xml

@@ -1,7 +1,7 @@
 <?xml version='1.0' encoding='utf-8' standalone='no'?>
 <!DOCTYPE issue SYSTEM "lwg-issue.dtd">
 
-<issue num="3109" status="New">
+<issue num="3109" status="Resolved">
 <title><tt>strstreambuf</tt> is copyable</title>
 <section><sref ref="[depr.strstreambuf]"/></section>
 <submitter>Jonathan Wakely</submitter>
@@ -10,18 +10,20 @@
 
 <discussion>
 <p>
-In C++03 <tt>strstreambuf</tt> was not copyable, because <tt>basic_streambuf</tt> wasn't copyable. 
-In C++11 we made <tt>basic_streambuf</tt> copyable by derived classes, and <tt>strstreambuf</tt> 
-doesn't define any special members, so it (unintentionally?) became copyable, with completely 
+In C++03 <tt>strstreambuf</tt> was not copyable, because <tt>basic_streambuf</tt> wasn't copyable.
+In C++11 we made <tt>basic_streambuf</tt> copyable by derived classes, and <tt>strstreambuf</tt>
+doesn't define any special members, so it (unintentionally?) became copyable, with completely
 unspecified semantics.
 <p/>
-VC++ and libc++ make it movable not copyable, and libstdc++ still follows C++03, so it's neither 
-movable nor copyable. Making it movable seems to be the sane option, and consistent with 
+VC++ and libc++ make it movable not copyable, and libstdc++ still follows C++03, so it's neither
+movable nor copyable. Making it movable seems to be the sane option, and consistent with
 <tt>filebuf</tt> and <tt>stringbuf</tt>.
 </p>
 
 <note>2018-06-18 after reflector discussion</note>
 <p>Priority set to 4</p>
+
+<note>2025-11-10 Resolved by the removal of <tt>strstreambuf</tt> via paper <paper num="P2867R2"/> in Tokyo, 2024. Status changed: New &rarr; Resolved.</note>
 </discussion>
 
 <resolution>