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

Age	Commit message (Collapse)	Author	Lines
2017-06-13	Merge crate `collections` into `alloc`	Murarth	-92/+0

2017-03-01	Panic on errors in `format!` or `<T: Display>::to_string`	Simon Sapin	-0/+6
	… instead of silently ignoring a result. `fmt::Write for String` never returns `Err`, so implementations of `Display` (or other traits of that family) never should either. Fixes #40103
2016-09-29	Add link to format! docs	Paul Lange	-1/+3

2016-02-25	Use `box` syntax in `vec!` macro	Andrew Paseltiner	-2/+3
	Closes #28950.
2015-09-07	Add note about clone in docs for vec![]	Manish Goregaokar	-0/+6

2015-03-18	Register new snapshots	Alex Crichton	-43/+3

2015-03-16	better document the hacks required to test libcollections	Jorge Aparicio	-2/+4

2015-03-16	move some tests back to libcollections	Jorge Aparicio	-0/+15

2015-03-16	impl<T> [T]	Jorge Aparicio	-0/+38

2015-03-11	Example -> Examples	Steve Klabnik	-1/+1
	This brings comments in line with https://github.com/rust-lang/rfcs/blob/master/text/0505-api-comment-conventions.md#using-markdown
2015-02-24	Use arrays instead of vectors in tests	Vadim Petrochenkov	-1/+1

2015-02-17	Implement `Vec::from_elem` (RFC 832)	Markus Siemens	-3/+25
	Implement `Vec::from_elem` by making the `vec![element; len]` macro more powerful (see RFC 832). Closes #22414
2015-02-07	Don't use std:: paths in syntax extensions when compiling a #![no_std] crate	Keegan McAllister	-0/+16
	Fixes #16803. Fixes #14342. Fixes half of #21827 -- slice syntax is still broken.
2015-01-25	Merge remote-tracking branch 'rust-lang/master'	Brian Anderson	-8/+8
	Conflicts: mk/tests.mk src/liballoc/arc.rs src/liballoc/boxed.rs src/liballoc/rc.rs src/libcollections/bit.rs src/libcollections/btree/map.rs src/libcollections/btree/set.rs src/libcollections/dlist.rs src/libcollections/ring_buf.rs src/libcollections/slice.rs src/libcollections/str.rs src/libcollections/string.rs src/libcollections/vec.rs src/libcollections/vec_map.rs src/libcore/any.rs src/libcore/array.rs src/libcore/borrow.rs src/libcore/error.rs src/libcore/fmt/mod.rs src/libcore/iter.rs src/libcore/marker.rs src/libcore/ops.rs src/libcore/result.rs src/libcore/slice.rs src/libcore/str/mod.rs src/libregex/lib.rs src/libregex/re.rs src/librustc/lint/builtin.rs src/libstd/collections/hash/map.rs src/libstd/collections/hash/set.rs src/libstd/sync/mpsc/mod.rs src/libstd/sync/mutex.rs src/libstd/sync/poison.rs src/libstd/sync/rwlock.rs src/libsyntax/feature_gate.rs src/libsyntax/test.rs
2015-01-23	grandfathered -> rust1	Brian Anderson	-1/+1

2015-01-21	Add 'feature' and 'since' to stability attributes	Brian Anderson	-1/+1

2015-01-18	Improve the vec![...] macro with UFCS.	Eduard Burtescu	-8/+8
	There are two limitations to the macro that this addresses: 1. the expected type is not propagated, coercions don't trigger 2. references inside element expressions don't outlive the `Vec` Both of these limitations are caused by the block in the macro expansion, previously needed to trigger a coercion from `Box<[T; N]>` to `Box<[T]>`, now possible with UFCS.
2015-01-08	Enabled the `vec![]` macro to use the `[a; b]` repeat syntax.	Marvin Löbel	-1/+5
	Closes #15587
2015-01-07	Test fixes and rebase conflicts	Alex Crichton	-1/+1

2015-01-07	std: Stablize the macros module	Alex Crichton	-0/+1
	This commit performs a pass over the `std::macros` module, applying stability attributes where necessary. In particular, this audits macros for patterns such as: * Standard use of forward-to-format-args via `$($arg:tt)` (or `+`) Prevent macro-defined identifiers from leaking into expression arguments as hygiene is not perfectly implemented. * Wherever possible, `$crate` is used now. Specifically, the following actions were taken: * The `std::macros` module itself is no longer public. * The `panic!` macro is stable * The `assert!` macro is stable * The `assert_eq!` macro is stable * The `debug_assert!` macro is stable * The `debug_assert_eq!` macro is stable * The `unreachable!` macro is stable after removing the extra forms to bring the definition in line with the `unimplemented!` macro. * The `try!` macro is stable * The `vec!` macro is stable [breaking-change]
2015-01-06	Register new snapshots	Alex Crichton	-14/+0
	Conflicts: src/librbml/lib.rs src/libserialize/json_stage0.rs src/libserialize/serialize_stage0.rs src/libsyntax/ast.rs src/libsyntax/ext/deriving/generic/mod.rs src/libsyntax/parse/token.rs
2015-01-05	Stop using macro_escape as an inner attribute	Keegan McAllister	-2/+0
	In preparation for the rename.
2015-01-05	Use $crate and macro reexport to reduce duplicated code	Keegan McAllister	-0/+12
	Many of libstd's macros are now re-exported from libcore and libcollections. Their libstd definitions have moved to a macros_stage0 module and can disappear after the next snapshot. Where the two crates had already diverged, I took the libstd versions as they're generally newer and better-tested. See e.g. d3c831b, which was a fix to libstd's assert_eq!() that didn't make it into libcore's. Fixes #16806.
2014-12-18	librustc: Always parse `macro!()`/`macro![]` as expressions if not	Patrick Walton	-2/+3
	followed by a semicolon. This allows code like `vec![1i, 2, 3].len();` to work. This breaks code that uses macros as statements without putting semicolons after them, such as: fn main() { ... assert!(a == b) assert!(c == d) println(...); } It also breaks code that uses macros as items without semicolons: local_data_key!(foo) fn main() { println("hello world") } Add semicolons to fix this code. Those two examples can be fixed as follows: fn main() { ... assert!(a == b); assert!(c == d); println(...); } local_data_key!(foo); fn main() { println("hello world") } RFC #378. Closes #18635. [breaking-change]
2014-08-19	A few minor documentation fixes	P1start	-1/+1

2014-06-05	std: Recreate a `collections` module	Alex Crichton	-0/+22
	As with the previous commit with `librand`, this commit shuffles around some `collections` code. The new state of the world is similar to that of librand: * The libcollections crate now only depends on libcore and liballoc. * The standard library has a new module, `std::collections`. All functionality of libcollections is reexported through this module. I would like to stress that this change is purely cosmetic. There are very few alterations to these primitives. There are a number of notable points about the new organization: * std::{str, slice, string, vec} all moved to libcollections. There is no reason that these primitives shouldn't be necessarily usable in a freestanding context that has allocation. These are all reexported in their usual places in the standard library. * The `hashmap`, and transitively the `lru_cache`, modules no longer reside in `libcollections`, but rather in libstd. The reason for this is because the `HashMap::new` contructor requires access to the OSRng for initially seeding the hash map. Beyond this requirement, there is no reason that the hashmap could not move to libcollections. I do, however, have a plan to move the hash map to the collections module. The `HashMap::new` function could be altered to require that the `H` hasher parameter ascribe to the `Default` trait, allowing the entire `hashmap` module to live in libcollections. The key idea would be that the default hasher would be different in libstd. Something along the lines of: // src/libstd/collections/mod.rs pub type HashMap<K, V, H = RandomizedSipHasher> = core_collections::HashMap<K, V, H>; This is not possible today because you cannot invoke static methods through type aliases. If we modified the compiler, however, to allow invocation of static methods through type aliases, then this type definition would essentially be switching the default hasher from `SipHasher` in libcollections to a libstd-defined `RandomizedSipHasher` type. This type's `Default` implementation would randomly seed the `SipHasher` instance, and otherwise perform the same as `SipHasher`. This future state doesn't seem incredibly far off, but until that time comes, the hashmap module will live in libstd to not compromise on functionality. * In preparation for the hashmap moving to libcollections, the `hash` module has moved from libstd to libcollections. A previously snapshotted commit enables a distinct `Writer` trait to live in the `hash` module which `Hash` implementations are now parameterized over. Due to using a custom trait, the `SipHasher` implementation has lost its specialized methods for writing integers. These can be re-added backwards-compatibly in the future via default methods if necessary, but the FNV hashing should satisfy much of the need for speedier hashing. A list of breaking changes: * HashMap::{get, get_mut} no longer fails with the key formatted into the error message with `{:?}`, instead, a generic message is printed. With backtraces, it should still be not-too-hard to track down errors. * The HashMap, HashSet, and LruCache types are now available through std::collections instead of the collections crate. * Manual implementations of hash should be parameterized over `hash::Writer` instead of just `Writer`. [breaking-change]