Fix#7322.
I started out with a band-aid approach to special-case the duplicate module error using `is_duplicate_module`, but thought this would be better in the long term.
The "first definition of ..." error string reported by add_child() looks
different from similar messages reported by other functions. Fix this.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
add_child() is responsible for reporting errors about type, value, and
module duplicate definitions. Although it checks for all three, it uses
namespace_to_str() to convert a Namespace value into a string before
printing an error like:
error: duplicate definition of type `foo`
^^^^
note: first definition of type foo here:
^^^^
Unfortunately, this string can only be one of "type" or
"value" (corresponding to TypeNS and ValueNS respectively), and it
reports duplicate modules as duplicate types.
To alleviate the problem, define a special NamespaceError enum to define
more specialized errors, and use it instead of attempting to reuse the
Namespace enum.
Reported-by: Corey Richardson <corey@octayn.net>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
This adds a `#[no_drop_flag]` attribute. This attribute tells the compiler to omit the drop flag from the struct, if it has a destructor. When the destructor is run, instead of setting the drop flag, it instead zeroes-out the struct. This means the destructor can run multiple times and therefore it is up to the developer to use it safely.
The primary usage case for this is smart-pointer types like `Rc<T>` as the extra flag caused the struct to be 1 word larger because of alignment.
This closes#7271 and #7138
This sets the `get_tydesc()` return type correctly and removes the intrinsic module. See #3730, #3475.
Update: this now also removes the unused shape fields in tydescs.
This adds both `static mut` items and `static mut` foreign items. This involved changing far less code than I thought it was going to, but the tests seem to pass and the variables seem functional.
I'm more than willing to write more tests, so suggestions are welcome!
Closes#553
This PR fixes a few problems with the benchmark, mentioned in #2913. Since I do not have a 4GB RAM machine (I run rust on a puny 2GB RAM VM) I can't test binarytrees with N=20. If it works we can close#2913.
Fixes: 1) binarytrees prints "long lived trees of depth" instead of "long lived tree of depth"
Fixes: 2) chameneosredux -- the whitespace printed by show_number should be the same as printed by show_color
Already fixed: 3) spectralnorm prints an extra
Fixes: 4) threadring prints an extra
Fixes: 5) fasta -- strangely, output stops half-way through line 169 -- with another 8166 lines still to do.
Could not test: 6) the latest binarytrees fails with input N=20 on a 4GB machine.
r?
flat_map_ produces an iterator that maps each element to an iterator,
and yields the elements of the produced iterators.
This is the monadic bind :: M a -> (a -> M b) -> M b for iterators.
Named just like the vec method, but with a trailing underline until the
method resolution bug is resolved.
the `test/run-pass/class-trait-bounded-param.rs` test was xfailed and
written in an ancient dialect of Rust so I've just removed it
this also removes `to_vec` from DList because it's provided by
`std::iter::to_vec`
an Iterator implementation is added for OptVec but some transitional
internal iterator methods are still left
This pull request contains an unoptimized implementation of most of the SHA-2 functions (everything but the variable output size versions). I also created a common trait (Digest) for all of the interesting methods for working with digests and updated the existing SHA-1 code to use it. Finally, while working with the SHA-1 code, I got rid of the use of @ types and type objects.
I've tested all functions against the Wikipedia test vectors. Additionally, I tested the SHA-512, 384, and 256 variants against the Java implementations of those digests.
I did my best to try to follow Rust conventions, but, there are so many different conventions in the code base right now that I'm not sure if I'm following the correct one or not. Anyway, I'm happy to rework if I didn't get the coding convention right (or if there are bugs!).
