Commit Graph

13 Commits

Author SHA1 Message Date
Alex Crichton
665ea963d3 Test fixes and rebase conflicts 2015-02-17 19:42:28 -08:00
Tobias Bucher
7f64fe4e27 Remove all i suffixes 2015-01-30 04:38:54 +01:00
Aaron Turon
caca9b2e71 Fallout from stabilization 2015-01-06 14:57:52 -08:00
Jorge Aparicio
d6a948e8f4 fix run-make test 2015-01-05 17:22:17 -05:00
Alex Crichton
7d8d06f86b Remove deprecated functionality
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 23:43:57 -08:00
Niko Matsakis
5c3d398919 Mostly rote conversion of proc() to move|| (and occasionally Thunk::new) 2014-12-14 04:21:56 -05:00
Steve Klabnik
7828c3dd28 Rename fail! to panic!
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-10-29 11:43:07 -04:00
Patrick Walton
a5bb0a3a45 librustc: Remove the fallback to int for integers and f64 for
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-29 11:47:58 -07:00
Manish Goregaokar
713e87526e Use new attribute syntax in python files in src/etc too (#13478) 2014-04-14 21:00:31 +05:30
Alex Crichton
a41b0c2529 extern mod => extern crate
This was previously implemented, and it just needed a snapshot to go through
2014-02-14 22:55:21 -08:00
Derek Guenther
730bdb6403 Added tests to make tidy 2014-02-07 12:49:24 -06:00
Scott Lawrence
3dbc1c34e6 Remove do keyword from test/ 2014-01-29 09:15:42 -05:00
Alex Crichton
6d6ccb75ff Add a new run-make test directory
This infrastructure is meant to support runnings tests that involve various
interesting interdependencies about the types of crates being linked or possibly
interacting with C libraries. The goal of these make tests is to not restrict
them to a particular test runner, but allow each test to run its own tests.

To this end, there is a new src/test/run-make directory which has sub-folders of
tests. Each test requires a `Makefile`, and running the tests constitues simply
running `make` inside the directory. The new target is `check-stageN-rmake`.

These tests will have the destination directory (as TMPDIR) and the local rust
compiler (as RUSTC) passed along to them. There is also some helpful
cross-platform utilities included in src/test/run-make/tools.mk to aid with
compiling C programs and running them.

The impetus for adding this new test suite is to allow various interesting forms
of testing rust linkage. All of the tests initially added are various flavors of
compiling Rust and C with one another as well as just making sure that rust
linkage works in general.

Closes #10434
2013-11-29 18:36:14 -08:00