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

Age	Commit message (Collapse)	Author	Lines
2015-03-23	rustdoc: Replace no-pretty-expanded with pretty-expanded	Brian Anderson	-0/+2
	Now that features must be declared expanded source often does not compile. This adds 'pretty-expanded' to a bunch of test cases that still work.
2015-03-15	Strip all leading/trailing newlines	Tamir Duberstein	-1/+0

2015-02-06	make `for PAT in ITER_EXPR { ... }` a terminating-scope for ITER_EXPR.	Felix S. Klock II	-1/+1
	In effect, temporary anonymous values created during the evaluation of ITER_EXPR no longer not live for the entirety of the block surrounding the for-loop; instead they only live for the extent of the for-loop itself, and no longer. ---- There is one case I know of that this breaks, demonstrated to me by niko (but it is also a corner-case that is useless in practice). Here is that case: ``` fn main() { let mut foo: Vec<&i8> = Vec::new(); for i in &[1, 2, 3] { foo.push(i) } } ``` Note that if you add any code following the for-loop above, or even a semicolon to the end of it, then the code will stop compiling (i.e., it gathers a vector of references but the gathered vector cannot actually be used.) (The above code, despite being useless, did occur in one run-pass test by accident; that test is updated here to accommodate the new striction.) ---- So, technically this is a: [breaking-change]
2015-02-02	`for x in xs.iter()` -> `for x in &xs`	Jorge Aparicio	-1/+1

2015-01-30	Remove all `i` suffixes	Tobias Bucher	-1/+1

2014-06-29	librustc: Remove the fallback to `int` for integers and `f64` for	Patrick Walton	-1/+1
	floating point numbers for real. This will break code that looks like: let mut x = 0; while ... { x += 1; } println!("{}", x); Change that code to: let mut x = 0i; while ... { x += 1; } println!("{}", x); Closes #15201. [breaking-change]
2014-06-13	librustc: Fix the issue with labels shadowing variable names by making	Patrick Walton	-0/+19
	the leading quote part of the identifier for the purposes of hygiene. This adopts @jbclements' solution to #14539. I'm not sure if this is a breaking change or not. Closes #12512. [breaking-change]