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.
It now:
- can be explicitly seeded from user code (`seed_task_rng`) or from the
environment (`RUST_SEED`, a positive integer)
- automatically reseeds itself from the OS *unless* it was seeded by
either method above
- has more documentation
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 implemented as a wrapper around another RNG. It is designed
to allow the actual implementation to be changed without changing
the external API (e.g. it currently uses a 64-bit generator on 64-
bit platforms, and a 32-bit one on 32-bit platforms; but one could
imagine that the IsaacRng may be deprecated later, and having this
ability to switch algorithms without having to update the points of
use is convenient.)
This is the recommended general use RNG.
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.
Since lint check attributes are the preferred way of selectively
enabling/disabling lint checks, the output format of a failed
default check has been changed to reflect that.
When lint checks are being explicitly set by a command-line flag
or an attribute, the behavior is unchanged, so that the user can
quickly pinpoint the source.
Supersedes the patch suggested in #9778Closes#6580
Fixes a bug that `rustc.exe -v` didn't show git revision hash.
The bug is caused by that `$(wildcard $(CFG_GIT))` requires
space-escaped inputs while `$(CFG_GIT)` is usually
`C:\Program Files (x86)\Git\bin\git.exe`.
Since lint check attributes are the preferred way of selectively
enabling/disabling lint checks, the output format of a failed
default check has been changed to reflect that.
When lint checks are being explicitly set by a command-line flag
or an attribute, the behavior is unchanged, so that the user can
quickly pinpoint the source.
Closes#6580
It's unclear to me why these currently aren't allowed, and my best guess is that
a long time ago we didn't strip the ast of cfg nodes before syntax expansion.
Now that this is done, I'm not certain that we should continue to prohibit this
functionality.
This is a step in the right direction towards #5605, because now we can add an
empty `std::macros` module to the documentation with a bunch of empty macros
explaining how they're supposed to be used.
It's unclear to me why these currently aren't allowed, and my best guess is that
a long time ago we didn't strip the ast of cfg nodes before syntax expansion.
Now that this is done, I'm not certain that we should continue to prohibit this
functionality.
This is a step in the right direction towards #5605, because now we can add an
empty `std::macros` module to the documentation with a bunch of empty macros
explaining how they're supposed to be used.
r? anybody It's more helpful to list the span of each open delimiter seen so far
than to print out an error with the span of the last position in the file.
Closes#2354
r? anyone
Add bindings for start and ends of keyword ranges; use bindings in match arms.
Also, fixed latent bug that inspired this change: the pattern in `is_any_keyword` had not been updated to match the new range of reserved keyword identifiers.
(I briefly tried to expose the latent bug, but `is_any_keyword` is currently only called in contexts where a failure of this kind merely causes a bit more fruitless compilation before `check_reserved_keywords` is called by the parser, which correctly tags `sizeof` as reserved.)
This should fix some outstanding namespace issues. It also fixes an issue with LLVM metadata uniquing that caused an LLVM assertion when compiling libstd.
One thing to keep in mind is that the `-O` flag and the debug info flags are essentially incompatible. It may work but I would not consider this in any way supported at the moment. On the other hand, there is also good news: With the changes in this PR I am able to compile all of rust with extra-debug-info:
```
make RUSTFLAGS_STAGE2='-Zextra-debug-info' check
```
compiles the whole thing without warning and passes the whole test suite (given that `configure` is run with `--disable-optimize`). That's kind of nice `:)` Still, I'm reluctant to automatically close the related issues (#9167, #9190, #9268) without confirmation from the openers. I'll post to the individual threads once this gets merged.
This is the culmination and attempted resolution of #8215. The commits have many more details about implementation details and the consequences of this refinement.
I'll point out specific locations which may be possible causes for alarm. In general, I have been very happy with how things have turned out. I'm a little sad that I couldn't remove privacy from resolve as much as I did, but I blame glob imports (although in theory even some of this can be mitigated as well).
For the benefit of the pretty printer we want to keep track of how
string literals in the ast were originally represented in the source
code.
This commit changes parser functions so they don't extract strings from
the token stream without at least also returning what style of string
literal it was. This is stored in the resulting ast node for string
literals, obviously, for the package id in `extern mod = r"package id"`
view items, for the inline asm in `asm!()` invocations.
For `asm!()`'s other arguments or for `extern "Rust" fn()` items, I just
the style of string, because it seemed disproportionally cumbersome to
thread that information through the string processing that happens with
those string literals, given the limited advantage raw string literals
would provide in these positions.
The other syntax extensions don't seem to store passed string literals
in the ast, so they also discard the style of strings they parse.
