about summary refs log tree commit diff
path: root/src/libstd/num
AgeCommit message (Collapse)AuthorLines
2014-05-07core: Add unwrap()/unwrap_err() methods to ResultAlex Crichton-0/+3
These implementations must live in libstd right now because the fmt module has not been migrated yet. This will occur in a later PR. Just to be clear, there are new extension traits, but they are not necessary once the std::fmt module has migrated to libcore, which is a planned migration in the future.
2014-05-07core: Inherit the specific numeric modulesAlex Crichton-1506/+77
This implements all traits inside of core::num for all the primitive types, removing all the functionality from libstd. The std modules reexport all of the necessary items from the core modules.
2014-05-07core: Inherit what's possible from the num moduleAlex Crichton-849/+15
This strips out all string-related functionality from the num module. The inherited functionality is all that will be implemented in libcore (for now). Primarily, libcore will not implement the Float trait or any string-related functionality. It may be possible to migrate string parsing functionality into libcore in the future, but for now it will remain in libstd. All functionality in core::num is reexported in std::num.
2014-05-03Add lint check for negating uint literals and variables.Falco Hirschenberger-0/+7
See #11273 and #13318
2014-04-27Rewrote documentation for parse_bytes and to_str_bytes in {int, uint}_macros.rsJacob Hegna-10/+28
2014-04-24add min_pos_value constant for floatsAaron Turon-19/+40
Follow-up on issue #13297 and PR #13710. Instead of following the (confusing) C/C++ approach of using `MIN_VALUE` for the smallest *positive* number, we introduce `MIN_POS_VALUE` (and in the Float trait, `min_pos_value`) to represent this number. This patch also removes a few remaining redundantly-defined constants that were missed last time around.
2014-04-23fix std::f32 and std::f64 constantsAaron Turon-75/+94
Some of the constant values in std::f32 were incorrectly copied from std::f64. More broadly, both modules defined their constants redundantly in two places, which is what led to the bug. Moreover, the specs for some of the constants were incorrent, even when the values were correct. Closes #13297. Closes #11537.
2014-04-23auto merge of #13694 : jacob-hegna/rust/master, r=brsonbors-0/+20
... and uint_macros.rs
2014-04-22auto merge of #13597 : bjz/rust/float-api, r=brsonbors-429/+523
This pull request: - Merges the `Round` trait into the `Float` trait, continuing issue #10387. - Has floating point functions take their parameters by value. - Cleans up the formatting and organisation in the definition and implementations of the `Float` trait. More information on the breaking changes can be found in the commit messages.
2014-04-22Removed trailing whitespace in on line 242 in int_macros.rs and on line 156 ↵Jacob Hegna-3/+3
in uint_macros.rs
2014-04-22Added examples for parse_bytes(buf: &[u8], radix: uint) in int_macros.rs and ↵Jacob Hegna-0/+20
uint_macros.rs
2014-04-20auto merge of #13410 : alexcrichton/rust/issue-12278, r=pcwaltonbors-2/+8
This commit removes the compiler support for floating point modulus operations, as well as from the language. An implementation for this operator is now required to be provided by libraries. Floating point modulus is rarely used, doesn't exist in C, and is always lowered to an fmod library call by LLVM, and LLVM is considering removing support entirely. Closes #12278
2014-04-19auto merge of #13614 : cgaebel/rust/master, r=brsonbors-0/+6
We previously allocated 3x for every HashMap creation and resize. This patch reduces it to 1x.
2014-04-19Reorder Float methods in trait definition and make consistent in implsBrendan Zabarauskas-293/+268
2014-04-19Fix formatting in float implementationsBrendan Zabarauskas-72/+198
2014-04-19Have floating point functions take their parameters by value.Brendan Zabarauskas-154/+154
Make all of the methods in `std::num::Float` take `self` and their other parameters by value. Some of the `Float` methods took their parameters by value, and others took them by reference. This standardises them to one convention. The `Float` trait is intended for the built in IEEE 754 numbers only so we don't have to worry about the trait serving types of larger sizes. [breaking-change]
2014-04-19Merge the Round trait into the Float traitBrendan Zabarauskas-77/+70
Move the rounding functions into the `std::num::Float` trait and then remove `std::num::Round`. This continues the flattening of the numeric traits tracked in #10387. The aim is to make `std::num` very simple and tied to the built in types, leaving the definition of more complex numeric towers to third-party libraries. [breaking-change]
2014-04-18Replace all ~"" with "".to_owned()Richo Healey-28/+30
2014-04-18Reduce HashMap allocations.Clark Gaebel-0/+6
2014-04-18std: Make ~[T] no longer a growable vectorAlex Crichton-26/+27
This removes all resizability support for ~[T] vectors in preparation of DST. The only growable vector remaining is Vec<T>. In summary, the following methods from ~[T] and various functions were removed. Each method/function has an equivalent on the Vec type in std::vec unless otherwise stated. * slice::OwnedCloneableVector * slice::OwnedEqVector * slice::append * slice::append_one * slice::build (no replacement) * slice::bytes::push_bytes * slice::from_elem * slice::from_fn * slice::with_capacity * ~[T].capacity() * ~[T].clear() * ~[T].dedup() * ~[T].extend() * ~[T].grow() * ~[T].grow_fn() * ~[T].grow_set() * ~[T].insert() * ~[T].pop() * ~[T].push() * ~[T].push_all() * ~[T].push_all_move() * ~[T].remove() * ~[T].reserve() * ~[T].reserve_additional() * ~[T].reserve_exect() * ~[T].retain() * ~[T].set_len() * ~[T].shift() * ~[T].shrink_to_fit() * ~[T].swap_remove() * ~[T].truncate() * ~[T].unshift() * ~str.clear() * ~str.set_len() * ~str.truncate() Note that no other API changes were made. Existing apis that took or returned ~[T] continue to do so. [breaking-change]
2014-04-15std: Un-ignore some float tests on windowsAlex Crichton-2/+2
These were fixed in the upgrade from mingw32 to mingw64. Closes #8663
2014-04-15Use the unsigned integer types for bitwise intrinsics.Huon Wilson-12/+12
Exposing ctpop, ctlz, cttz and bswap as taking signed i8/i16/... is just exposing the internal LLVM names pointlessly (LLVM doesn't have "signed integers" or "unsigned integers", it just has sized integer types with (un)signed *operations*). These operations are semantically working with raw bytes, which the unsigned types model better.
2014-04-13auto merge of #13470 : Manishearth/rust/docnum, r=brsonbors-0/+4
See #7511
2014-04-12Document traits in std::num (#7511)Manish Goregaokar-0/+4
2014-04-11libtest: rename `BenchHarness` to `Bencher`Liigo Zhuang-27/+27
Closes #12640
2014-04-08rustc: Remove f{32,64} % from the languageAlex Crichton-2/+8
This commit removes the compiler support for floating point modulus operations, as well as from the language. An implementation for this operator is now required to be provided by libraries. Floating point modulus is rarely used, doesn't exist in C, and is always lowered to an fmod library call by LLVM, and LLVM is considering removing support entirely. Closes #12278
2014-04-04Removed cmath and instrinsic wrapper.Michael Darakananda-205/+84
2014-04-02Fix fallout of requiring uint indicesAlex Crichton-8/+8
2014-04-01auto merge of #13225 : thestinger/rust/num, r=cmrbors-276/+126
The `Float` trait methods will be usable as functions via UFCS, and we came to a consensus to remove duplicate functions like this a long time ago. It does still make sense to keep the duplicate functions when the trait methods are static, unless the decision to leave out the in-scope trait name resolution for static methods changes.
2014-04-01auto merge of #13115 : huonw/rust/rand-errors, r=alexcrichtonbors-11/+11
move errno -> IoError converter into std, bubble up OSRng errors Also adds a general errno -> `~str` converter to `std::os`, and makes the failure messages for the things using `OSRng` (e.g. (transitively) the task-local RNG, meaning hashmap initialisation failures aren't such a black box).
2014-04-01remove the cmath moduleDaniel Micay-203/+126
This is an implementation detail of the `f32` and `f64` modules and it should not be public. It renames many functions and leaves out any provided by LLVM intrinsics, so it is not a sensible binding to the C standard library's math library and will never be a stable target. This also removes the abuse of link_name so that this can be switched to using automatically generated definitions in the future. This also removes the `scalbn` binding as it is equivalent to `ldexp` when `FLT_RADIX` is 2, which must always be true for Rust.
2014-04-01rand: bubble up IO messages futher.Huon Wilson-11/+11
The various ...Rng::new() methods can hit IO errors from the OSRng they use, and it seems sensible to expose them at a higher level. Unfortunately, writing e.g. `StdRng::new().unwrap()` gives a much poorer error message than if it failed internally, but this is a problem with all `IoResult`s.
2014-03-31num: rm wrapping of `Float` methods as functionsDaniel Micay-73/+0
The `Float` trait methods will be usable as functions via UFCS, and we came to a consensus to remove duplicate functions like this a long time ago. It does still make sense to keep the duplicate functions when the trait methods are static, unless the decision to leave out the in-scope trait name resolution for static methods changes.
2014-03-28Convert most code to new inner attribute syntax.Brian Anderson-22/+22
Closes #2569
2014-03-28Rename Pod into CopyFlavio Percoco-2/+2
Summary: So far, we've used the term POD "Plain Old Data" to refer to types that can be safely copied. However, this term is not consistent with the other built-in bounds that use verbs instead. This patch renames the Pod kind into Copy. RFC: 0003-opt-in-builtin-traits Test Plan: make check Reviewers: cmr Differential Revision: http://phabricator.octayn.net/D3
2014-03-25std: Touch various I/O documentation blocksAlex Crichton-5/+5
These are mostly touchups from the previous commit.
2014-03-25libstd: Document the following modules:Patrick Walton-46/+183
* native::io * std::char * std::fmt * std::fmt::parse * std::io * std::io::extensions * std::io::net::ip * std::io::net::udp * std::io::net::unix * std::io::pipe * std::num * std::num::f32 * std::num::f64 * std::num::strconv * std::os
2014-03-20rename std::vec -> std::sliceDaniel Micay-4/+4
Closes #12702
2014-03-08Removed DeepClone. Issue #12698.Michael Darakananda-2/+1
2014-03-05add tests for `min` and `max` from `Float`Daniel Micay-0/+24
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-02-28std: Change assert_eq!() to use {} instead of {:?}Alex Crichton-3/+3
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-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-24Remove std::num::ToStrRadix from the preludeBrendan Zabarauskas-1/+3
2014-02-24Remove std::from_str::FromStr from the preludeBrendan Zabarauskas-0/+12
2014-02-24auto merge of #12445 : huonw/rust/less-unsafe, r=alexcrichtonbors-8/+4
Commits for details. Highlights: - `flate` returns `CVec<u8>` to save reallocating a whole new `&[u8]` - a lot of `transmute`s removed outright or replaced with `as` (etc.)
2014-02-23Remove all ToStr impls, add Show implsAlex Crichton-28/+0
This commit changes the ToStr trait to: impl<T: fmt::Show> ToStr for T { fn to_str(&self) -> ~str { format!("{}", *self) } } The ToStr trait has been on the chopping block for quite awhile now, and this is the final nail in its coffin. The trait and the corresponding method are not being removed as part of this commit, but rather any implementations of the `ToStr` trait are being forbidden because of the generic impl. The new way to get the `to_str()` method to work is to implement `fmt::Show`. Formatting into a `&mut Writer` (as `format!` does) is much more efficient than `ToStr` when building up large strings. The `ToStr` trait forces many intermediate allocations to be made while the `fmt::Show` trait allows incremental buildup in the same heap allocated buffer. Additionally, the `fmt::Show` trait is much more extensible in terms of interoperation with other `Writer` instances and in more situations. By design the `ToStr` trait requires at least one allocation whereas the `fmt::Show` trait does not require any allocations. Closes #8242 Closes #9806
2014-02-24arena,std,serialize: remove some unnecessary transmutes.Huon Wilson-8/+4
`as`-able transmutes, duplication and manual slice decomposition are silly.
2014-02-23auto merge of #12416 : alexcrichton/rust/highlight, r=huonwbors-2/+2
This adds simple syntax highlighting based off libsyntax's lexer to be sure to stay up to date with rust's grammar. Some of the highlighting is a bit ad-hoc, but it definitely seems to get the job done! This currently doesn't highlight rustdoc-rendered function signatures and structs that are emitted to each page because the colors already signify what's clickable and I think we'd have to figure out a different scheme before colorizing them. This does, however, colorize all code examples and source code. Closes #11393