rust - https://github.com/rust-lang/rust

Age	Commit message (Collapse)	Author	Lines
2015-01-07	rollup merge of #20707: nikomatsakis/issue-20582	Alex Crichton	-2/+2

2015-01-07	rollup merge of #20721: japaric/snap	Alex Crichton	-19/+19
	Conflicts: src/libcollections/vec.rs src/libcore/fmt/mod.rs src/librustc/lint/builtin.rs src/librustc/session/config.rs src/librustc_trans/trans/base.rs src/librustc_trans/trans/context.rs src/librustc_trans/trans/type_.rs src/librustc_typeck/check/_match.rs src/librustdoc/html/format.rs src/libsyntax/std_inject.rs src/libsyntax/util/interner.rs src/test/compile-fail/mut-pattern-mismatched.rs
2015-01-07	rollup merge of #20654: alexcrichton/stabilize-hash	Alex Crichton	-38/+41
	This commit aims to prepare the `std::hash` module for alpha by formalizing its current interface whileholding off on adding `#[stable]` to the new APIs. The current usage with the `HashMap` and `HashSet` types is also reconciled by separating out composable parts of the design. The primary goal of this slight redesign is to separate the concepts of a hasher's state from a hashing algorithm itself. The primary change of this commit is to separate the `Hasher` trait into a `Hasher` and a `HashState` trait. Conceptually the old `Hasher` trait was actually just a factory for various states, but hashing had very little control over how these states were used. Additionally the old `Hasher` trait was actually fairly unrelated to hashing. This commit redesigns the existing `Hasher` trait to match what the notion of a `Hasher` normally implies with the following definition: trait Hasher { type Output; fn reset(&mut self); fn finish(&self) -> Output; } This `Hasher` trait emphasizes that hashing algorithms may produce outputs other than a `u64`, so the output type is made generic. Other than that, however, very little is assumed about a particular hasher. It is left up to implementors to provide specific methods or trait implementations to feed data into a hasher. The corresponding `Hash` trait becomes: trait Hash<H: Hasher> { fn hash(&self, &mut H); } The old default of `SipState` was removed from this trait as it's not something that we're willing to stabilize until the end of time, but the type parameter is always required to implement `Hasher`. Note that the type parameter `H` remains on the trait to enable multidispatch for specialization of hashing for particular hashers. Note that `Writer` is not mentioned in either of `Hash` or `Hasher`, it is simply used as part `derive` and the implementations for all primitive types. With these definitions, the old `Hasher` trait is realized as a new `HashState` trait in the `collections::hash_state` module as an unstable addition for now. The current definition looks like: trait HashState { type Hasher: Hasher; fn hasher(&self) -> Hasher; } The purpose of this trait is to emphasize that the one piece of functionality for implementors is that new instances of `Hasher` can be created. This conceptually represents the two keys from which more instances of a `SipHasher` can be created, and a `HashState` is what's stored in a `HashMap`, not a `Hasher`. Implementors of custom hash algorithms should implement the `Hasher` trait, and only hash algorithms intended for use in hash maps need to implement or worry about the `HashState` trait. The entire module and `HashState` infrastructure remains `#[unstable]` due to it being recently redesigned, but some other stability decision made for the `std::hash` module are: * The `Writer` trait remains `#[experimental]` as it's intended to be replaced with an `io::Writer` (more details soon). * The top-level `hash` function is `#[unstable]` as it is intended to be generic over the hashing algorithm instead of hardwired to `SipHasher` * The inner `sip` module is now private as its one export, `SipHasher` is reexported in the `hash` module. And finally, a few changes were made to the default parameters on `HashMap`. * The `RandomSipHasher` default type parameter was renamed to `RandomState`. This renaming emphasizes that it is not a hasher, but rather just state to generate hashers. It also moves away from the name "sip" as it may not always be implemented as `SipHasher`. This type lives in the `std::collections::hash_map` module as `#[unstable]` * The associated `Hasher` type of `RandomState` is creatively called... `Hasher`! This concrete structure lives next to `RandomState` as an implemenation of the "default hashing algorithm" used for a `HashMap`. Under the hood this is currently implemented as `SipHasher`, but it draws an explicit interface for now and allows us to modify the implementation over time if necessary. There are many breaking changes outlined above, and as a result this commit is a: [breaking-change]
2015-01-07	use slicing sugar	Jorge Aparicio	-19/+19

2015-01-07	std: Stabilize the std::hash module	Alex Crichton	-38/+41
	This commit aims to prepare the `std::hash` module for alpha by formalizing its current interface whileholding off on adding `#[stable]` to the new APIs. The current usage with the `HashMap` and `HashSet` types is also reconciled by separating out composable parts of the design. The primary goal of this slight redesign is to separate the concepts of a hasher's state from a hashing algorithm itself. The primary change of this commit is to separate the `Hasher` trait into a `Hasher` and a `HashState` trait. Conceptually the old `Hasher` trait was actually just a factory for various states, but hashing had very little control over how these states were used. Additionally the old `Hasher` trait was actually fairly unrelated to hashing. This commit redesigns the existing `Hasher` trait to match what the notion of a `Hasher` normally implies with the following definition: trait Hasher { type Output; fn reset(&mut self); fn finish(&self) -> Output; } This `Hasher` trait emphasizes that hashing algorithms may produce outputs other than a `u64`, so the output type is made generic. Other than that, however, very little is assumed about a particular hasher. It is left up to implementors to provide specific methods or trait implementations to feed data into a hasher. The corresponding `Hash` trait becomes: trait Hash<H: Hasher> { fn hash(&self, &mut H); } The old default of `SipState` was removed from this trait as it's not something that we're willing to stabilize until the end of time, but the type parameter is always required to implement `Hasher`. Note that the type parameter `H` remains on the trait to enable multidispatch for specialization of hashing for particular hashers. Note that `Writer` is not mentioned in either of `Hash` or `Hasher`, it is simply used as part `derive` and the implementations for all primitive types. With these definitions, the old `Hasher` trait is realized as a new `HashState` trait in the `collections::hash_state` module as an unstable addition for now. The current definition looks like: trait HashState { type Hasher: Hasher; fn hasher(&self) -> Hasher; } The purpose of this trait is to emphasize that the one piece of functionality for implementors is that new instances of `Hasher` can be created. This conceptually represents the two keys from which more instances of a `SipHasher` can be created, and a `HashState` is what's stored in a `HashMap`, not a `Hasher`. Implementors of custom hash algorithms should implement the `Hasher` trait, and only hash algorithms intended for use in hash maps need to implement or worry about the `HashState` trait. The entire module and `HashState` infrastructure remains `#[unstable]` due to it being recently redesigned, but some other stability decision made for the `std::hash` module are: * The `Writer` trait remains `#[experimental]` as it's intended to be replaced with an `io::Writer` (more details soon). * The top-level `hash` function is `#[unstable]` as it is intended to be generic over the hashing algorithm instead of hardwired to `SipHasher` * The inner `sip` module is now private as its one export, `SipHasher` is reexported in the `hash` module. And finally, a few changes were made to the default parameters on `HashMap`. * The `RandomSipHasher` default type parameter was renamed to `RandomState`. This renaming emphasizes that it is not a hasher, but rather just state to generate hashers. It also moves away from the name "sip" as it may not always be implemented as `SipHasher`. This type lives in the `std::collections::hash_map` module as `#[unstable]` * The associated `Hasher` type of `RandomState` is creatively called... `Hasher`! This concrete structure lives next to `RandomState` as an implemenation of the "default hashing algorithm" used for a `HashMap`. Under the hood this is currently implemented as `SipHasher`, but it draws an explicit interface for now and allows us to modify the implementation over time if necessary. There are many breaking changes outlined above, and as a result this commit is a: [breaking-change]
2015-01-07	Solve rather subtle bug in `replace_late_bound_regions` -- we were passing ↵	Niko Matsakis	-2/+2
	the debruijn index in so that callees could construct late-bound regions at the right depth, but then the result was cached. When the cached result was used, it might be at the wrong depth. So now we don't pass the result in and instead simply adjust the depth to match the current nesting level as we go.
2015-01-07	Merge pull request #20674 from jbcrail/fix-misspelled-comments	bors	-1/+1
	Fix misspelled comments. Reviewed-by: steveklabnik
2015-01-06	Fix misspelled comments.	Joseph Crail	-1/+1
	I cleaned up comments prior to the 1.0 alpha release.
2015-01-06	rollup merge of #20593: nikomatsakis/unused-tps-in-impl	Alex Crichton	-0/+1
	Conflicts: src/libcollections/lib.rs src/librustc/lib.rs src/libserialize/lib.rs src/libstd/lib.rs
2015-01-06	rollup merge of #20481: seanmonstar/fmt-show-string	Alex Crichton	-26/+27
	Conflicts: src/compiletest/runtest.rs src/libcore/fmt/mod.rs src/libfmt_macros/lib.rs src/libregex/parse.rs src/librustc/middle/cfg/construct.rs src/librustc/middle/dataflow.rs src/librustc/middle/infer/higher_ranked/mod.rs src/librustc/middle/ty.rs src/librustc_back/archive.rs src/librustc_borrowck/borrowck/fragments.rs src/librustc_borrowck/borrowck/gather_loans/mod.rs src/librustc_resolve/lib.rs src/librustc_trans/back/link.rs src/librustc_trans/save/mod.rs src/librustc_trans/trans/base.rs src/librustc_trans/trans/callee.rs src/librustc_trans/trans/common.rs src/librustc_trans/trans/consts.rs src/librustc_trans/trans/controlflow.rs src/librustc_trans/trans/debuginfo.rs src/librustc_trans/trans/expr.rs src/librustc_trans/trans/monomorphize.rs src/librustc_typeck/astconv.rs src/librustc_typeck/check/method/mod.rs src/librustc_typeck/check/mod.rs src/librustc_typeck/check/regionck.rs src/librustc_typeck/collect.rs src/libsyntax/ext/format.rs src/libsyntax/ext/source_util.rs src/libsyntax/ext/tt/transcribe.rs src/libsyntax/parse/mod.rs src/libsyntax/parse/token.rs src/test/run-pass/issue-8898.rs
2015-01-06	core: split into fmt::Show and fmt::String	Sean McArthur	-26/+27
	fmt::Show is for debugging, and can and should be implemented for all public types. This trait is used with `{:?}` syntax. There still exists #[derive(Show)]. fmt::String is for types that faithfully be represented as a String. Because of this, there is no way to derive fmt::String, all implementations must be purposeful. It is used by the default format syntax, `{}`. This will break most instances of `{}`, since that now requires the type to impl fmt::String. In most cases, replacing `{}` with `{:?}` is the correct fix. Types that were being printed specifically for users should receive a fmt::String implementation to fix this. Part of #20013 [breaking-change]
2015-01-06	Fix fallout in libs. For the most part I just tagged impls as ↵	Niko Matsakis	-0/+1
	`#[old_impl_check]`.
2015-01-07	Replace full slice notation with index calls	Nick Cameron	-19/+19

2015-01-05	Merge remote-tracking branch 'nrc/sized-2' into rollup	Alex Crichton	-2/+2
	Conflicts: src/liballoc/boxed.rs src/libcollections/btree/map.rs src/libcollections/slice.rs src/libcore/borrow.rs src/libcore/cmp.rs src/libcore/ops.rs src/libstd/c_str.rs src/libstd/collections/hash/map.rs src/libsyntax/parse/obsolete.rs src/test/compile-fail/unboxed-closure-sugar-default.rs src/test/compile-fail/unboxed-closure-sugar-equiv.rs src/test/compile-fail/unboxed-closure-sugar-lifetime-elision.rs src/test/compile-fail/unboxed-closure-sugar-region.rs src/test/compile-fail/unsized3.rs src/test/run-pass/associated-types-conditional-dispatch.rs
2015-01-05	rollup merge of #20556: japaric/no-for-sized	Alex Crichton	-1/+1
	Conflicts: src/libcollections/slice.rs src/libcollections/str.rs src/libcore/borrow.rs src/libcore/cmp.rs src/libcore/ops.rs src/libstd/c_str.rs src/test/compile-fail/issue-19009.rs
2015-01-06	Fallout	Nick Cameron	-2/+2

2015-01-05	remove ty_closure	Jorge Aparicio	-4/+1

2015-01-05	sed -i -s 's/ for Sized?//g' */.rs	Jorge Aparicio	-1/+1

2015-01-03	Remove deprecated functionality	Alex Crichton	-1/+1
	This removes a large array of deprecated functionality, regardless of how recently it was deprecated. The purpose of this commit is to clean out the standard libraries and compiler for the upcoming alpha release. Some notable compiler changes were to enable warnings for all now-deprecated command line arguments (previously the deprecated versions were silently accepted) as well as removing deriving(Zero) entirely (the trait was removed). The distribution no longer contains the libtime or libregex_macros crates. Both of these have been deprecated for some time and are available externally.
2015-01-03	sed -i -s 's/#\[deriving(/#\[derive(/g' */.rs	Jorge Aparicio	-3/+3

2014-12-30	Fallout from stabilization	Aaron Turon	-1/+1

2014-12-30	Remove the AssocSpace	Niko Matsakis	-2/+1

2014-12-30	Remove the def-id from type parameters. Having this def-id was bad for ↵	Niko Matsakis	-11/+2
	several reasons: 1. Produced more unique types than is necessary. This increases memory consumption. 2. Linking the type parameter to its definition seems like a good idea, but it encourages reliance on the bounds listing. 3. It made pretty-printing harder and in particular was causing bad error messages when errors occurred before the `TypeParameterDef` entries were fully stored.
2014-12-30	Integrate projection bounds to `ExistentialBounds` but do not use them for ↵	Niko Matsakis	-4/+4
	anything.
2014-12-30	Implement associated type projection and normalization.	Niko Matsakis	-5/+49

2014-12-30	Rename `Polytype` to `TypeScheme` to differentiate type schemes (early ↵	Niko Matsakis	-2/+2
	bound) from higher-ranked things (late-bound), which also use the `Poly` prefix.
2014-12-30	More rebase fixes.	Huon Wilson	-2/+0

2014-12-29	Rebase fixes.	Huon Wilson	-1/+1
	I've totally mangled the history with these rebases; sorry, future programmer!
2014-12-29	Intern Region in tcx.	Huon Wilson	-1/+1
	This makes sty only 32 bytes on machines with 64-bit pointers.
2014-12-29	Store Substs in an arena in the tcx.	Huon Wilson	-3/+5
	This current inflates memory use more than 3 times.
2014-12-22	rollup merge of #19891: nikomatsakis/unique-fn-types-3	Alex Crichton	-2/+14
	Conflicts: src/libcore/str.rs src/librustc_trans/trans/closure.rs src/librustc_typeck/collect.rs src/libstd/path/posix.rs src/libstd/path/windows.rs
2014-12-22	Change print out to include the path to the fn, a bit ad-hoc for now .	Niko Matsakis	-2/+14

2014-12-22	Rote changes that don't care to distinguish between a fn pointer and a fn item.	Niko Matsakis	-1/+1

2014-12-21	Fallout of std::str stabilization	Alex Crichton	-13/+14

2014-12-21	std: Stabilize the std::str module	Alex Crichton	-0/+63
	This commit starts out by consolidating all `str` extension traits into one `StrExt` trait to be included in the prelude. This means that `UnicodeStrPrelude`, `StrPrelude`, and `StrAllocating` have all been merged into one `StrExt` exported by the standard library. Some functionality is currently duplicated with the `StrExt` present in libcore. This commit also currently avoids any methods which require any form of pattern to operate. These functions will be stabilized via a separate RFC. Next, stability of methods and structures are as follows: Stable * from_utf8_unchecked * CowString - after moving to std::string * StrExt::as_bytes * StrExt::as_ptr * StrExt::bytes/Bytes - also made a struct instead of a typedef * StrExt::char_indices/CharIndices - CharOffsets was renamed * StrExt::chars/Chars * StrExt::is_empty * StrExt::len * StrExt::lines/Lines * StrExt::lines_any/LinesAny * StrExt::slice_unchecked * StrExt::trim * StrExt::trim_left * StrExt::trim_right * StrExt::words/Words - also made a struct instead of a typedef Unstable * from_utf8 - the error type was changed to a `Result`, but the error type has yet to prove itself * from_c_str - this function will be handled by the c_str RFC * FromStr - this trait will have an associated error type eventually * StrExt::escape_default - needs iterators at least, unsure if it should make the cut * StrExt::escape_unicode - needs iterators at least, unsure if it should make the cut * StrExt::slice_chars - this function has yet to prove itself * StrExt::slice_shift_char - awaiting conventions about slicing and shifting * StrExt::graphemes/Graphemes - this functionality may only be in libunicode * StrExt::grapheme_indices/GraphemeIndices - this functionality may only be in libunicode * StrExt::width - this functionality may only be in libunicode * StrExt::utf16_units - this functionality may only be in libunicode * StrExt::nfd_chars - this functionality may only be in libunicode * StrExt::nfkd_chars - this functionality may only be in libunicode * StrExt::nfc_chars - this functionality may only be in libunicode * StrExt::nfkc_chars - this functionality may only be in libunicode * StrExt::is_char_boundary - naming is uncertain with container conventions * StrExt::char_range_at - naming is uncertain with container conventions * StrExt::char_range_at_reverse - naming is uncertain with container conventions * StrExt::char_at - naming is uncertain with container conventions * StrExt::char_at_reverse - naming is uncertain with container conventions * StrVector::concat - this functionality may be replaced with iterators, but it's not certain at this time * StrVector::connect - as with concat, may be deprecated in favor of iterators Deprecated * StrAllocating and UnicodeStrPrelude have been merged into StrExit * eq_slice - compiler implementation detail * from_str - use the inherent parse() method * is_utf8 - call from_utf8 instead * replace - call the method instead * truncate_utf16_at_nul - this is an implementation detail of windows and does not need to be exposed. * utf8_char_width - moved to libunicode * utf16_items - moved to libunicode * is_utf16 - moved to libunicode * Utf16Items - moved to libunicode * Utf16Item - moved to libunicode * Utf16Encoder - moved to libunicode * AnyLines - renamed to LinesAny and made a struct * SendStr - use CowString<'static> instead * str::raw - all functionality is deprecated * StrExt::into_string - call to_string() instead * StrExt::repeat - use iterators instead * StrExt::char_len - use .chars().count() instead * StrExt::is_alphanumeric - use .chars().all(..) * StrExt::is_whitespace - use .chars().all(..) Pending deprecation -- while slicing syntax is being worked out, these methods are all #[unstable] * Str - while currently used for generic programming, this trait will be replaced with one of [], deref coercions, or a generic conversion trait. * StrExt::slice - use slicing syntax instead * StrExt::slice_to - use slicing syntax instead * StrExt::slice_from - use slicing syntax instead * StrExt::lev_distance - deprecated with no replacement Awaiting stabilization due to patterns and/or matching * StrExt::contains * StrExt::contains_char * StrExt::split * StrExt::splitn * StrExt::split_terminator * StrExt::rsplitn * StrExt::match_indices * StrExt::split_str * StrExt::starts_with * StrExt::ends_with * StrExt::trim_chars * StrExt::trim_left_chars * StrExt::trim_right_chars * StrExt::find * StrExt::rfind * StrExt::find_str * StrExt::subslice_offset
2014-12-21	Test fixes and rebase conflicts	Alex Crichton	-0/+2

2014-12-21	rollup merge of #20057: nick29581/array-syntax	Alex Crichton	-1/+1
	This does NOT break any existing programs because the `[_, ..n]` syntax is also supported. Part of #19999 r? @nikomatsakis
2014-12-21	rollup merge of #20039: barosl/if-let-friendly-error	Alex Crichton	-2/+3
	Fixes #19991.
2014-12-21	rollup merge of #19979: Munksgaard/19978	Alex Crichton	-1/+5
	This fixes #19978. The bug was introduced by 570325d, where if the type of an Fn has not been inferred (strs[0] is "_") we slice from 1 to 0.
2014-12-20	Allow use of `[_ ; n]` syntax for fixed length and repeating arrays.	Nick Cameron	-1/+1
	This does NOT break any existing programs because the `[_, ..n]` syntax is also supported.
2014-12-20	Drop the Match prefix from the MatchSource variants	Barosl Lee	-2/+3

2014-12-19	librustc: use `#[deriving(Copy)]`	Jorge Aparicio	-6/+2

2014-12-19	Add a check for uninferred type parameter	Philip Munksgaard	-1/+5
	This fixes #19978. The bug was introduced by 570325d, where if the type of an Fn has not been inferred (strs[0] is "_") we slice from 1 to 0. We now explicitly check if `strs[0]` is a single element tuple.
2014-12-19	Make all predicates higher-ranked, not just trait references.	Niko Matsakis	-0/+53

2014-12-19	Centralize on using `Binder` to introduce new binding levels, rather than ↵	Niko Matsakis	-22/+32
	having FnSig carry an implicit binding level. This means that we be more typesafe in general, since things that instantiate bound regions can drop the Binder to reflect that.
2014-12-19	Rename the code that replaces unbound variables to "freshen" rather than ↵	Niko Matsakis	-2/+2
	"skolemize" -- strictly speaking, this is not skolemization, because it is not discharging quantifiers. Also, the trait selection code will still be doing true skolemization, so it would be a confusing overlap of names.
2014-12-19	Create distinct types for a PolyTraitRef (with bindings) and a normal TraitRef.	Niko Matsakis	-21/+18

2014-12-19	Fix bug in higher-ranked code that would sometimes leak skolemized regions ↵	Niko Matsakis	-1/+7
	and/or cause incorrect results.
2014-12-17	rollup merge of #19912: P1start/fn-formatting	Alex Crichton	-8/+17
	This is to encourage the use of the sugary syntax instead of the `<>` syntax, which will not be usable post-1.0. Rustdoc [still uses the `<>` syntax](https://github.com/rust-lang/rust/issues/19909), so if a rustdoc wizard is looking for something to do, it would be nice to use the parenthetical syntax there as well. (I tried to patch rustdoc as well, but failed…)
2014-12-17	Use the sugary syntax to print the `Fn` traits in error messages	P1start	-8/+17