Performing a deep copy isn't ever desired for a persistent data
structure, and it requires a more complex implementation to do
correctly. A deep copy needs to check for cycles to avoid an infinite
loop.
Performing a deep copy isn't ever desired for a persistent data
structure, and it requires a more complex implementation to do
correctly. A deep copy needs to check for cycles to avoid an infinite
loop.
Addresses #5544 and #5770, as well as a comment left in the documentation of `from_str_bytes_common`, so that there is now an option to ignore underscores.
A number like 0b1_1111_1111 == 511 would be parsed to Some(255u8) rather than None
by from_str_common, since 255 * 2 + 1 == 255 (mod 256) so the overflow wasn't detected.
Only applied to conversions where the radix was a power of 2, and where all digits
repeated.
Closes#5770.
Currently error messages say ``mismatched types: expected `uint` but found `[uint * 10]` (expected uint but found vector)`` rather than `[uint, .. 10]`.
r? @brson In my WIP on rustpkg, I was calling driver code that calls
LLVMRustWriteOutputFile more than once. This was making LLVM
unhappy, since that function has code that initializes the
command-line options for LLVM, and I guess you can't do that more
than once. So, check if they've already been initialized.
This adds two generic data types, `Ratio` and `Cmplx` (and some aliases for useful instances, e.g. `Ratio<int>` and `Cmplx<f64>`), and basic arithmetic support, as well as `.to_str` (for both) and `.from_str` (for rational).
The complex number implementation doesn't solve #1284 other than getting something into the libraries, specifically it doesn't even try to address C interop. If the complex part of this gets merged, maybe it's worth closing that issue and reopening more specific issue(s) about the failings.
The implementations can be fleshed out when the numeric traits stabilise (and trait inheritance works).
This is some stuff which seemed to be missing to me (though I haven't read everything yet so hope I haven't missed the relevant section).
A similar addition for borrowing handles is needed, but #5720 stumped me.
Comments welcome.
In my WIP on rustpkg, I was calling driver code that calls
LLVMRustWriteOutputFile more than once. This was making LLVM
unhappy, since that function has code that initializes the
command-line options for LLVM, and I guess you can't do that more
than once. So, check if they've already been initialized.
bare function store (which is not in fact a kind of value) but rather
ty::TraitRef. Removes many uses of fail!() and other telltale signs of
type-semantic mismatch.
cc #4183 (not a fix, but related)
