---

yaml
---
r: 72151
b: refs/heads/dist-snap
c: e782e1f
h: refs/heads/master
i:
  72149: edf89b8
  72147: eb3288a
  72143: 093c074
v: v3

Author: brson

[refs]

@@ -7,7 +7,7 @@ refs/tags/release-0.1: 1f5c5126e96c79d22cb7862f75304136e204f105
 refs/heads/ndm: f3868061cd7988080c30d6d5bf352a5a5fe2460b
 refs/heads/try2: 147ecfdd8221e4a4d4e090486829a06da1e0ca3c
 refs/heads/incoming: b50030718cf28f2a5a81857a26b57442734fe854
-refs/heads/dist-snap: b57611d10c31a7bfdc3703fa938277caaa87f3a7
+refs/heads/dist-snap: e782e1f37183b7ad7731cf0fbb474b55d199a9d5
 refs/tags/release-0.2: c870d2dffb391e14efb05aa27898f1f6333a9596
 refs/tags/release-0.3: b5f0d0f648d9a6153664837026ba1be43d3e2503
 refs/heads/try3: 9387340aab40a73e8424c48fd42f0c521a4875c0

branches/dist-snap/src/libcore/rt/io/file.rs

@@ -14,10 +14,10 @@ use super::{Reader, Writer, Seekable, Closeable};
 use super::{IoError, SeekStyle};
 
 /// Open a file with the default FileMode and FileAccess
-/// # TODO are there sane defaults here?
+/// # XXX are there sane defaults here?
 pub fn open_file<P: PathLike>(_path: &P) -> FileStream { fail!() }
 
-/// # TODO
+/// # XXX
 /// * Ugh, this is ridiculous. What is the best way to represent these options?
 enum FileMode {
     /// Opens an existing file. IoError if file does not exist.
@@ -33,7 +33,7 @@ enum FileMode {
     /// Opens an existing file or creates a new one, truncating it to 0 bytes.
     CreateOrTruncate,
 }
- 
+
 enum FileAccess {
     Read,
     Write,

branches/dist-snap/src/libcore/rt/io/mem.rs

@@ -10,7 +10,7 @@
 
 //! Readers and Writers for in-memory buffers
 //!
-//! # TODO
+//! # XXX
 //!
 //! * Should probably have something like this for strings.
 //! * Should they implement Closable? Would take extra state.
@@ -61,7 +61,7 @@ impl Decorator<~[u8]> for MemWriter {
     }
 }
 
-/// Reads from an owned byte vector 
+/// Reads from an owned byte vector
 pub struct MemReader {
     buf: ~[u8],
     pos: uint
@@ -109,13 +109,13 @@ impl Decorator<~[u8]> for MemReader {
     }
 }
 
- 
+
 /// Writes to a fixed-size byte slice
 struct BufWriter<'self> {
     buf: &'self mut [u8],
     pos: uint
 }
- 
+
 impl<'self> BufWriter<'self> {
     pub fn new<'a>(buf: &'a mut [u8]) -> BufWriter<'a> {
         BufWriter {
@@ -138,7 +138,7 @@ impl<'self> Seekable for BufWriter<'self> {
 }
 
 
-/// Reads from a fixed-size byte slice 
+/// Reads from a fixed-size byte slice
 struct BufReader<'self> {
     buf: &'self [u8],
     pos: uint

branches/dist-snap/src/libcore/rt/io/mod.rs

@@ -11,7 +11,7 @@
 /*! Synchronous I/O
 
 This module defines the Rust interface for synchronous I/O.
-It supports file access, 
+It supports file access,
 
 This will likely live in core::io, not core::rt::io.
 
@@ -73,7 +73,7 @@ Some I/O things don't belong in core
     - http
   - flate
 
-# TODO
+# XXX
 
 * Should default constructors take `Path` or `&str`? `Path` makes simple cases verbose.
   Overloading would be nice.
@@ -149,10 +149,10 @@ mod misc;
 pub mod blocking {
     /// Posix file I/O
     pub mod file;
-    /// # TODO - implement this
+    /// # XXX - implement this
     pub mod stdio { }
     /// Sockets
-    /// # TODO - implement this
+    /// # XXX - implement this
     pub mod net {
         pub mod tcp { }
         pub mod udp { }
@@ -164,7 +164,7 @@ pub mod blocking {
 
 /// The type passed to I/O condition handlers to indicate error
 ///
-/// # TODO
+/// # XXX
 ///
 /// Is something like this sufficient? It's kind of archaic
 pub struct IoError {
@@ -195,7 +195,7 @@ pub trait Reader {
     ///
     /// Raises the `io_error` condition on error, then returns `None`.
     ///
-    /// # TODO
+    /// # XXX
     ///
     /// This doesn't take a `len` argument like the old `read`.
     /// Will people often need to slice their vectors to call this
@@ -211,7 +211,7 @@ pub trait Reader {
     ///         println(reader.read_line());
     ///     }
     ///
-    /// # TODO
+    /// # XXX
     ///
     /// What does this return if the Reader is in an error state?
     fn eof(&mut self) -> bool;
@@ -249,7 +249,7 @@ pub enum SeekStyle {
     SeekCur,
 }
 
-/// # TODO
+/// # XXX
 /// * Are `u64` and `i64` the right choices?
 pub trait Seekable {
     fn tell(&self) -> u64;
@@ -262,13 +262,13 @@ pub trait Seekable {
 /// uses decorators to add functionality like compression and encryption to I/O
 /// streams.
 ///
-/// # TODO
+/// # XXX
 ///
 /// Is this worth having a trait for? May be overkill
 pub trait Decorator<T> {
     /// Destroy the decorator and extract the decorated value
     ///
-    /// # TODO
+    /// # XXX
     ///
     /// Because this takes `self' one could never 'undecorate' a Reader/Writer
     /// that has been boxed. Is that ok? This feature is mostly useful for

branches/dist-snap/src/libcore/rt/io/net/http.rs

@@ -17,7 +17,7 @@ struct HttpServer;
 #[cfg(test)]
 mod test {
     use unstable::run_in_bare_thread;
-    
+
     #[test] #[ignore]
     fn smoke_test() {
         do run_in_bare_thread {

branches/dist-snap/src/libcore/rt/io/util.rs

@@ -10,8 +10,8 @@
 
 //! Utility mixins that apply to all Readers and Writers
 
-// TODO: Not sure how this should be structured
-// TODO: Iteration should probably be considered seperately
+// XXX: Not sure how this should be structured
+// XXX: Iteration should probably be considered seperately
 
 pub trait ReaderUtil {