about summary refs log tree commit diff
path: root/src/libstd
AgeCommit message (Collapse)AuthorLines
2014-03-12rand: deprecate `rng`.Huon Wilson-1/+1
This should be called far less than it is because it does expensive OS interactions and seeding of the internal RNG, `task_rng` amortises this cost. The main problem is the name is so short and suggestive. The direct equivalent is `StdRng::new`, which does precisely the same thing. The deprecation will make migrating away from the function easier.
2014-03-12Remove the dependence of std::io::test on rand.Huon Wilson-4/+11
This replaces it with a manual "task rng" using XorShift and a crappy seeding mechanism. Theoretically good enough for the purposes though (unique for tests).
2014-03-12std: Move rand to librand.Huon Wilson-3888/+2
This functionality is not super-core and so doesn't need to be included in std. It's possible that std may need rand (it does a little bit now, for io::test) in which case the functionality required could be moved to a secret hidden module and reexposed by librand. Unfortunately, using #[deprecated] here is hard: there's too much to mock to make it feasible, since we have to ensure that programs still typecheck to reach the linting phase.
2014-03-11auto merge of #12556 : alexcrichton/rust/weak-linkage, r=brsonbors-40/+28
It is often convenient to have forms of weak linkage or other various types of linkage. Sadly, just using these flavors of linkage are not compatible with Rust's typesystem and how it considers some pointers to be non-null. As a compromise, this commit adds support for weak linkage to external symbols, but it requires that this is only placed on extern statics of type `*T`. Codegen-wise, we get translations like: ```rust // rust code extern { #[linkage = "extern_weak"] static foo: *i32; } // generated IR @foo = extern_weak global i32 @_some_internal_symbol = internal global *i32 @foo ``` All references to the rust value of `foo` then reference `_some_internal_symbol` instead of the symbol `_foo` itself. This allows us to guarantee that the address of `foo` will never be null while the value may sometimes be null. An example was implemented in `std::rt::thread` to determine if `__pthread_get_minstack()` is available at runtime, and a test is checked in to use it for a static value as well. Function pointers a little odd because you still need to transmute the pointer value to a function pointer, but it's thankfully better than not having this capability at all. Thanks to @bnoordhuis for the original patch, most of this work is still his!
2014-03-11rustc: Support various flavors of linkagesAlex Crichton-40/+28
It is often convenient to have forms of weak linkage or other various types of linkage. Sadly, just using these flavors of linkage are not compatible with Rust's typesystem and how it considers some pointers to be non-null. As a compromise, this commit adds support for weak linkage to external symbols, but it requires that this is only placed on extern statics of type `*T`. Codegen-wise, we get translations like: // rust code extern { #[linkage = "extern_weak"] static foo: *i32; } // generated IR @foo = extern_weak global i32 @_some_internal_symbol = internal global *i32 @foo All references to the rust value of `foo` then reference `_some_internal_symbol` instead of the symbol `_foo` itself. This allows us to guarantee that the address of `foo` will never be null while the value may sometimes be null. An example was implemented in `std::rt::thread` to determine if `__pthread_get_minstack()` is available at runtime, and a test is checked in to use it for a static value as well. Function pointers a little odd because you still need to transmute the pointer value to a function pointer, but it's thankfully better than not having this capability at all.
2014-03-11Add an ItemModifier syntax extension typeSteven Fackler-0/+15
Where ItemDecorator creates new items given a single item, ItemModifier alters the tagged item in place. The expansion rules for this are a bit weird, but I think are the most reasonable option available. When an item is expanded, all ItemModifier attributes are stripped from it and the item is folded through all ItemModifiers. At that point, the process repeats until there are no ItemModifiers in the new item.
2014-03-08auto merge of #12706 : pongad/rust/issue_12698, r=brsonbors-209/+20
Fixes #12698
2014-03-08auto merge of #12759 : lucab/rust/char-doc, r=alexcrichtonbors-29/+60
This is mostly a reaction to #12730. If we are going to keep calling them `char`, at least make it clear that they aren't characters but codepoint/scalar.
2014-03-08Incorporated review feedback atop pcwalton's original patches.Felix S. Klock II-11/+9
(Original PR was #12716; feedback was provided by thestinger and me.)
2014-03-08Removed DeepClone. Issue #12698.Michael Darakananda-209/+20
2014-03-08libstd: Add some more functionality to Vec<T>Patrick Walton-0/+131
2014-03-08doc: add two missing char methods doc-stringsLuca Bruno-2/+12
XID_* property are defined in UAX #31, just reference it here. Signed-off-by: Luca Bruno <lucab@debian.org>
2014-03-08doc: uniform std::char doc-stringsLuca Bruno-23/+30
Uniform and beautify doc-string for current rustdoc output. Signed-off-by: Luca Bruno <lucab@debian.org>
2014-03-08doc: don't refer to 'char' as charactersLuca Bruno-18/+32
This seems to be causing some confusion among users. Rust's char are not 8bit characters, but 32bit UCS-4 codepoint without surrogates (Unicode Scalar Values as per Unicode glossary). Make the doc more explicit about it. Signed-off-by: Luca Bruno <lucab@debian.org>
2014-03-07create a sensible comparison trait hierarchyDaniel Micay-18/+33
* `Ord` inherits from `Eq` * `TotalOrd` inherits from `TotalEq` * `TotalOrd` inherits from `Ord` * `TotalEq` inherits from `Eq` This is a partial implementation of #12517.
2014-03-07std: stop `vec!()` warning about unused mutability.Huon Wilson-3/+5
If no arguments are given to `vec!` then no pushes are emitted and so the compiler (rightly) complains that the mutability of `temp` is never used. This behaviour is rather annoying for users.
2014-03-06fix typos with with repeated words, just like this sentence.Kang Seonghoon-8/+8
2014-03-06auto merge of #12705 : alexcrichton/rust/issue-12692, r=brsonbors-3/+64
Details are in the commit messages, but this closes a few issues seen with `libnative` recently.
2014-03-05std: Move libnative task count bookkeeping to stdAlex Crichton-0/+56
When using tasks in Rust, the expectation is that the runtime does not exit before all tasks have exited. This is enforced in libgreen through the `SchedPool` type, and it is enforced in libnative through a `bookkeeping` module and a global count/mutex pair. Unfortunately, this means that a process which originates with libgreen will not wait for spawned native tasks. In order to fix this problem, the bookkeeping module was moved from libnative to libstd so the runtime itself can wait for native tasks to exit. Green tasks do not manage themselves through this bookkeeping module, but native tasks will continue to manage themselves through this module. Closes #12684
2014-03-05add tests for `min` and `max` from `Float`Daniel Micay-0/+24
2014-03-05native: Move from usleep() to nanosleep()Alex Crichton-0/+2
Using nanosleep() allows us to gracefully recover from EINTR because on error it fills in the second parameter with the remaining time to sleep. Closes #12689
2014-03-05native: Stop using readdir()Alex Crichton-3/+6
This function is not threadsafe, and is deprecated in favor of the threadsafe readdir_r variant. Closes #12692
2014-03-05auto merge of #12700 : thestinger/rust/float, r=cmrbors-89/+42
2014-03-05consistently use LLVM floating point intrinsicsDaniel Micay-87/+18
2014-03-05add correct floating point `min` and `max` methods.Daniel Micay-2/+24
The `std::cmp` functions are not correct for floating point types. `min(NaN, 2.0)` and `min(2.0, NaN)` return different values, because these functions assume a total order. Floating point types need special `min`, `max` and `clamp` functions.
2014-03-05Str::slice_chars() is O(end), not O(end - begin)Simon Sapin-2/+2
2014-03-04auto merge of #12491 : eddyb/rust/deref, r=nikomatsakisbors-3/+54
Add the `Deref` and `DerefMut` traits and implement overloading explicit dereferences.
2014-03-04auto merge of #12300 : DaGenix/rust/uppercase-variable-lint, r=alexcrichtonbors-25/+26
I added a new lint for variables whose names contain uppercase characters, since, by convention, variable names should be all lowercase. What motivated me to work on this was when I ran into something like the following: ```rust use std::io::File; use std::io::IoError; fn main() { let mut f = File::open(&Path::new("/something.txt")); let mut buff = [0u8, ..16]; match f.read(buff) { Ok(cnt) => println!("read this many bytes: {}", cnt), Err(IoError{ kind: EndOfFile, .. }) => println!("Got end of file: {}", EndOfFile.to_str()), } } ``` I then got compile errors when I tried to add a wildcard match pattern at the end which I found very confusing since I believed that the 2nd match arm was only matching the EndOfFile condition. The problem is that I hadn't imported io::EndOfFile into the local scope. So, I thought that I was using EndOfFile as a sub-pattern, however, what I was actually doing was creating a new local variable named EndOfFile. This lint makes this error easier to spot by providing a warning that the variable name EndOfFile contains a uppercase characters which provides a nice hint as to why the code isn't doing what is intended. The lint warns on local bindings as well: ```rust let Hi = 0; ``` And also struct fields: ```rust struct Something { X: uint } ```
2014-03-05Allow uppercase_variables in libstd/libc.rsPalmer Cox-0/+1
2014-03-04Rename struct fields with uppercase characters in their names to use lowercasePalmer Cox-4/+4
2014-03-04Rename all variables that have uppercase characters in their names to use ↵Palmer Cox-22/+22
only lowercase characters
2014-03-04auto merge of #12697 : thestinger/rust/vec, r=huonwbors-0/+1
This exists for the sake of compatibility during the ~[T] -> Vec<T> transition. It will be removed in the future.
2014-03-04mark the `map` method on Vec<T> as deprecatedDaniel Micay-0/+1
This exists for the sake of compatibility during the ~[T] -> Vec<T> transition. It will be removed in the future.
2014-03-04auto merge of #12694 : thestinger/rust/mut_iter, r=huonwbors-9/+19
This become `Pod` when it was switched to using marker types.
2014-03-04make `MutItems` iterator sound againDaniel Micay-9/+19
This become `Pod` when it was switched to using marker types.
2014-03-04auto merge of #12667 : Kimundi/rust/any_improv, r=cmrbors-119/+56
- Added `TraitObject` representation to `std::raw`. - Added doc to `std::raw`. - Removed `Any::as_void_ptr()` and `Any::as_mut_void_ptr()` methods as they are uneccessary now after the removal of headers on owned boxes. This reduces the number of virtual calls needed from 2 to 1. - Made the `..Ext` implementations work directly with the repr of a trait object. - Removed `Any`-related traits from the prelude. - Added bench. Bench before/after: ~~~ 7 ns/iter (+/- 0) 4 ns/iter (+/- 0) ~~~
2014-03-04Cleaned up `std::any`Marvin Löbel-119/+56
- Added `TraitObject` representation to `std::raw`. - Added doc to `std::raw`. - Removed `Any::as_void_ptr()` and `Any::as_mut_void_ptr()` methods as they are uneccessary now after the removal of headers on owned boxes. This reduces the number of virtual calls needed. - Made the `..Ext` implementations work directly with the repr of a trait object. - Removed `Any`-related traits from the prelude. - Added bench for `Any`
2014-03-04doc: use the newer faviconAdrien Tétar-1/+1
2014-03-04Implement DerefImm for Rc and DerefImm/DerefMut for RefCell's Ref/RefMut.Eduard Burtescu-2/+31
2014-03-04Add the DerefImm and DerefMut traits.Eduard Burtescu-1/+23
2014-03-04std: add reserve_additional and an Extendable impl to Vec.Huon Wilson-2/+66
2014-03-01libsyntax: Fix errors arising from the automated `~[T]` conversionPatrick Walton-0/+27
2014-03-01libstd: Add some functionality to `Vec<T>`Patrick Walton-1/+37
2014-03-01std: Switch stdout/stderr to buffered by defaultAlex Crichton-10/+32
Similarly to #12422 which made stdin buffered by default, this commit makes the output streams also buffered by default. Now that buffered writers will flush their contents when they are dropped, I don't believe that there's no reason why the output shouldn't be buffered by default, which is what you want in 90% of cases. As with stdin, there are new stdout_raw() and stderr_raw() functions to get unbuffered streams to stdout/stderr.
2014-03-01std: Flush when buffered writers are droppedAlex Crichton-14/+25
It's still not entirely clear what should happen if there was an error when flushing, but I'm deferring that decision to #12628. I believe that it's crucial for the usefulness of buffered writers to be able to flush on drop. It's just too easy to forget to flush them in small one-off use cases. cc #12628
2014-02-28std: Change assert_eq!() to use {} instead of {:?}Alex Crichton-183/+189
Formatting via reflection has been a little questionable for some time now, and it's a little unfortunate that one of the standard macros will silently use reflection when you weren't expecting it. This adds small bits of code bloat to libraries, as well as not always being necessary. In light of this information, this commit switches assert_eq!() to using {} in the error message instead of {:?}. In updating existing code, there were a few error cases that I encountered: * It's impossible to define Show for [T, ..N]. I think DST will alleviate this because we can define Show for [T]. * A few types here and there just needed a #[deriving(Show)] * Type parameters needed a Show bound, I often moved this to `assert!(a == b)` * `Path` doesn't implement `Show`, so assert_eq!() cannot be used on two paths. I don't think this is much of a regression though because {:?} on paths looks awful (it's a byte array). Concretely speaking, this shaved 10K off a 656K binary. Not a lot, but sometime significant for smaller binaries.
2014-02-28auto merge of #12616 : alexcrichton/rust/size, r=huonwbors-112/+117
I've been playing around with code size when linking to libstd recently, and these were some findings I found that really helped code size. I started out by eliminating all I/O implementations from libnative and instead just return an unimplemented error. In doing so, a `fn main() {}` executable was ~378K before this patch, and about 170K after the patch. These size wins are all pretty minor, but they all seemed pretty reasonable to me. With native I/O not stubbed out, this takes the size of an LTO executable from 675K to 400K.
2014-02-28std: Flag run_fmt() as #[inline(always)]Alex Crichton-1/+8
This function is a tiny wrapper that LLVM doesn't want to inline, and it ends up causing more bloat than necessary. The bloat is pretty small, but it's a win of at least 7k for small executables, and I imagine that the number goes up as there are more calls to fail!().
2014-02-28std: Avoid using "{:?}" in format stringsAlex Crichton-5/+5
This removes all usage of Poly in format strings from libstd. This doesn't prevent more future strings from coming in, but it at least removes the ones for now.
2014-02-28std: Remove lots of allocations from log settingsAlex Crichton-102/+96
Most of these are unnecessary because we're only looking at static strings. This also moves to Vec in a few places instead of ~[T]. This didn't end up getting much of a code size win (update_log_settings is the third largest function in the executables I'm looking at), but this seems like a generally nice improvement regardless.