This includes new, tested, hygiene support functions. It also removes the interner_key! macro and replaces it with a function, which should be inline-able. It also contains some parser patch-ups and some docfixes.
On my machine, this patch passes all tests.
Currently, trait_info is a hashmap that allows a quick lookup of all
methods contained in a given trait, but we actually only use it to
lookup traits that contain a given method. Adjusting the map to support
the lookup we actually need gives a nice speed boost, reducing the time
required for the resolution step for librustc from ~2.6s to ~1.0s on my
box.
The function was a workaround for bootstrapping that isn't required
anymore and just degrades hashmap performance, as it doesn't get inlined
cross-crate and turns a no-op into a call.
The function was a workaround for bootstrapping that isn't required
anymore and just degrades hashmap performance, as it doesn't get inlined
cross-crate and turns a no-op into a call.
With this, the build is almost 100% warning free.
One more can be fixed after the next snapshot, and there's one other that I filed an issue about already.
Had a conversation with @cmr in IRC about some places that these
docs were confusing. The functions that advance the stream now say so.
In addition, I think that calling out the similarities to familliar C
functions should help people coming from other languages.
My earlier fix for #4202 would not work correctly if the trait being exported was a top-level item relative to the module from which it was being exported. An example that would not work correctly with the original patch:
// foo.rs
pub use Foo = self::Bar;
pub trait Bar {
pub fn bar() -> Self;
}
impl Bar for int {
pub fn bar() -> int { 42 }
}
// bar.rs
fn main() {
foo::Foo::bar()
}
This is now supported.
I believe this change will allow the GenericPath trait to be exported from core::path as Path in such a manner, which should allow #5389 to move forward.
Had a conversation with @cmr in IRC about some places that these
docs were confusing. The functions that advance the stream now say so.
In addition, I think that calling out the similarities to familliar C
functions should help people coming from other languages.
I don't have a strong opinion on the function vs. method, but there's no point in having both. I'd like to make a `repeat` adaptor like Python/Haskell for turning a value into an infinite stream of the value, so this has to at least be renamed.
