Instead of scrutinizing modification times in rustpkg tests,
change output files to be read-only and detect attempts to write
to them (hack suggested by Jack). This avoids time granularity problems.
As part of this change, I discovered that some dependencies weren't
getting written correctly (involving built executables and library
files), so this patch fixes that too.
This partly addresses #9441, but one test (test_rebuild_when_needed)
is still ignored on Linux.
Rewrite the entire `std::path` module from scratch.
`PosixPath` is now based on `~[u8]`, which fixes#7225.
Unnecessary allocation has been eliminated.
There are a lot of clients of `Path` that still assume utf-8 paths.
This is covered in #9639.
Standardize the is_sep() functions to be the same in both posix and
windows, and re-export from path. Update extra::glob to use this.
Remove the usage of either, as it's going away.
Move the WindowsPath-specific methods out of WindowsPath and make them
top-level functions of path::windows instead. This way you cannot
accidentally write code that will fail to compile on non-windows
architectures without typing ::windows anywhere.
Remove GenericPath::from_c_str() and just impl BytesContainer for
CString instead.
Remove .join_path() and .push_path() and just implement BytesContainer
for Path instead.
Remove FilenameDisplay and add a boolean flag to Display instead.
Remove .each_parent(). It only had one caller, so just inline its
definition there.
Add a new trait BytesContainer that is implemented for both byte vectors
and strings.
Convert Path::from_vec and ::from_str to one function, Path::new().
Remove all the _str-suffixed mutation methods (push, join, with_*,
set_*) and modify the non-suffixed versions to use BytesContainer.
Remove the old path.
Rename path2 to path.
Update all clients for the new path.
Also make some miscellaneous changes to the Path APIs to help the
adoption process.
(scratching an itch.)
Rebased and updated.
Fixed bug: omitted field init from embedded struct literal in a test.
Fixed bug: int underflow during padding length calculation.
I've left out a way to construct from a `Send` type until #9509 is resolved. I am confident that this interface can remain backwards compatible though, assuming we name the `Pointer` trait method `borrow`.
When there is a way to convert from `Send` (`from_send`), a future RAII-based `Mut` type can be used with this to implemented a mutable reference-counted pointer. For now, I've left around the `RcMut` type but it may drastically change or be removed.
This provides 2 methods: .reseed() and ::from_seed that modify and
create respecitively.
Implement this trait for the RNGs in the stdlib for which this makes
sense.
This is 2x faster on 64-bit computers at generating anything larger
than 32-bits.
It has been verified against the canonical C implementation from the
website of the creator of ISAAC64.
Also, move `Rng.next` to `Rng.next_u32` and add `Rng.next_u64` to
take full advantage of the wider word width; otherwise Isaac64 will
always be squeezed down into a u32 wasting half the entropy and
offering no advantage over the 32-bit variant.
This commit fixes all of the fallout of the previous commit which is an attempt
to refine privacy. There were a few unfortunate leaks which now must be plugged,
and the most horrible one is the current `shouldnt_be_public` module now inside
`std::rt`. I think that this either needs a slight reorganization of the
runtime, or otherwise it needs to just wait for the external users of these
modules to get replaced with their `rt` implementations.
Other fixes involve making things pub which should be pub, and otherwise
updating error messages that now reference privacy instead of referencing an
"unresolved name" (yay!).
A few features are now hidden behind various #[feature(...)] directives. These
include struct-like enum variants, glob imports, and macro_rules! invocations.
Closes#9304Closes#9305Closes#9306Closes#9331
This PR solves one of the pain points with c-style enums. Simplifies writing a fn to convert from an int/uint to an enum. It does this through a `#[deriving(FromPrimitive)]` syntax extension.
Before this is committed though, we need to discuss if `ToPrimitive`/`FromPrimitive` has the right design (cc #4819). I've changed all the `.to_int()` and `from_int()` style functions to return `Option<int>` so we can handle partial functions. For this PR though only enums and `extra::num::bigint::*` take advantage of returning None for unrepresentable values. In the long run it'd be better if `i64.to_i8()` returned `None` if the value was too large, but I'll save this for a future PR.
Closes#3868.
The general idea of hyperlinking between crates is that it should require as
little configuration as possible, if any at all. In this vein, there are two
separate ways to generate hyperlinks between crates:
1. When you're generating documentation for a crate 'foo' into folder 'doc',
then if foo's external crate dependencies already have documented in the
folder 'doc', then hyperlinks will be generated. This will work because all
documentation is in the same folder, allowing links to work seamlessly both
on the web and on the local filesystem browser.
The rationale for this use case is a package with multiple libraries/crates
that all want to link to one another, and you don't want to have to deal with
going to the web. In theory this could be extended to have a RUST_PATH-style
searching situtation, but I'm not sure that it would work seamlessly on the
web as it does on the local filesystem, so I'm not attempting to explore this
case in this pull request. I believe to fully realize this potential rustdoc
would have to be acting as a server instead of a static site generator.
2. One of foo's external dependencies has a #[doc(html_root_url = "...")]
attribute. This means that all hyperlinks to the dependency will be rooted at
this url.
This use case encompasses all packages using libstd/libextra. These two
crates now have this attribute encoded (currently at the /doc/master url) and
will be read by anything which has a dependency on libstd/libextra. This
should also work for arbitrary crates in the wild that have online
documentation. I don't like how the version is hard-wired into the url, but I
think that this may be a case-by-case thing which doesn't end up being too
bad in the long run.
Closes#9539
