It appears that uv's support for interacting with a stdio stream as a tty when
it's actually a pipe is pretty problematic. To get around this, promote a check
to see if the stream is a tty to the top of the tty constructor, and bail out
quickly if it's not identified as a tty.
Closes#10237
It turns out that the uv implementation would cause use-after-free if the idle
callback was used after the call to `close`, and additionally nothing would ever
really work that well if `start()` were called twice. To change this, the
`start` and `close` methods were removed in favor of specifying the callback at
creation, and allowing destruction to take care of closing the watcher.
Fully support multiple lifetime parameters on types and elsewhere, removing special treatment for `'self`. I am submitting this a touch early in that I plan to push a new commit with more tests specifically targeting types with multiple lifetime parameters -- but the current code bootstraps and passes `make check`.
Fixes#4846
This Fixes#10265 and paves the way for fixing #9543. It works by adding a 'package_id' attribute by default for library crates that don't specify it. This is necessary to use the 'extern mod foo = "bar"' form instead of 'extern mod foo(name="bar") (as per #9543), because the former adds a required package_id when trying to link with the bar crate. I added a simple test to ensure that the default package_id value is being generated, and also added an explicit package_id in the link attribute in all rust libs to avoid getting warnings about default package_id values when building rust.
I'm not sure this is something you're interested in, but I was playing around the Any trait a bit and I wanted to try it as a key in a HashMap. To do that, TypeId needs to implement IterBytes.
This renames to_str_ascii to as_str_ascii and makes it non-copying,
which is possible now that strings no longer have a hidden extra
byte/null terminator.
Fixes#6120.
This renames to_str_ascii to as_str_ascii and makes it non-copying,
which is possible now that strings no longer have a hidden extra
byte/null terminator.
Fixes#6120.
There were a few ambiguous error messages which look like they could have
cropped up from either the rust compiler for the format string parser. To
differentiate, the prefix 'invalid format string' is now added in front of all
format string errors.
cc #9970
There were a few ambiguous error messages which look like they could have
cropped up from either the rust compiler for the format string parser. To
differentiate, the prefix 'invalid format string' is now added in front of all
format string errors.
cc #9970
This binds to the appropriate pthreads_* and Windows specific functions
and calls them from Rust. This allows for removal of the C++ support
code for threads.
Fixes#10162
Right now if you're running a program with its output piped to some location and
the program decides to go awry, when you kill the program via some signal none
of the program's last 4K of output will get printed to the screen. In theory the
solution to this would be to register a signal handler as part of the runtime
which then flushes the output stream.
I believe that the current behavior is far enough from what's expected that we
shouldn't be providing this sort of "super buffering" by default when stdout
isn't attached to a tty.
This isn't quite as fancy as the struct in #9913, but I'm not sure we should be exposing crate names/hashes of the types. That being said, it'd be pretty easy to extend this (the deterministic hashing regardless of what crate you're in was the hard part).
Right now if you're running a program with its output piped to some location and
the program decides to go awry, when you kill the program via some signal none
of the program's last 4K of output will get printed to the screen. In theory the
solution to this would be to register a signal handler as part of the runtime
which then flushes the output stream.
I believe that the current behavior is far enough from what's expected that we
shouldn't be providing this sort of "super buffering" by default when stdout
isn't attached to a tty.
This fleshes out the io::file module a fair bit more, adding all of the functionality that I can think of that we would want. Some questions about the representation which I'm curious about:
* I modified `FileStat` to be a little less platform-agnostic, but it's still fairly platform-specific. I don't want to hide information that we have, but I don't want to depend on this information being available. One possible route is to have an `extra` field which has all this os-dependent stuff which is clearly documented as it should be avoided.
* Does it make sense for directory functions to be top-level functions instead of static methods? It seems silly to import `std::rt::io::file` and `std::rt::io::File` at the top of files that need to deal with directories and files.
This renames the `file` module to `fs` because that more accurately describes
its current purpose (manipulating the filesystem, not just files).
Additionally, this adds an UnstableFileStat structure as a nested structure of
FileStat to signify that the fields should not be depended on. The structure is
currently flagged with #[unstable], but it's unlikely that it has much meaning.
Closes#10241
This adds bindings to the remaining functions provided by libuv, all of which
are useful operations on files which need to get exposed somehow.
Some highlights:
* Dropped `FileReader` and `FileWriter` and `FileStream` for one `File` type
* Moved all file-related methods to be static methods under `File`
* All directory related methods are still top-level functions
* Created `io::FilePermission` types (backed by u32) that are what you'd expect
* Created `io::FileType` and refactored `FileStat` to use FileType and
FilePermission
* Removed the expanding matrix of `FileMode` operations. The mode of reading a
file will not have the O_CREAT flag, but a write mode will always have the
O_CREAT flag.
Closes#10130Closes#10131Closes#10121
This commit moves all thread-blocking I/O functions from the std::os module.
Their replacements can be found in either std::rt::io::file or in a hidden
"old_os" module inside of native::file. I didn't want to outright delete these
functions because they have a lot of special casing learned over time for each
OS/platform, and I imagine that these will someday get integrated into a
blocking implementation of IoFactory. For now, they're moved to a private module
to prevent bitrot and still have tests to ensure that they work.
I've also expanded the extensions to a few more methods defined on Path, most of
which were previously defined in std::os but now have non-thread-blocking
implementations as part of using the current IoFactory.
The api of io::file is in flux, but I plan on changing it in the next commit as
well.
Closes#10057
The invocation for making a directory should be able to specify a mode to make
the directory with (instead of defaulting to one particular mode). Additionally,
libuv and various OSes implement efficient versions of renaming files, so this
operation is exposed as an IoFactory call.
New standards have arisen in recent months, mostly for the use of
rustpkg, but the main Rust codebase has not been altered to match these
new specifications. This changeset rectifies most of these issues.
- Renamed the crate source files `src/libX/X.rs` to `lib.rs`, for
consistency with current styles; this affects extra, rustc, rustdoc,
rustpkg, rustuv, std, syntax.
- Renamed `X/X.rs` to `X/mod.rs,` as is now recommended style, for
`std::num` and `std::terminfo`.
- Shifted `src/libstd/str/ascii.rs` out of the otherwise unused `str`
directory, to be consistent with its import path of `std::ascii`;
libstd is flat at present so it's more appropriate thus.
While this removes some `#[path = "..."]` directives, it does not remove
all of them, and leaves certain other inconsistencies, such as `std::u8`
et al. which are actually stored in `src/libstd/num/` (one subdirectory
down). No quorum has been reached on this issue, so I felt it best to
leave them all alone at present. #9208 deals with the possibility of
making libstd more hierarchical (such as changing the crate to match the
current filesystem structure, which would make the module path
`std::num::u8`).
There is one thing remaining in which this repository is not
rustpkg-compliant: rustpkg would have `src/std/` et al. rather than
`src/libstd/` et al. I have not endeavoured to change that at this point
as it would guarantee prompt bitrot and confusion. A change of that
magnitude needs to be discussed first.
