| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This makes some headway on #3309, see commits for details.
|
|
|
|
|
|
|
|
This lets the C++ code in the rt handle the (slightly) tricky parts of
random number generation: e.g. error detection/handling, and using the
values of the `#define`d options to the various functions.
|
|
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.
|
|
respectively.
The former reads from e.g. /dev/urandom, the latter just wraps any
std::rt::io::Reader into an interface that implements Rng.
This also adds Rng.fill_bytes for efficient implementations of the above
(reading 8 bytes at a time is inefficient when you can read 1000), and
removes the dependence on src/rt (i.e. rand_gen_seed) although this last
one requires implementing hand-seeding of the XorShiftRng used in the
scheduler on Linux/unixes, since OSRng relies on a scheduler existing to
be able to read from /dev/urandom.
|
|
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 works around #9779, but is probably the right thing to do anyways
since that's the module where all of the documentation for those traits
lives.
|
|
this is no longer used by the compiler
|
|
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!).
|
|
This pull request changes to memory layout of the `CrateMap` struct to use static slices instead of raw pointers. Most of the discussion took place [here](https://github.com/fhahn/rust/commit/63b5975efa10af7df3df0a50d8d7f9c8d5bcf9e9#L1R92) .
The memory layout of CrateMap changed, without bumping the version number in the struct. Another, more backward compatible, solution would be to keep the old code and increase the version number in the new struct. On the other hand, the `annihilate_fn` pointer was removed without bumping the version number recently.
At the moment, the stage0 compiler does not use the new memory layout, which would lead the segfaults during stage0 compilation, so I've added a dummy `iter_crate_map` function for stage0, which does nothing. Again, this could be avoided if we'd bump the version number in the struct and keep the old code.
I'd like to use a normal `for` loop [here](https://github.com/fhahn/rust/compare/logging-unsafe-removal?expand=1#L1R109),
for child in children.iter() {
do_iter_crate_map(child, |x| f(x), visited);
}
but for some reason this only yields `error: unresolved enum variant, struct or const 'Some'` and I have no idea why.
|
|
|
|
static or owned strings
|
|
|
|
|
|
Relaxe lifetime of CrateMap as well.
|
|
|
|
cc #8811
|
|
|
|
cc #9605
|
|
This adds a large doc-block to the top of the std::logging module explaining how
to use it. This is mostly just making sure that all the information in the
manual's section about logging is also here (in case someone decides to look
into this module first).
This also removes the old console_{on,off} methods. As far as I can tell, the
functions were only used by the compiler, and there's no reason for them to be
used because they're all turned off by default anyway (maybe they were turned on
by default at some point...)
I believe that this is the final nail in the coffin and closes #5021
|
|
Add a test to make sure it works and switch a private struct over to a
newtype.
Closes #9155
|
|
UnboundedPipeStream is still a newtype since process::set_stdio needs to
look into its internals.
Closes #9667
|
|
Uses the new snapshots to kill the old `loop` and introduce the new `continue`.
|
|
Closes #9341
|
|
Closes #9341
|
|
Closes #9467
|
|
|
|
Closes #8815.
|
|
|
|
Small change that suppresses a warning because of an unused import.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This lifts various restrictions on the runtime, for example the character limit
when logging a message. Right now the old debug!-style macros still involve
allocating (because they use fmt! syntax), but the new debug2! macros don't
involve allocating at all (unless the formatter for a type requires allocation.
|
|
This also includes a fix for yielding from single-threaded schedulers where the scheduler would stop working before its work queue was empty. Fixes the deadlocks that this patch had previously.
|
|
|
|
If there's no TLS key just yet, then there's nothing to unsafely borrow, so
continue returning None. This prevents causing the runtime to abort itself when
logging before the runtime is fully initialized.
Closes #9487
r? @brson
|
|
|
|
|
|
This lifts various restrictions on the runtime, for example the character limit
when logging a message. Right now the old debug!-style macros still involve
allocating (because they use fmt! syntax), but the new debug2! macros don't
involve allocating at all (unless the formatter for a type requires allocation.
|
|
find src -name '*.rs' | xargs sed -i '' 's/~~~.*{\.rust}/```rust/g'
find src -name '*.rs' | xargs sed -i '' 's/ ~~~$/ ```/g'
find src -name '*.rs' | xargs sed -i '' 's/^~~~$/ ```/g'
|
|
If there's no TLS key just yet, then there's nothing to unsafely borrow, so
continue returning None. This prevents causing the runtime to abort itself when
logging before the runtime is fully initialized.
Closes #9487
|
|
#8431
~~@brson: do we need to bump up the cratemap version for this change?~~ Tis a no.
|
|
|
