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

Age	Commit message (Collapse)	Author	Lines
2019-07-27	tests: Move run-pass tests without naming conflicts to ui	Vadim Petrochenkov	-8/+0

2019-07-27	tests: Add missing run-pass annotations	Vadim Petrochenkov	-0/+1

2018-12-25	Remove licenses	Mark Rousskov	-10/+0

2015-04-08	Remove pretty-expanded from failing tests	Alex Crichton	-1/+0
	This commit removes pretty-expanded from all tests that wind up calling panic! one way or another now that its internals are unstable.
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-01-30	Remove all `i` suffixes	Tobias Bucher	-2/+2

2014-10-29	Rename fail! to panic!	Steve Klabnik	-1/+1
	https://github.com/rust-lang/rfcs/pull/221 The current terminology of "task failure" often causes problems when writing or speaking about code. You often want to talk about the possibility of an operation that returns a Result "failing", but cannot because of the ambiguity with task failure. Instead, you have to speak of "the failing case" or "when the operation does not succeed" or other circumlocutions. Likewise, we use a "Failure" header in rustdoc to describe when operations may fail the task, but it would often be helpful to separate out a section describing the "Err-producing" case. We have been steadily moving away from task failure and toward Result as an error-handling mechanism, so we should optimize our terminology accordingly: Result-producing functions should be easy to describe. To update your code, rename any call to `fail!` to `panic!` instead. Assuming you have not created your own macro named `panic!`, this will work on UNIX based systems: grep -lZR 'fail!' . \| xargs -0 -l sed -i -e 's/fail!/panic!/g' You can of course also do this by hand. [breaking-change]
2014-06-24	librustc: Remove the fallback to `int` from typechecking.	Niko Matsakis	-2/+2
	This breaks a fair amount of code. The typical patterns are: * `for _ in range(0, 10)`: change to `for _ in range(0u, 10)`; * `println!("{}", 3)`: change to `println!("{}", 3i)`; * `[1, 2, 3].len()`: change to `[1i, 2, 3].len()`. RFC #30. Closes #6023. [breaking-change]
2013-10-22	Drop the '2' suffix from logging macros	Alex Crichton	-1/+1
	Who doesn't like a massive renaming?
2013-09-30	rpass: Remove usage of fmt!	Alex Crichton	-1/+1

2013-05-19	Use assert_eq! rather than assert! where possible	Corey Richardson	-1/+1

2013-05-14	Use static string with fail!() and remove fail!(fmt!())	Björn Steinbrink	-1/+1
	fail!() used to require owned strings but can handle static strings now. Also, it can pass its arguments to fmt!() on its own, no need for the caller to call fmt!() itself.
2013-03-29	librustc: Remove `fail_unless!`	Patrick Walton	-1/+1

2013-03-07	librustc: Convert all uses of `assert` over to `fail_unless!`	Patrick Walton	-1/+1

2013-02-13	Remove die!, raplace invocations with fail! Issue #4524 pt 3	Nick Desaulniers	-1/+1

2013-02-01	check-fast fallout from removing export, r=burningtree	Graydon Hoare	-1/+1

2013-01-31	Replace most invocations of fail keyword with die! macro	Nick Desaulniers	-1/+1

2012-12-10	Reliciense makefiles and testsuite. Yup.	Graydon Hoare	-0/+10

2012-08-23	Remove match check from test cases	Tim Chevalier	-1/+1

2012-08-06	Convert alt to match. Stop parsing alt	Brian Anderson	-1/+1

2012-08-05	Switch alts to use arrows	Brian Anderson	-1/+1

2012-02-15	Rewrite exhaustiveness checker	Marijn Haverbeke	-1/+1
	Issue #352 Closes #1720 The old checker would happily accept things like 'alt x { @some(a) { a } }'. It now properly descends into patterns, checks exhaustiveness of booleans, and complains when number/string patterns aren't exhaustive.
2011-10-07	Make 1-1 parse again	Marijn Haverbeke	-0/+6
	Issue #954 This is not a very elegant fix -- we should probably do something with constant folding to handle negative-int alt patterns in the future.