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 fixes a bug in which the visibility rules were approximated by
reachability, but forgot to cover the case where a 'pub use' reexports a private
item. This fixes the commit by instead using the results of the privacy pass of
the compiler to create the initial working set of the reachability pass.
This may have the side effect of increasing the size of metadata, but it's
difficult to avoid for correctness purposes sadly.
Closes#9790
This implements a number of the baby steps needed to start eliminating everything inside of `std::io`. It turns out that there are a *lot* of users of that module, so I'm going to try to tackle them separately instead of bringing down the whole system all at once.
This pull implements a large amount of unimplemented functionality inside of `std::rt::io` including:
* Native file I/O (file descriptors, *FILE)
* Native stdio (through the native file descriptors)
* Native processes (extracted from `std::run`)
I also found that there are a number of users of `std::io` which desire to read an input line-by-line, so I added an implementation of `read_until` and `read_line` to `BufferedReader`.
With all of these changes in place, I started to axe various usages of `std::io`. There's a lot of one-off uses here-and-there, but the major use-case remaining that doesn't have a fantastic solution is `extra::json`. I ran into a few compiler bugs when attempting to remove that, so I figured I'd come back to it later instead.
There is one fairly major change in this pull, and it's moving from native stdio to uv stdio via `print` and `println`. Unfortunately logging still goes through native I/O (via `dumb_println`). This is going to need some thinking, because I still want the goal of logging/printing to be 0 allocations, and this is not possible if `io::stdio::stderr()` is called on each log message. Instead I think that this may need to be cached as the `logger` field inside the `Task` struct, but that will require a little more workings to get right (this is also a similar problem for print/println, do we cache `stdout()` to not have to re-create it every time?).
This fixes a bug in which the visibility rules were approximated by
reachability, but forgot to cover the case where a 'pub use' reexports a private
item. This fixes the commit by instead using the results of the privacy pass of
the compiler to create the initial working set of the reachability pass.
This may have the side effect of increasing the size of metadata, but it's
difficult to avoid for correctness purposes sadly.
Closes#9790
This changes an `assert_once_ever!` assertion to just a plain old assertion
around an atomic boolean to ensure that one particular runtime doesn't attempt
to exit twice.
Closes#9739
This changes an `assert_once_ever!` assertion to just a plain old assertion
around an atomic boolean to ensure that one particular runtime doesn't attempt
to exit twice.
Closes#9739
This disallows `str[0] = foo` along with `foo = &mut str[i]` to prevent strings
from being modified at runtime (except possibly through the `str` module)
Closes#8891
A pile of changes to `std::rand`:
- Add the 64-bit variant of the ISAAC Rng. This also splits the `Rng.next() -> u32` method into `Rng.next_u32() -> u32` and `Rng.next_u64() -> u64` to be able to actually take advantage of the wider numbers. They have default implementations in terms of each other. (This is ~2× faster than the 32 bit one for generating anything larger than a `u32` on 64-bit computers.)
- Add `ReaderRng` which just wraps a reader as an RNG, useful for `/dev/urandom`, `/dev/random`, `/dev/hwrng`, etc. This also adds the overrideable `fill_bytes` method to `Rng`, since readers can "generate" randomness more than just 8 bytes at a time.
- Add an interface to `/dev/urandom` (and the windows API) that implements `Rng` (`os::OSRng`) so that it is a first-class randomness source. This means that experimenting with things like seeding hashmaps from it will be much easier. It deletes most of the C++ supporting the old form, except for thin wrappers around the Windows API; I don't have access to a windows with Rust other than the try branch. ( **Note:** on unices, this means that `OSRng` requires the runtime, so it's not possible to use it to seed the scheduler RNG; I've replaced it with direct libc calls for reading from `/dev/urandom`.)
- Add the "blessed" `StdRng` which means users who just want a random number generator don't need to worry about the implementation details (which will make changing the underlying implementation from Isaac to something else will be easier, if this every happen). This actually changes between the 32 and 64-bit variants of Isaac depending on the platform at the moment.
- Add a `SeedableRng` trait for random number generators that can be explicitly seeded,
- Add the `ReseedingRng` wrapper for reseeding a RNG after a certain amount of randomness is emitted. (The method for reseeding is controlled via the `Reseeder` trait from the same module)
- changes to the task rng:
- uses `StdRng`
- it will reseed itself every 32KB, that is, after outputting 32KB of random data it will read new data from the OS (via `OSRng`)
- Implements `Rand` for `char`, and makes the `f32` and `f64` instances more reasonable (and more similar to most other languages I've looked at).
- Documentation, examples and tests
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.
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
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).
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
Raw string literals are lexed into regular string literals. This is okay
for them to "work" and be usable/testable, but the pretty-printer does
not know about them yet and will just emit regular string literals.
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 commit is the culmination of my recent effort to refine Rust's notion of
privacy and visibility among crates. The major goals of this commit were to
remove privacy checking from resolve for the sake of sane error messages, and to
attempt a much more rigid and well-tested implementation of visibility
throughout rust. The implemented rules for name visibility are:
1. Everything pub from the root namespace is visible to anyone
2. You may access any private item of your ancestors.
"Accessing a private item" depends on what the item is, so for a function this
means that you can call it, but for a module it means that you can look inside
of it. Once you look inside a private module, any accessed item must be "pub
from the root" where the new root is the private module that you looked into.
These rules required some more analysis results to get propagated from trans to
privacy in the form of a few hash tables.
I added a new test in which my goal was to showcase all of the privacy nuances
of the language, and I hope to place any new bugs into this file to prevent
regressions.
Overall, I was unable to completely remove the notion of privacy from resolve.
One use of privacy is for dealing with glob imports. Essentially a glob import
can only import *public* items from the destination, and because this must be
done at namespace resolution time, resolve must maintain the notion of "what
items are public in a module". There are some sad approximations of privacy, but
I unfortunately can't see clear methods to extract them outside.
The other use case of privacy in resolve now is one that must stick around
regardless of glob imports. When dealing with privacy, checking a private path
needs to know "what the last private thing was" when looking at a path. Resolve
is the only compiler pass which knows the answer to this question, so it
maintains the answer on a per-path resolution basis (works similarly to the
def_map generated).
Closes#8215
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.
Mostly as per a short discussion on irc. (@cmr)
08:46 < cmr> so I'm thinking
Obsolete{Let,With,FieldTerminator,ClassTraits,ModeInFnType,MoveInit,BinaryMove,I
mplSyntax,MutOwnedPointer,MutVector,RecordType,RecordPattern,PostFnTySigil,Newty
pEnum,Mode,ImplicitSelf,LifetimeNotation,Purity,StaticMethod,ConstItem,FixedLeng
thVectorType}
08:46 < cmr> Those are the ones that are older than 0.6
08:46 < cmr> (at least!)
This PR removes these specific "obsolete syntax"/"suggestion for change" errors and just lets the parser run into regular parser errors for long-invalid syntax. I also removed `ObsoletePrivSection` which apparently dates further back than cmr or I could recall and `ObsoleteUnenforcedBound` which seemed unused. Also I removed `ObsoleteNewtypeEnum`.
Replaces existing tests for removed obsolete-syntax errors with tests
for the resulting regular errors, adds a test for each of the removed
parser errors to make sure that obsolete forms don't start working
again, removes some obsolete/superfluous tests that were now failing.
Deletes some amount of dead code in the parser, also includes some small
changes to parser error messages to accomodate new tests.
This makes sure that the top-level crate name is correct when emitting log
statements for a monomorphized function in another crate. This happens by
tracing the monomorphized ID back to the external source and then using that
crate index to get the name of the crate.
Closes#3046
