[libcxx][docs] Remove completed issues from TODO.TXT

[jloser]

Summary

Remove tasks listed that refer to papers or issues that are marked complete in
libcxx/docs/Status/Cxx17Papers.csv or libcxx/docs/Status/Cxx17Issues.csv

[• Quuxplusone]

FWIW, I'm OK with this. (Does anyone care about TODO.TXT anyway?) I spot-checked some of the removals (US 25, US 60, US 185 rejected, Late 36, Late 37) and found that libc++ implemented them correctly AFAICT.
@ldionne should be the sole arbiter here.

[Mordante]

IMO we should remove this file, if there's relevant information I'd rather have is in an .rst file and visible on the website.
But I agree to let @ldionne decide.

[ldionne]

I agree that we should eventually remove this file, however I'd rather do it gradually while making sure that the stuff it mentions has been addressed properly.

I'm fine with this once the std::allocator thing has been addressed (LWG 2447). Until then, requesting changes.

Regardless, thanks a lot for the cleanup.

libcxx/TODO.TXT

75

I am not seeing a static assertion in allocator for LWG 2447.

[jloser]

In D108856#2972654, @ldionne wrote:

I agree that we should eventually remove this file, however I'd rather do it gradually while making sure that the stuff it mentions has been addressed properly.

I'm fine with this once the std::allocator thing has been addressed (LWG 2447). Until then, requesting changes.

Regardless, thanks a lot for the cleanup.

LWG 2447 is marked complete according to the issues docs. I agree with you though that it doesn't seem to be implemented. I'll keep the LWG 2447 note in this TODO.txt, but I think we should also unmark it as Complete in the docs linked previously. Want me to do that in this diff or a separate patch?

[jloser]

Bring back LWG 2447 note in the TODO.txt

[ldionne]

In D108856#2973329, @jloser wrote:

In D108856#2972654, @ldionne wrote:

I agree that we should eventually remove this file, however I'd rather do it gradually while making sure that the stuff it mentions has been addressed properly.

I'm fine with this once the std::allocator thing has been addressed (LWG 2447). Until then, requesting changes.

Regardless, thanks a lot for the cleanup.

LWG 2447 is marked complete according to the issues docs. I agree with you though that it doesn't seem to be implemented. I'll keep the LWG 2447 note in this TODO.txt, but I think we should also unmark it as Complete in the docs linked previously. Want me to do that in this diff or a separate patch?

Let's ship this, but you can open a separate patch so we can look at what needs to be done for LWG 2447. Thanks!

libcxx/TODO.TXT

 ====================
 * future should use <atomic> for synchronization.
 
 Test Suite Tasks
 ================
 * Improve the quality and portability of the locale test data.
 * Convert failure tests to use Clang Verify.
 
-Filesystem Tasks
-================
-* P0492r2 - Implement National body comments for Filesystem
-    * INCOMPLETE - US 25: has_filename() is equivalent to just !empty()
-    * INCOMPLETE - US 31: Everything is defined in terms of one implicit host system
-    * INCOMPLETE - US 32: Meaning of 27.10.2.1 unclear
-    * INCOMPLETE - US 33: Definition of canonical path problematic
-    * INCOMPLETE - US 34: Are there attributes of a file that are not an aspect of the file system?
-    * INCOMPLETE - US 35: What synchronization is required to avoid a file system race?
-    * INCOMPLETE - US 36: Symbolic links themselves are attached to a directory via (hard) links
-    * INCOMPLETE - US 37: The term “redundant current directory (dot) elements” is not defined
-    * INCOMPLETE - US 38: Duplicates §17.3.16
-    * INCOMPLETE - US 39: Remove note: Dot and dot-dot are not directories
-    * INCOMPLETE - US 40: Not all directories have a parent.
-    * INCOMPLETE - US 41: The term “parent directory” for a (non-directory) file is unusual
-    * INCOMPLETE - US 42: Pathname resolution does not always resolve a symlink
-    * INCOMPLETE - US 43: Concerns about encoded character types
-    * INCOMPLETE - US 44: Definition of path in terms of a string requires leaky abstraction
-    * INCOMPLETE - US 45: Generic format portability compromised by unspecified root-name
-    * INCOMPLETE - US 46: filename can be empty so productions for relative-path are redundant
-    * INCOMPLETE - US 47: “.” and “..” already match the name production
-    * INCOMPLETE - US 48: Multiple separators are often meaningful in a root-name
-    * INCOMPLETE - US 49: What does “method of conversion method” mean?
-    * INCOMPLETE - US 50: 27.10.8.1 ¶ 1.4 largely redundant with ¶ 1.3
-    * INCOMPLETE - US 51: Failing to add / when appending empty string prevents useful apps
-    * INCOMPLETE - US 52: remove_filename() postcondition is not by itself a definition
-    * INCOMPLETE - US 53: remove_filename()'s name does not correspond to its behavior
-    * INCOMPLETE - US 54: remove_filename() is broken
-    * INCOMPLETE - US 55: replace_extension()'s use of path as parameter is inappropriate
-    * INCOMPLETE - US 56: Remove replace_extension()'s conditional addition of period
-    * INCOMPLETE - US 57: On Windows, absolute paths will sort in among relative paths
-    * INCOMPLETE - US 58: parent_path() behavior for root paths is useless
-    * INCOMPLETE - US 59: filename() returning path for single path components is bizarre
-    * INCOMPLETE - US 60: path("/foo/").filename()==path(".") is surprising
-    * INCOMPLETE - US 61: Leading dots in filename() should not begin an extension
-    * INCOMPLETE - US 62: It is important that stem()+extension()==filename()
-    * INCOMPLETE - US 63: lexically_normal() inconsistently treats trailing "/" but not "/.." as directory
-    * INCOMPLETE - US 73, CA 2: root-name is effectively implementation defined
-    * INCOMPLETE - US 74, CA 3: The term “pathname” is ambiguous in some contexts
-    * INCOMPLETE - US 75, CA 4: Extra flag in path constructors is needed
-    * INCOMPLETE - US 76, CA 5: root-name definition is over-specified.
-    * INCOMPLETE - US 77, CA 6: operator/ and other appends not useful if arg has root-name
-    * INCOMPLETE - US 78, CA 7: Member absolute() in 27.10.4.1 is overspecified for non-POSIX-like O/S
-    * INCOMPLETE - US 79, CA 8: Some operation functions are overspecified for implementation-defined file types
-    * INCOMPLETE - US 185: Fold error_code and non-error_code signatures into one signature
-    * INCOMPLETE - FI 14: directory_entry comparisons are members
-    * INCOMPLETE - Late 36: permissions() error_code overload should be noexcept
-    * INCOMPLETE - Late 37: permissions() actions should be separate parameter
-    * INCOMPLETE - Late 42: resize_file() Postcondition missing argument
-
 Misc Tasks
 ==========
 * Find all sequences of >2 underscores and eradicate them.
 * run clang-tidy on libc++
 * Document the "conditionally-supported" bits of libc++
-* Look at basic_string's move assignment operator, re LWG 2063 and POCMA
 * Put a static_assert in std::allocator to deny const/volatile types (LWG 2447)