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.)
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#8242Closes#9806
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
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
This is PR is the beginning of a complete rewrite and ultimate removal of the `std::num::strconv` module (see #6220), and the removal of the `ToStrRadix` trait in favour of using the `std::fmt` functionality directly. This should make for a cleaner API, encourage less allocation, and make the implementation more comprehensible .
The `Formatter::{pad_integral, with_padding}` methods have also been refactored make things easier to understand.
The formatting tests for integers have been moved out of `run-pass/ifmt.rs` in order to provide more immediate feedback when building using `make check-stage2-std NO_REBUILD=1`.
Arbitrary radixes are now easier to use in format strings. For example:
~~~rust
assert_eq!(format!("{:04}", radix(3, 2)), ~"0011");
~~~
The benchmarks have been standardised between `std::num::strconv` and `std::num::fmt` to make it easier to compare the performance of the different implementations.
~~~
type | radix | std::num::strconv | std::num::fmt
======|=======|========================|======================
int | bin | 1748 ns/iter (+/- 150) | 321 ns/iter (+/- 25)
int | oct | 706 ns/iter (+/- 53) | 179 ns/iter (+/- 22)
int | dec | 640 ns/iter (+/- 59) | 207 ns/iter (+/- 10)
int | hex | 637 ns/iter (+/- 77) | 205 ns/iter (+/- 19)
int | 36 | 446 ns/iter (+/- 30) | 309 ns/iter (+/- 20)
------|-------|------------------------|----------------------
uint | bin | 1724 ns/iter (+/- 159) | 322 ns/iter (+/- 13)
uint | oct | 663 ns/iter (+/- 25) | 175 ns/iter (+/- 7)
uint | dec | 613 ns/iter (+/- 30) | 186 ns/iter (+/- 6)
uint | hex | 519 ns/iter (+/- 44) | 207 ns/iter (+/- 20)
uint | 36 | 418 ns/iter (+/- 16) | 308 ns/iter (+/- 32)
~~~
This is in preparation to remove the implementations of ToStrRadix in integers, and to remove the associated logic from `std::num::strconv`.
The parts that still need to be liberated are:
- `std::fmt::Formatter::runplural`
- `num::{bigint, complex, rational}`
This works towards a complete rewrite and ultimate removal of the `std::num::strconv` module (see #6220), and the removal of the `ToStrRadix` trait in favour of using the `std::fmt` functionality directly. This should make for a cleaner API, encourage less allocation, and make the implementation far more comprehensible.
The `Formatter::pad_integral` method has also been refactored make it easier to understand.
The formatting tests for integers have been moved out of `run-pass/ifmt.rs` in order to provide more immediate feedback when building using `make check-stage2-std NO_REBUILD=1`.
The benchmarks have been standardised between std::num::strconv and std::num::fmt to make it easier to compare the performance of the different implementations.
Arbitrary radixes are now easier to use in format strings. For example:
~~~
assert_eq!(format!("{:04}", radix(3, 2)), ~"0011");
~~~
The previous code erroneously assumed that 'steals > cnt' was always true, but
that was a false assumption. The code was altered to decrement steals to a
minimum of 0 instead of taking all of cnt into account.
I didn't include the exact test from #12295 because it could run for quite
awhile, and instead set the threshold for MAX_STEALS to much lower during
testing. I found that this triggered the old bug quite frequently when running
without this fix.
Closes#12295
`Times::times` was always a second-class loop because it did not support the `break` and `continue` operations. Its playful appeal (which I liked) was then lost after `do` was disabled for closures. It's time to let this one go.
`Times::times` was always a second-class loop because it did not support the `break` and `continue` operations. Its playful appeal was then lost after `do` was disabled for closures. It's time to let this one go.
The implementation has been made more succinct and no longer requires Clone. The coverage of the associated unit test has also been increased to check more combinations of bases, exponents, and expected results.
There was an old and barely used implementation of pow, which expected
both parameters to be uint and required more traits to be implemented.
Since a new implementation for `pow` landed, I'm proposing to remove
this old impl in favor of the new one.
The benchmark shows that the new implementation is faster than the one
being removed:
test num::bench::bench_pow_function ..bench: 9429 ns/iter (+/- 2055)
test num::bench::bench_pow_with_uint_function ...bench: 28476 ns/iter (+/- 2202)
As part of #10387, this removes the `Primitive::{bits, bytes, is_signed}` methods and removes the trait's operator trait constraints for the reasons outlined below:
- The `Primitive::{bits, bytes}` associated functions were originally added to reflect the existing `BITS` and `BYTES`statics included in the numeric modules. These statics are only exist as a workaround for Rust's lack of CTFE, and should be deprecated in the future in favor of using the `std::mem::size_of` function (see #11621).
- `Primitive::is_signed` seems to be of little utility and does not seem to be used anywhere in the Rust compiler or libraries. It is also rather ugly to call due to the `Option<Self>` workaround for #8888.
- The operator trait constraints are already covered by the `Num` trait.
This removes the `Primitive::{bits, bytes, is_signed}` methods and removes the operator trait constraints, for the reasons outlined below:
- The `Primitive::{bits, bytes}` associated functions were originally added to reflect the existing `BITS` and `BYTES` statics included in the numeric modules. These statics are only exist as a workaround for Rust's lack of CTFE, and should probably be deprecated in the future in favor of using the `std::mem::size_of` function (see #11621).
- `Primitive::is_signed` seems to be of little utility and does not seem to be used anywhere in the Rust compiler or libraries. It is also rather ugly to call due to the `Option<Self>` workaround for #8888.
- The operator trait constraints are already covered by the `Num` trait.
The patch adds a `pow` function for types implementing `One`, `Mul` and
`Clone` trait.
The patch also renames f32 and f64 pow into powf in order to still have
a way to easily have float powers. It uses llvms intrinsics.
The pow implementation for all num types uses the exponentiation by
square.
Fixes bug #11499
These functions are of little utility outside a small subset of use cases. If people need them for their own projects then they can use their own bindings for libm (which aren't hard to make).
The methods contained in `std::num::{Algebraic, Trigonometric, Exponential, Hyperbolic}` have now been moved into `std::num::Real`. This is part of an ongoing effort to simplify `std::num` (see issue #10387).
`std::num::RealExt` has also been removed from the prelude because it is not a commonly used trait.
r? @alexcrichton
The methods contained in `std::num::{Algebraic, Trigonometric, Exponential, Hyperbolic}` have now been moved into `std::num::Real`. This is part of an ongoing effort to simplify `std::num` (see issue #10387).
`std::num::RealExt` has also been removed from the prelude because it is not a commonly used trait.
This commit uniforms the short title of modules provided by libstd,
in order to make their roles more explicit when glancing at the index.
Signed-off-by: Luca Bruno <lucab@debian.org>
The `integer_decode()` function decodes a float (f32/f64)
into integers containing the mantissa, exponent and sign.
It's needed for `rationalize()` implementation of #9838.
The code got ported from ABCL [1].
[1] http://abcl.org/trac/browser/trunk/abcl/src/org/armedbear/lisp/FloatFunctions.java?rev=14465#L94
I got the permission to use this code for Rust from Peter Graves (the ABCL copyright holder) . If there's any further IP clearance needed, let me know.
This function had type &[u8] -> ~str, i.e. it allocates a string
internally, even though the non-allocating version that take &[u8] ->
&str and ~[u8] -> ~str are all that is necessary in most circumstances.
These two attributes are no longer useful now that Rust has decided to leave
segmented stacks behind. It is assumed that the rust task's stack is always
large enough to make an FFI call (due to the stack being very large).
There's always the case of stack overflow, however, to consider. This does not
change the behavior of stack overflow in Rust. This is still normally triggered
by the __morestack function and aborts the whole process.
C stack overflow will continue to corrupt the stack, however (as it did before
this commit as well). The future improvement of a guard page at the end of every
rust stack is still unimplemented and is intended to be the mechanism through
which we attempt to detect C stack overflow.
Closes#8822Closes#10155
New standards have arisen in recent months, mostly for the use of
rustpkg, but the main Rust codebase has not been altered to match these
new specifications. This changeset rectifies most of these issues.
- Renamed the crate source files `src/libX/X.rs` to `lib.rs`, for
consistency with current styles; this affects extra, rustc, rustdoc,
rustpkg, rustuv, std, syntax.
- Renamed `X/X.rs` to `X/mod.rs,` as is now recommended style, for
`std::num` and `std::terminfo`.
- Shifted `src/libstd/str/ascii.rs` out of the otherwise unused `str`
directory, to be consistent with its import path of `std::ascii`;
libstd is flat at present so it's more appropriate thus.
While this removes some `#[path = "..."]` directives, it does not remove
all of them, and leaves certain other inconsistencies, such as `std::u8`
et al. which are actually stored in `src/libstd/num/` (one subdirectory
down). No quorum has been reached on this issue, so I felt it best to
leave them all alone at present. #9208 deals with the possibility of
making libstd more hierarchical (such as changing the crate to match the
current filesystem structure, which would make the module path
`std::num::u8`).
There is one thing remaining in which this repository is not
rustpkg-compliant: rustpkg would have `src/std/` et al. rather than
`src/libstd/` et al. I have not endeavoured to change that at this point
as it would guarantee prompt bitrot and confusion. A change of that
magnitude needs to be discussed first.
Allows an enum with a discriminant to use any of the primitive integer types to store it. By default the smallest usable type is chosen, but this can be overridden with an attribute: `#[repr(int)]` etc., or `#[repr(C)]` to match the target's C ABI for the equivalent C enum.
Also adds a lint pass for using non-FFI safe enums in extern declarations, checks that specified discriminants can be stored in the specified type if any, and fixes assorted code that was assuming int.
Otherwise, run-pass/deriving-primitive.rs breaks on 32-bit platforms,
because `int::min_value` is `0xffffffff7fffffff` when evaluated for the
discriminant declaration.
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!).
One downside with this current implementation is that since BigInt's
default is now 64 bit, we can convert larger BigInt's to a primitive,
however the current implementation on 32 bit architectures does not
take advantage of this fact.
It is simply defined as `f64` across every platform right now.
A use case hasn't been presented for a `float` type defined as the
highest precision floating point type implemented in hardware on the
platform. Performance-wise, using the smallest precision correct for the
use case greatly saves on cache space and allows for fitting more
numbers into SSE/AVX registers.
If there was a use case, this could be implemented as simply a type
alias or a struct thanks to `#[cfg(...)]`.
Closes#6592
The mailing list thread, for reference:
https://mail.mozilla.org/pipermail/rust-dev/2013-July/004632.html
Also, documentation & general clean-up:
- remove `gen_char_from`: better served by `sample` or `choose`.
- `gen_bytes` generalised to `gen_vec`.
- `gen_int_range`/`gen_uint_range` merged into `gen_integer_range` and
made to be properly uniformly distributed. Fixes#8644.
Minor adjustments to other functions.
This large commit implements and `html` output option for rustdoc_ng. The
executable has been altered to be invoked as "rustdoc_ng html <crate>" and
it will dump everything into the local "doc" directory. JSON can still be
generated by changing 'html' to 'json'.
This also fixes a number of bugs in rustdoc_ng relating to comment stripping,
along with some other various issues that I found along the way.
The `make doc` command has been altered to generate the new documentation into
the `doc/ng/$(CRATE)` directories.
This is for consistency in naming conventions.
- ``std::num::Float::NaN()`` is changed to ``nan()``;
- ``std::num::Float.is_NaN()`` is changed to ``is_nan()``; and
- ``std::num::strconv::NumStrConv::NaN()`` is changed to ``nan()``.
Fixes#9319.
This is my first contribution, so please point out anything that I may have missed.
I consulted IRC and settled on `match () { ... }` for most of the replacements.
Like issue #9209, remove float::{from_str, from_str_radix} in favor of
the two corresponding traits. The same for modules f64 and f32.
New usage is
from_str::<float>("1.2e34")
Remove these in favor of the two traits themselves and the wrapper
function std::from_str::from_str.
Add the function std::num::from_str_radix in the corresponding role for
the FromStrRadix trait.
Here's a fix for issue #7588, "Overflow handling of from_str methods is broken".
The integer overflow issues are taken care of by checking to see if the multiply-by-radix-and-add-next-digit process is reversible. If it overflowed, then some information is lost and the process is irreversible, in which case, None is returned.
Floats now consistently return Some(Inf) of Some(-Inf) on overflow thanks to a call to NumStrConv::inf() and NumStrConv::neg_inf() respectively when the overflow is detected (which yields a value of None in the case of ints and uints anyway).
This is my first contribution to Rust, and my first time using the language in general, so any and all feedback is appreciated.
Summary:
-removed "ne" methods in libstd and librustpkg
-made default "ne" be inlined
-made one of the "eq" methods in librustpkg follow more standard parameter naming convention
This removes the stacking of type parameters that occurs when invoking
trait methods, and fixes all places in the standard library that were
relying on it. It is somewhat awkward in places; I think we'll probably
want something like the `Foo::<for T>::new()` syntax.
Basically, generic containers should not use the default methods since a
type of elements may not guarantees total order. str could use them
since u8's Ord guarantees total order. Floating point numbers are also
broken with the default methods because of NaN. Thanks for @thestinger.
Timespec also guarantees total order AIUI. I'm unsure whether
extra::semver::Identifier does so I left it alone. Proof needed.
Signed-off-by: OGINO Masanori <masanori.ogino@gmail.com>
- Made naming schemes consistent between Option, Result and Either
- Changed Options Add implementation to work like the maybe monad (return None if any of the inputs is None)
- Removed duplicate Option::get and renamed all related functions to use the term `unwrap` instead
Change the former repetition::
for 5.times { }
to::
do 5.times { }
.times() cannot be broken with `break` or `return` anymore; for those
cases, use a numerical range loop instead.
The free-standing functions in f32, f64, i8, i16, i32, i64, u8, u16,
u32, u64, float, int, and uint are replaced with generic functions in
num instead.
If you were previously using any of those functions, just replace them
with the corresponding function with the same name in num.
Note: If you were using a function that corresponds to an operator, use
the operator instead.
Continuation of #7430.
I haven't removed the `map` method, since the replacement `v.iter().transform(f).collect::<~[SomeType]>()` is a little ridiculous at the moment.
This works with pandoc linked against highlighting-kate >= 0.5.3.8. It seems to just be a no-op with earlier versions, because I successfully ran this through `try`.
This also fixes some consistency issues (like making `Example`/`Examples` always a header and always using three tildes).
There were several old `#[doc(hidden)]` attributes in libstd and
libextra, left over from when rustdoc didn't hide private
definitions, tagged with `FIXME #3538`.
Since #3538 is now closed, I removed the `#[doc(hidden)]` attributes
as well as the FIXMEs, but I left `#[doc(hidden)]` in
libstd/task/spawn.rs and libstd/task/rt.rs since those two are
apparently `pub`, as well as in libextra/std.rc since std/extra is
`pub`.
`std::ratio` module contains `BigRational` type, but the type is not usable by following reasons.
* `Ratio::new` requires `T: Copy + Num + Ord`, but `BigInt` is not implicitly copyable, because it contains unique vector.
* `BigInt` is not implements `Num`
So, I rewrite `Ratio` as follows.
* `Ratio` requires `T: Clone + Integer + Ord`.
* `Copy` -> `Clone`: to be able to use `BigRational`
* `Num` -> `Integer`: It is incorrect that a rational number constructed by two non-integer numbers.
* `BigInt` implements `Num` and `Orderable` which are required by `Integer` bound
fail!() used to require owned strings but can handle static strings
now. Also, it can pass its arguments to fmt!() on its own, no need for
the caller to call fmt!() itself.
`std::bigint` contains the following code.
```rust
borrow = *elem << (uint::bits - n_bits);
```
The code above contains a bug that the value of the right operand of the shift operator exceeds the size of the left operand,
because sizeof(*elem) == 32, and 0 <= n_bits < 32 in 64bit architecture.
If `--opt-level` option is not given to rustc, the code above runs as if the right operand is `(uint::bits - n_bits) % 32`,
but if --opt-level is given, `borrow` is always zero.
I wonder why this bug is not catched in the libstd's testsuite (I try the `rustc --test --opt-level=2 bigint.rs` before fixing the bug,
but the unittest passes normally.)
This pull request also removes the implicit vector copies in `bigint.rs`.
borrow = *elem << (uint::bits - n_bits);
The code above contains a bug that the value of the right operand of the shift operator exceeds the size of the left operand,
because sizeof(*elem) == 32, and 0 <= n_bits < 32 in 64bit architecture.
If `--opt-level` option is not given to rustc, the code above runs as if the right operand is `(uint::bits - n_bits) % 32`,
but if --opt-level is given, `borrow` is always zero.
I wonder why this bug is not catched in the libstd's testsuite (I try the `rustc --test --opt-level=2 bigint.rs` before fixing the bug,
but the unittest passes normally.)
Closes#3083.
This takes a similar approach to #5797 where a set is present on the `tcx` of used mutable definitions. Everything is by default warned about, and analyses must explicitly add mutable definitions to this set so they're not warned about.
Most of this was pretty straightforward, although there was one caveat that I ran into when implementing it. Apparently when the old modes are used (or maybe `legacy_modes`, I'm not sure) some different code paths are taken to cause spurious warnings to be issued which shouldn't be issued. I'm not really sure how modes even worked, so I was having a lot of trouble tracking this down. I figured that because they're a legacy thing that I'd just de-mode the compiler so that the warnings wouldn't be a problem anymore (or at least for the compiler).
Other than that, the entire compiler compiles without warnings of unused mutable variables. To prevent bad warnings, #5965 should be landed (which in turn is waiting on #5963) before landing this. I figured I'd stick it out for review anyway though.
