Commit Graph

516 Commits

Author SHA1 Message Date
Alex Crichton
231eeaa35b rollup merge of #22502: nikomatsakis/deprecate-bracket-bracket
Conflicts:
	src/libcollections/slice.rs
	src/libcollections/str.rs
	src/librustc/middle/lang_items.rs
	src/librustc_back/rpath.rs
	src/librustc_typeck/check/regionck.rs
	src/libstd/ffi/os_str.rs
	src/libsyntax/diagnostic.rs
	src/libsyntax/parse/parser.rs
	src/libsyntax/util/interner.rs
	src/test/run-pass/regions-refcell.rs
2015-02-18 15:48:40 -08:00
Niko Matsakis
9ea84aeed4 Replace all uses of &foo[] with &foo[..] en masse. 2015-02-18 17:36:03 -05:00
Alex Crichton
c07ec507e2 rollup merge of #22287: Ryman/purge_carthographers
This overlaps with #22276 (I left make check running overnight) but covers a number of additional cases and has a few rewrites where the clones are not even necessary.

This also implements `RandomAccessIterator` for `iter::Cloned`

cc @steveklabnik, you may want to glance at this before #22281 gets the bors treatment
2015-02-18 14:31:55 -08:00
Huon Wilson
dfc5c0f1e8 Manual merge of #22475 - alexcrichton:rollup, r=alexcrichton
One windows bot failed spuriously.
2015-02-18 23:50:21 +11:00
Alex Crichton
d8ba8b00a7 rollup merge of #22459: alexcrichton/feature-names
Conflicts:
	src/rustbook/main.rs
2015-02-17 17:26:59 -08:00
Kevin Butler
2f586b9687 Opt for .cloned() over .map(|x| x.clone()) etc. 2015-02-18 00:56:07 +00:00
Alex Crichton
5be2b8964c rollup merge of #22191: nagisa/target-ptr-width-json
This aligns json target specification to match terminology used elsewhere in the code base.

[breaking-change] for custom target json users. Change all appearances of target-word-size
to target-pointer-width.
2015-02-17 15:13:46 -08:00
Alex Crichton
a2ebb24ee6 std: Rename io/path features with old_ prefix
This commit renames the features for the `std::old_io` and `std::old_path`
modules to `old_io` and `old_path` to help facilitate migration to the new APIs.

This is a breaking change as crates which mention the old feature names now need
to be renamed to use the new feature names.

[breaking-change]
2015-02-17 14:02:45 -08:00
bors
6c065fc8cb Auto merge of #21774 - ejjeong:enable-test-for-android, r=alexcrichton
- Now "make check-stage2-T-aarch64-linux-android-H-x86_64-unknown-linux-gnu" works (#21773)
- Fix & enable debuginfo tests for android (#10381)
- Fix & enable more tests for android (both for arm/aarch64)
- Enable many already-pass tests on android (both for arm/aarch64)
2015-02-17 19:35:12 +00:00
Eunji Jeong
194d96e5c3 Lower the default dwarf version for android 2015-02-16 17:48:50 +09:00
Manish Goregaokar
ed58399449 Rollup merge of #22297 - nagisa:spring-cleanup, r=alexcrichton
This PR replaces uses of `os::getenv` with newly introduced `env::var{,_os}`.

Mostly did this as a background activity to procrastinate from procrastinating.

Tests appear to build and run fine. This includes benchmarks from test/bench directory.
2015-02-15 18:42:47 +05:30
Simonas Kazlauskas
5284c4ea63 Remove a few uses of deprecated getenv 2015-02-13 22:05:12 +02:00
Valerii Hiora
00a6ff9571 Adjusting default CPUs for iOS
According to @dotdash it enables more aggressive optimizations from LLVM
2015-02-12 19:17:34 +02:00
Dave Huseby
1302f2832e oops, fixing abi::OsOpenbsd 2015-02-11 14:49:13 -08:00
Dave Huseby
47ad1cdf56 fixing PR review comments 2015-02-11 14:49:11 -08:00
Dave Huseby
cd8f31759f bitrig integration 2015-02-11 14:49:06 -08:00
Alex Crichton
a828e79480 std: Tweak the std::env OsString/String interface
This commit tweaks the interface of the `std::env` module to make it more
ergonomic for common usage:

* `env::var` was renamed to `env::var_os`
* `env::var_string` was renamed to `env::var`
* `env::args` was renamed to `env::args_os`
* `env::args` was re-added as a panicking iterator over string values
* `env::vars` was renamed to `env::vars_os`
* `env::vars` was re-added as a panicking iterator over string values.

This should make common usage (e.g. unicode values everywhere) more ergonomic
as well as "the default". This is also a breaking change due to the differences
of what's yielded from each of these functions, but migration should be fairly
easy as the defaults operate over `String` which is a common type to use.

[breaking-change]
2015-02-11 13:46:35 -08:00
Simonas Kazlauskas
6f5944bfcf Change target-word-size to target-pointer-width
This aligns json target specification to match terminology used elsewhere in the code base.

[breaking-change] for custom target json users. Change all appearances of target-word-size
to target-pointer-width.
2015-02-11 22:29:16 +02:00
Eunji Jeong
5cbdf1db9b Make aarch64-linux-android check with real target 2015-02-10 15:48:05 +09:00
GuillaumeGomez
8b12d3ddf9 Libsyntax has been updated 2015-02-06 11:59:10 +01:00
Jorge Aparicio
17bc7d8d5b cleanup: replace as[_mut]_slice() calls with deref coercions 2015-02-05 13:45:01 -05:00
Jorge Aparicio
571cc7f8e9 remove all kind annotations from closures 2015-02-04 20:06:08 -05:00
bors
c3e1f77291 Auto merge of #21892 - huonw:deprecate-rand, r=alexcrichton
Use [`rand`](https://crates.io/crates/rand) and [`derive_rand`](https://crates.io/crates/derive_rand) from crates.io.

[breaking-change]
2015-02-04 08:47:27 +00:00
Huon Wilson
df1ac7aa63 Deprecate in-tree rand, std::rand and #[derive(Rand)].
Use the crates.io crate `rand` (version 0.1 should be a drop in
replacement for `std::rand`) and `rand_macros` (`#[derive_Rand]` should
be a drop-in replacement).

[breaking-change]
2015-02-04 09:39:40 +11:00
Aaron Turon
3e39f0bc0e Rename std::path to std::old_path
As part of [RFC 474](https://github.com/rust-lang/rfcs/pull/474), this
commit renames `std::path` to `std::old_path`, leaving the existing path
API in place to ease migration to the new one. Updating should be as
simple as adjusting imports, and the prelude still maps to the old path
APIs for now.

[breaking-change]
2015-02-03 14:34:42 -08:00
bors
336c8d2e9c Auto merge of #21613 - alfie:suffix-small, r=alexcrichton 2015-02-03 07:59:04 +00:00
Alfie John
8f4844d58b More deprecating of i/u suffixes 2015-02-02 23:37:01 +00:00
Alex Crichton
7335c7dd63 rollup merge of #21830: japaric/for-cleanup
Conflicts:
	src/librustc/metadata/filesearch.rs
	src/librustc_back/target/mod.rs
	src/libstd/os.rs
	src/libstd/sys/windows/os.rs
	src/libsyntax/ext/tt/macro_parser.rs
	src/libsyntax/print/pprust.rs
	src/test/compile-fail/issue-2149.rs
2015-02-02 11:01:12 -08:00
Alex Crichton
902abab144 rollup merge of #21787: alexcrichton/std-env
Conflicts:
	src/libstd/sys/unix/backtrace.rs
	src/libstd/sys/unix/os.rs
2015-02-02 10:58:01 -08:00
Jorge Aparicio
d5d7e6565a for x in xs.iter() -> for x in &xs 2015-02-02 13:40:18 -05:00
Alex Crichton
70ed3a48df std: Add a new env module
This is an implementation of [RFC 578][rfc] which adds a new `std::env` module
to replace most of the functionality in the current `std::os` module. More
details can be found in the RFC itself, but as a summary the following methods
have all been deprecated:

[rfc]: https://github.com/rust-lang/rfcs/pull/578

* `os::args_as_bytes`   => `env::args`
* `os::args`            => `env::args`
* `os::consts`          => `env::consts`
* `os::dll_filename`    => no replacement, use `env::consts` directly
* `os::page_size`       => `env::page_size`
* `os::make_absolute`   => use `env::current_dir` + `join` instead
* `os::getcwd`          => `env::current_dir`
* `os::change_dir`      => `env::set_current_dir`
* `os::homedir`         => `env::home_dir`
* `os::tmpdir`          => `env::temp_dir`
* `os::join_paths`      => `env::join_paths`
* `os::split_paths`     => `env::split_paths`
* `os::self_exe_name`   => `env::current_exe`
* `os::self_exe_path`   => use `env::current_exe` + `pop`
* `os::set_exit_status` => `env::set_exit_status`
* `os::get_exit_status` => `env::get_exit_status`
* `os::env`             => `env::vars`
* `os::env_as_bytes`    => `env::vars`
* `os::getenv`          => `env::var` or `env::var_string`
* `os::getenv_as_bytes` => `env::var`
* `os::setenv`          => `env::set_var`
* `os::unsetenv`        => `env::remove_var`

Many function signatures have also been tweaked for various purposes, but the
main changes were:

* `Vec`-returning APIs now all return iterators instead
* All APIs are now centered around `OsString` instead of `Vec<u8>` or `String`.
  There is currently on convenience API, `env::var_string`, which can be used to
  get the value of an environment variable as a unicode `String`.

All old APIs are `#[deprecated]` in-place and will remain for some time to allow
for migrations. The semantics of the APIs have been tweaked slightly with regard
to dealing with invalid unicode (panic instead of replacement).

The new `std::env` module is all contained within the `env` feature, so crates
must add the following to access the new APIs:

    #![feature(env)]

[breaking-change]
2015-02-01 11:08:15 -08:00
Sébastien Marie
fcb30a0b67 openbsd support 2015-02-01 14:41:38 +01:00
Alex Crichton
3a2530d611 Test fixes and rebase conflicts
Also some tidying up of a bunch of crate attributes
2015-01-30 14:53:34 -08:00
Jorge Aparicio
a873316277 remove dead code 2015-01-30 10:37:44 -05:00
Jorge Aparicio
9fdc0effd2 implement for loop desugaring 2015-01-30 10:36:31 -05:00
bors
265a23320d Auto merge of #21677 - japaric:no-range, r=alexcrichton
Note: Do not merge until we get a newer snapshot that includes #21374

There was some type inference fallout (see 4th commit) because type inference with `a..b` is not as good as with `range(a, b)` (see #21672).

r? @alexcrichton
2015-01-29 16:28:52 +00:00
Jorge Aparicio
788181d405 s/Show/Debug/g 2015-01-29 07:49:02 -05:00
bors
3d6f5100af Auto merge of #21730 - Manishearth:rollup, r=alexcrichton
Should clear our backlog of rollups from the queue
2015-01-29 11:28:30 +00:00
bors
bedd8108dc Auto merge of #21680 - japaric:slice, r=alexcrichton
Replaces `slice_*` method calls with slicing syntax, and removes `as_slice()` calls that are redundant due to `Deref`.
2015-01-29 05:47:21 +00:00
Manish Goregaokar
f553f58b7f Rollup merge of 21681 - japaric:no-warn, r=alexcrichton 2015-01-29 03:14:35 +05:30
Jorge Aparicio
57dd4ea78d fix #[cfg(test)] warnings 2015-01-27 22:58:45 -05:00
Brian Anderson
7122305053 Merge remote-tracking branch 'rust-lang/master'
Conflicts:
	src/libcore/cell.rs
	src/librustc_driver/test.rs
	src/libstd/old_io/net/tcp.rs
	src/libstd/old_io/process.rs
2015-01-27 15:05:04 -08:00
Jorge Aparicio
bce81e2464 cleanup: s/v.slice*()/&v[a..b]/g + remove redundant as_slice() calls 2015-01-27 09:03:06 -05:00
bors
1c87af2eba Auto merge of #21646 - dotdash:default_target_cpu, r=Aatch
Using `generic` as the target cpu limits the generated code to the bare basics for the arch, while we can probably assume that we'll actually be running on somewhat modern hardware. This updates the default target CPUs for the x86 and x86_64 archs to match clang's behaviour.

Refs #20777
2015-01-27 05:15:04 +00:00
Brian Anderson
abc56a011a Make '-A warnings' apply to all warnings, including feature gate warnings 2015-01-26 16:29:27 -08:00
Alex Crichton
3a07f859b8 Fallout of io => old_io 2015-01-26 16:01:16 -08:00
Björn Steinbrink
296c74de96 Default to Pentium 4 as the x86 target CPU on Windows/Linux/DragonFly
Limiting ourselves to a generic x86 instruction set doesn't seem useful.
Both users running those systems on original i386 hardware might as well
manually specify a target cpu ;-)

Clang uses the same default.
2015-01-26 09:58:56 +01:00
Björn Steinbrink
bca25aeeb4 Use more specific target CPUs on Darwin
Macs don't come with anything older than a Yonah (32bit) or Core2 (64bit),
so we can default to those targets. Clang does the same.
2015-01-26 09:58:55 +01:00
Brian Anderson
d179ba3b8e Merge remote-tracking branch 'rust-lang/master'
Conflicts:
	src/libcore/cmp.rs
	src/libcore/fmt/mod.rs
	src/libcore/iter.rs
	src/libcore/marker.rs
	src/libcore/num/f32.rs
	src/libcore/num/f64.rs
	src/libcore/result.rs
	src/libcore/str/mod.rs
	src/librustc/lint/builtin.rs
	src/librustc/lint/context.rs
	src/libstd/sync/mpsc/mod.rs
	src/libstd/sync/poison.rs
2015-01-25 22:14:06 -08:00
Brian Anderson
63fcbcf3ce Merge remote-tracking branch 'rust-lang/master'
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-25 01:20:55 -08:00
Huon Wilson
2e888d0341 Add the span of the operator itself to ast::BinOp. 2015-01-25 00:33:50 +11:00
Brian Anderson
cd6d9eab5d Set unstable feature names appropriately
* `core` - for the core crate
* `hash` - hashing
* `io` - io
* `path` - path
* `alloc` - alloc crate
* `rand` - rand crate
* `collections` - collections crate
* `std_misc` - other parts of std
* `test` - test crate
* `rustc_private` - everything else
2015-01-23 13:28:40 -08:00
Brian Anderson
d3c0bb416e Put #[staged_api] behind the 'staged_api' gate 2015-01-22 13:47:56 -08:00
Brian Anderson
41278c5441 Remove 'since' from unstable attributes 2015-01-21 19:25:55 -08:00
Brian Anderson
7b73ec4698 Tie stability attributes to feature gates 2015-01-21 16:16:21 -08:00
Brian Anderson
94ca8a3610 Add 'feature' and 'since' to stability attributes 2015-01-21 16:16:18 -08:00
Alex Crichton
df1cddf20a rollup merge of #20179: eddyb/blind-items
Conflicts:
	src/librustc/diagnostics.rs
	src/librustdoc/clean/mod.rs
	src/librustdoc/html/format.rs
	src/libsyntax/parse/parser.rs
2015-01-21 11:56:00 -08:00
Alex Crichton
87c3ee861e rollup merge of #21457: alexcrichton/issue-21436
Conflicts:
	src/liballoc/boxed.rs
	src/librustc/middle/traits/error_reporting.rs
	src/libstd/sync/mpsc/mod.rs
2015-01-21 09:20:35 -08:00
Alex Crichton
a6780d8c6b rollup merge of #21414: ejjeong/aarch64-linux-android
Initial support for aarch64-linux-android (#18920)
- Add new configuration files
- Modify some options to compile & link succesfully.
  (PIE, disable tls on jemalloc, modify some external function linkage, ..)
- To build, refer to https://github.com/rust-lang/rust/wiki/Doc-building-for-android.
   (tested with platform=21 and toolchain=aarch64-linux-android-4.9)
2015-01-21 09:15:59 -08:00
Alex Crichton
1646707c6e rollup merge of #21396: japaric/no-parens-in-range
Conflicts:
	src/libsyntax/parse/lexer/comments.rs
2015-01-21 09:15:15 -08:00
Eduard Burtescu
e389ab18a2 rustc_back: fix fallout of merging ast::ViewItem into ast::Item. 2015-01-21 16:27:26 +02:00
Alex Crichton
3cb9fa26ef std: Rename Show/String to Debug/Display
This commit is an implementation of [RFC 565][rfc] which is a stabilization of
the `std::fmt` module and the implementations of various formatting traits.
Specifically, the following changes were performed:

[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0565-show-string-guidelines.md

* The `Show` trait is now deprecated, it was renamed to `Debug`
* The `String` trait is now deprecated, it was renamed to `Display`
* Many `Debug` and `Display` implementations were audited in accordance with the
  RFC and audited implementations now have the `#[stable]` attribute
  * Integers and floats no longer print a suffix
  * Smart pointers no longer print details that they are a smart pointer
  * Paths with `Debug` are now quoted and escape characters
* The `unwrap` methods on `Result` now require `Display` instead of `Debug`
* The `Error` trait no longer has a `detail` method and now requires that
  `Display` must be implemented. With the loss of `String`, this has moved into
  libcore.
* `impl<E: Error> FromError<E> for Box<Error>` now exists
* `derive(Show)` has been renamed to `derive(Debug)`. This is not currently
  warned about due to warnings being emitted on stage1+

While backwards compatibility is attempted to be maintained with a blanket
implementation of `Display` for the old `String` trait (and the same for
`Show`/`Debug`) this is still a breaking change due to primitives no longer
implementing `String` as well as modifications such as `unwrap` and the `Error`
trait. Most code is fairly straightforward to update with a rename or tweaks of
method calls.

[breaking-change]
Closes #21436
2015-01-20 22:36:13 -08:00
Barosl LEE
1d8b917811 Rollup merge of #20998 - estsauver:20984, r=steveklabnik
There are a large number of places that incorrectly refer
to deriving in comments, instead of derives.

If someone could look at src/etc/generate-deriving-span-tests.py,
I'm not sure how those tests were passing before/if they were.
2015-01-21 02:16:45 +09:00
Eunji Jeong
940080501b Initial support for aarch64-linux-android 2015-01-20 17:43:15 +09:00
Jorge Aparicio
49684850be remove unnecessary parentheses from range notation 2015-01-19 12:24:43 -05:00
Brian Anderson
6f3a80e411 Set allow(unstable) in crates that use unstable features
Lets them build with the -dev, -nightly, or snapshot compiler
2015-01-17 16:38:04 -08:00
Earl St Sauver
6ab95bdd62 s/deriving/derives in Comments/Docs
There are a large number of places that incorrectly refer
to deriving in comments, instead of derives.

Fixes #20984
2015-01-17 11:08:02 -08:00
Eduard Burtescu
2cdc86c180 syntax: add fully qualified UFCS expressions. 2015-01-15 18:51:14 +02:00
bors
0c96037ec1 auto merge of #20980 : richo/rust/final-power, r=alexcrichton
Originally, this was going to be discussed and revisted, however I've been working on this for months, and a rebase on top of master was about 1 flight's worth of work so I just went ahead and did it.

This gets you as far as being able to target powerpc with, eg:

    LD_LIBRARY_PATH=./x86_64-unknown-linux-gnu/stage2/lib/ x86_64-unknown-linux-gnu/stage2/bin/rustc -C linker=powerpc-linux-gnu-gcc --target powerpc-unknown-linux-gnu hello.rs

Would really love to get this out before 1.0. r? @alexcrichton
2015-01-15 05:12:30 +00:00
Jorge Aparicio
c1d48a8508 cleanup: &foo[0..a] -> &foo[..a] 2015-01-12 17:59:37 -05:00
Richo Healey
c055d99526 powerpc: Teach trans about powerpc 2015-01-11 21:14:31 -08:00
Richo Healey
33cd9cf9f4 powerpc: initialize llvm 2015-01-11 21:14:31 -08:00
Richo Healey
c8442afeb0 powerpc: Add backend support for powerpc 2015-01-11 21:14:30 -08:00
Björn Steinbrink
14b6c6d153 Default to "x86-64" as the target cpu for x86_64 builds
Using "generic" disables a number of features that are present on all
x86_64 cpus, the "x86-64" target cpu is the common denominator for that
arch.

Refs #20777
2015-01-11 12:26:54 +01:00
bors
87ed884a9c Merge pull request #20699 from vhbit/ios-archs
Better iOS support

Reviewed-by: alexcrichton
2015-01-09 17:35:09 +00:00
Valerii Hiora
577d0dbcb8 iOS: preliminary 64-bit archs support 2015-01-09 18:38:30 +02:00
Valerii Hiora
1fb91dc1c2 iOS: updated targets
- target_word_size -> target_pointer_width
- added armv7 and armv7s targets
- enabled building binaries so tests could be run on a jailbroken device
2015-01-09 18:23:42 +02:00
Alex Crichton
4281bd1932 rollup merge of #20754: nikomatsakis/int-feature
Conflicts:
	src/test/compile-fail/borrowck-move-out-of-overloaded-auto-deref.rs
	src/test/compile-fail/issue-2590.rs
	src/test/compile-fail/lint-stability.rs
	src/test/compile-fail/slice-mut-2.rs
	src/test/compile-fail/std-uncopyable-atomics.rs
2015-01-08 09:24:08 -08:00
Huon Wilson
4f5a57e80e Remove warning from the libraries.
This adds the int_uint feature to *every* library, whether or not it
needs it.
2015-01-08 11:02:23 -05:00
Brian Anderson
1f70acbf4c Improvements to feature staging
This gets rid of the 'experimental' level, removes the non-staged_api
case (i.e. stability levels for out-of-tree crates), and lets the
staged_api attributes use 'unstable' and 'deprecated' lints.

This makes the transition period to the full feature staging design
a bit nicer.
2015-01-08 03:07:23 -08:00
Alex Crichton
0dc48b47a8 Test fixes and rebase conflicts 2015-01-07 19:27:27 -08:00
Alex Crichton
6e806bdefd rollup merge of #20721: japaric/snap
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 17:26:58 -08:00
Alex Crichton
dd38f46d71 rollup merge of #20708: aturon/new-int-modules
Conflicts:
	src/libserialize/lib.rs
2015-01-07 17:18:01 -08:00
Alex Crichton
6301c7878e rollup merge of #20680: nick29581/target-word
Closes #20421

[breaking-change]

r? @brson
2015-01-07 17:17:23 -08:00
Alex Crichton
f3b67afcab rollup merge of #20663: brson/feature-staging
This partially implements the feature staging described in the
[release channel RFC][rc]. It does not yet fully conform to the RFC as
written, but does accomplish its goals sufficiently for the 1.0 alpha
release.

It has three primary user-visible effects:

* On the nightly channel, use of unstable APIs generates a warning.
* On the beta channel, use of unstable APIs generates a warning.
* On the beta channel, use of feature gates generates a warning.

Code that does not trigger these warnings is considered 'stable',
modulo pre-1.0 bugs.

Disabling the warnings for unstable APIs continues to be done in the
existing (i.e. old) style, via `#[allow(...)]`, not that specified in
the RFC. I deem this marginally acceptable since any code that must do
this is not using the stable dialect of Rust.

Use of feature gates is itself gated with the new 'unstable_features'
lint, on nightly set to 'allow', and on beta 'warn'.

The attribute scheme used here corresponds to an older version of the
RFC, with the `#[staged_api]` crate attribute toggling the staging
behavior of the stability attributes, but the user impact is only
in-tree so I'm not concerned about having to make design changes later
(and I may ultimately prefer the scheme here after all, with the
`#[staged_api]` crate attribute).

Since the Rust codebase itself makes use of unstable features the
compiler and build system do a midly elaborate dance to allow it to
bootstrap while disobeying these lints (which would otherwise be
errors because Rust builds with `-D warnings`).

This patch includes one significant hack that causes a
regression. Because the `format_args!` macro emits calls to unstable
APIs it would trigger the lint.  I added a hack to the lint to make it
not trigger, but this in turn causes arguments to `println!` not to be
checked for feature gates. I don't presently understand macro
expansion well enough to fix. This is bug #20661.

Closes #16678

[rc]: https://github.com/rust-lang/rfcs/blob/master/text/0507-release-channels.md

Next steps are to disable the existing out-of-tree behavior for stability attributes, and convert the remaining system to be feature-based per the RFC. During the first beta cycle we will set these lints to 'forbid'.
2015-01-07 17:17:22 -08:00
Alex Crichton
8bf3ee7c5c rollup merge of #20654: alexcrichton/stabilize-hash
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 17:17:19 -08:00
Brian Anderson
c27133e2ce Preliminary feature staging
This partially implements the feature staging described in the
[release channel RFC][rc]. It does not yet fully conform to the RFC as
written, but does accomplish its goals sufficiently for the 1.0 alpha
release.

It has three primary user-visible effects:

* On the nightly channel, use of unstable APIs generates a warning.
* On the beta channel, use of unstable APIs generates a warning.
* On the beta channel, use of feature gates generates a warning.

Code that does not trigger these warnings is considered 'stable',
modulo pre-1.0 bugs.

Disabling the warnings for unstable APIs continues to be done in the
existing (i.e. old) style, via `#[allow(...)]`, not that specified in
the RFC. I deem this marginally acceptable since any code that must do
this is not using the stable dialect of Rust.

Use of feature gates is itself gated with the new 'unstable_features'
lint, on nightly set to 'allow', and on beta 'warn'.

The attribute scheme used here corresponds to an older version of the
RFC, with the `#[staged_api]` crate attribute toggling the staging
behavior of the stability attributes, but the user impact is only
in-tree so I'm not concerned about having to make design changes later
(and I may ultimately prefer the scheme here after all, with the
`#[staged_api]` crate attribute).

Since the Rust codebase itself makes use of unstable features the
compiler and build system to a midly elaborate dance to allow it to
bootstrap while disobeying these lints (which would otherwise be
errors because Rust builds with `-D warnings`).

This patch includes one significant hack that causes a
regression. Because the `format_args!` macro emits calls to unstable
APIs it would trigger the lint.  I added a hack to the lint to make it
not trigger, but this in turn causes arguments to `println!` not to be
checked for feature gates. I don't presently understand macro
expansion well enough to fix. This is bug #20661.

Closes #16678

[rc]: https://github.com/rust-lang/rfcs/blob/master/text/0507-release-channels.md
2015-01-07 15:34:56 -08:00
Jorge Aparicio
517f1cc63c use slicing sugar 2015-01-07 17:35:56 -05:00
Alex Crichton
511f0b8a3d std: Stabilize the std::hash module
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 12:18:08 -08:00
Nick Cameron
dd3e89aaf2 Rename target_word_size to target_pointer_width
Closes #20421

[breaking-change]
2015-01-08 09:07:55 +13:00
Alex Crichton
b53e9f17d3 Register new snapshots 2015-01-07 10:27:52 -08:00
bors
c0216c8945 Merge pull request #20674 from jbcrail/fix-misspelled-comments
Fix misspelled comments.

Reviewed-by: steveklabnik
2015-01-07 15:35:30 +00:00
Joseph Crail
e3b7fedc20 Fix misspelled comments.
I cleaned up comments prior to the 1.0 alpha release.
2015-01-06 20:53:18 -05:00
Alex Crichton
e2f97f51ad Register new snapshots
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-06 15:24:24 -08:00
Alex Crichton
5c3ddcb15d rollup merge of #20481: seanmonstar/fmt-show-string
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 15:22:24 -08:00
Nick Cameron
0c7f7a5fb8 fallout 2015-01-07 12:02:52 +13:00
Sean McArthur
44440e5c18 core: split into fmt::Show and fmt::String
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 14:49:42 -08:00
Nick Cameron
f7ff37e4c5 Replace full slice notation with index calls 2015-01-07 10:46:33 +13:00
Keegan McAllister
416137eb31 Modernize macro_rules! invocations
macro_rules! is like an item that defines a macro.  Other items don't have a
trailing semicolon, or use a paren-delimited body.

If there's an argument for matching the invocation syntax, e.g. parentheses for
an expr macro, then I think that applies more strongly to the *inner*
delimiters on the LHS, wrapping the individual argument patterns.
2015-01-05 18:21:14 -08:00
Keegan McAllister
c9f0ff3813 Reserve the keyword 'macro' 2015-01-05 18:21:14 -08:00
Keegan McAllister
60be2f52d2 Replace #[phase] with #[plugin] / #[macro_use] / #[no_link] 2015-01-05 18:21:13 -08:00
Jorge Aparicio
351409a622 sed -i -s 's/#\[deriving(/#\[derive(/g' **/*.rs 2015-01-03 22:54:18 -05:00
Akos Kiss
6e5fb8bd1b Initial version of AArch64 support.
Adds AArch64 knowledge to:
* configure,
* make files,
* sources,
* tests, and
* documentation.
2015-01-03 15:16:10 +00:00
Alex Crichton
735c308aed rollup merge of #20416: nikomatsakis/coherence
Conflicts:
	src/test/run-pass/issue-15734.rs
	src/test/run-pass/issue-3743.rs
2015-01-02 09:23:42 -08:00
Niko Matsakis
c61a0092bc Fix orphan checking (cc #19470). (This is not a complete fix of #19470 because of the backwards compatibility feature gate.)
This is a [breaking-change]. The new rules require that, for an impl of a trait defined
in some other crate, two conditions must hold:

1. Some type must be local.
2. Every type parameter must appear "under" some local type.

Here are some examples that are legal:

```rust
struct MyStruct<T> { ... }

// Here `T` appears "under' `MyStruct`.
impl<T> Clone for MyStruct<T> { }

// Here `T` appears "under' `MyStruct` as well. Note that it also appears
// elsewhere.
impl<T> Iterator<T> for MyStruct<T> { }
```

Here is an illegal example:

```rust
// Here `U` does not appear "under" `MyStruct` or any other local type.
// We call `U` "uncovered".
impl<T,U> Iterator<U> for MyStruct<T> { }
```

There are a couple of ways to rewrite this last example so that it is
legal:

1. In some cases, the uncovered type parameter (here, `U`) should be converted
   into an associated type. This is however a non-local change that requires access
   to the original trait. Also, associated types are not fully baked.
2. Add `U` as a type parameter of `MyStruct`:
   ```rust
   struct MyStruct<T,U> { ... }
   impl<T,U> Iterator<U> for MyStruct<T,U> { }
   ```
3. Create a newtype wrapper for `U`
   ```rust
   impl<T,U> Iterator<Wrapper<U>> for MyStruct<T,U> { }
   ```

Because associated types are not fully baked, which in the case of the
`Hash` trait makes adhering to this rule impossible, you can
temporarily disable this rule in your crate by using
`#![feature(old_orphan_check)]`. Note that the `old_orphan_check`
feature will be removed before 1.0 is released.
2015-01-02 04:06:09 -05:00
Nick Cameron
7e2b9ea235 Fallout - change array syntax to use ; 2015-01-02 10:28:19 +13:00
Jorge Aparicio
a6f3053208 rustc_back: unbox closures used in let bindings 2014-12-31 22:50:26 -05:00
Alex Crichton
582cba183f Test fixes and rebase conflicts 2014-12-31 08:33:13 -08:00
Aaron Turon
6abfac083f Fallout from stabilization 2014-12-30 17:06:08 -08:00
Alex Crichton
f8fc141c5e rollup merge of #20271: vhbit/datalayout-fix
According to http://llvm.org/docs/LangRef.html#data-layout correct syntax
for data layout is `a:<abi>:<pref>` so it looks like  `a0:<abi>:<pref>` is
either a typo or outdated syntax (as it goes back pretty deep in time)
2014-12-29 16:36:38 -08:00
Nick Cameron
3bf405682d Fallout from mut slices 2014-12-30 13:06:25 +13:00
Nick Cameron
4e2afb0052 Remove ExprSlice by hacking the compiler
[breaking-change]

The `mut` in slices is now redundant. Mutability is 'inferred' from position. This means that if mutability is only obvious from the type, you will need to use explicit calls to the slicing methods.
2014-12-30 13:06:25 +13:00
Valerii Hiora
b94bb8766e Fixes invalid LLVM data layout for aggregate data types
According to http://llvm.org/docs/LangRef.html#data-layout correct syntax
for data layout is `a:<abi>:<pref>` so it looks like  `a0:<abi>:<pref>` is
either a typo or outdated syntax (as it goes back pretty deep in time)
2014-12-28 08:31:23 +02:00
bors
ead198c513 auto merge of #20024 : mneumann/rust/dragonfly-fixes3, r=alexcrichton 2014-12-25 05:11:36 +00:00
Nick Cameron
8a357e1d87 Add syntax for ranges 2014-12-24 09:12:45 +13:00
Alex Crichton
082bfde412 Fallout of std::str stabilization 2014-12-21 23:31:42 -08:00
Michael Neumann
25c1bfe175 Several fixes for DragonFly (rebase) 2014-12-19 13:05:06 +01:00
Patrick Walton
ddb2466f6a librustc: Always parse macro!()/macro![] as expressions if not
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-12-18 12:09:07 -05:00
Niko Matsakis
d258d68db6 Remove proc types/expressions from the parser, compiler, and
language. Recommend `move||` instead.
2014-12-14 04:21:56 -05:00
Jorge Aparicio
451eef5c40 librustc_back: use unboxed closures 2014-12-13 17:03:47 -05:00
Jorge Aparicio
71d8d578c6 librustc_back: remove unnecessary to_string() calls 2014-12-06 23:53:02 -05:00
Jorge Aparicio
7d8eabb226 librustc_back: remove unnecessary as_slice() calls 2014-12-06 19:05:58 -05:00
Jorge Aparicio
09707d70a4 Fix fallout 2014-12-03 10:41:48 -05:00
bors
66601647cd auto merge of #19343 : sfackler/rust/less-special-attrs, r=alexcrichton
Descriptions and licenses are handled by Cargo now, so there's no reason
to keep these attributes around.
2014-11-27 06:41:17 +00:00
Steven Fackler
348cc9418a Remove special casing for some meta attributes
Descriptions and licenses are handled by Cargo now, so there's no reason
to keep these attributes around.
2014-11-26 11:44:45 -08:00
Ben S
3b9dfd6af0 Clean up FileType enum following enum namespacing
All of the enum components had a redundant 'Type' specifier: TypeSymlink, TypeDirectory, TypeFile. This change removes them, replacing them with a namespace: FileType::Symlink, FileType::Directory, and FileType::RegularFile.

RegularFile is used instead of just File, as File by itself could be mistakenly thought of as referring to the struct.

[breaking-change]
2014-11-24 23:01:15 +00:00
Jakub Bukaj
3594c588bb rollup merge of #19211: aochagavia/tuple-index
This breaks code like

```
let t = (42i, 42i);
... t.0::<int> ...;
```

Change this code to not contain an unused type parameter. For example:

```
let t = (42i, 42i);
... t.0 ...;
```

Closes https://github.com/rust-lang/rust/issues/19096

[breaking-change]

r? @aturon
2014-11-23 14:11:56 -05:00
Adolfo Ochagavía
35316972ff Remove type parameters from ExprField and ExprTupField 2014-11-23 12:17:43 +01:00
bors
f5212e3cd7 auto merge of #18856 : ruud-v-a/rust/fatptrs, r=cmr
This merges the `trt_field_*`, `fn_field_*` and `slice_elt_*` constants into two `fat_ptr_*` constants. This resolves the first part of #18590.
2014-11-23 07:51:51 +00:00
bors
97c043b2e9 auto merge of #19114 : frewsxcv/rust/master, r=bstrie
Fixes #19010
2014-11-21 19:06:52 +00:00
Ruud van Asseldonk
c724131a86 rustc: Change all ABI constants to all caps.
This also removes `box_field_refcnt`. It was not used anywhere.
2014-11-21 17:49:11 +01:00
Ruud van Asseldonk
b781c8b08e rustc: Unify fat pointer ABI constants.
This merges the `trt_field_*`, `fn_field_*` and `slice_elt_*` constants
into two `FAT_PTR_*` constants. This resolves the first part of #18590.
2014-11-21 17:49:11 +01:00
bors
1d81776209 auto merge of #19113 : nikomatsakis/rust/unboxed-boxed-closure-unification, r=acrichto
Use the expected type to infer the argument/return types of unboxed closures. Also, in `||` expressions, use the expected type to decide if the result should be a boxed or unboxed closure (and if an unboxed closure, what kind).

This supercedes PR #19089, which was already reviewed by @pcwalton.
2014-11-20 12:01:44 +00:00
Jakub Bukaj
1faa09615e rollup merge of #19073: jakub-/issue-19069
Fixes #19069.

These were never intended not to be feature-gated but this PR is nonetheless a...

[breaking-change]
2014-11-19 22:39:12 +01:00
Niko Matsakis
3e2929d362 Merge the ExprFnBlock and ExprUnboxedClosure into one ExprClosure with an optional unboxed closure kind. 2014-11-19 13:35:20 -05:00
Corey Farwell
d8a5242195 Rename json::List to json::Array
Fixes #19010
2014-11-19 13:23:05 -05:00
Jakub Bukaj
bde225e2fa Feature gate non-ASCII lifetime identifiers
Fixes #19069.
2014-11-18 23:07:14 +01:00
Barosl Lee
6f422c4c05 Make os::getcwd() return IoResult<Path>
os::getcwd() panics if the current directory is not available. According
to getcwd(3), there are three cases:

- EACCES: Permission denied.
- ENOENT: The current working directory has been removed.
- ERANGE: The buffer size is less than the actual absolute path.

This commit makes os::getcwd() return IoResult<Path>, not just Path,
preventing it from panicking.

As os::make_absolute() depends on os::getcwd(), it is also modified to
return IoResult<Path>.

Fixes #16946.

[breaking-change]
2014-11-19 05:31:45 +09:00
Steven Fackler
3dcd215740 Switch to purely namespaced enums
This breaks code that referred to variant names in the same namespace as
their enum. Reexport the variants in the old location or alter code to
refer to the new locations:

```
pub enum Foo {
    A,
    B
}

fn main() {
    let a = A;
}
```
=>
```
pub use self::Foo::{A, B};

pub enum Foo {
    A,
    B
}

fn main() {
    let a = A;
}
```
or
```
pub enum Foo {
    A,
    B
}

fn main() {
    let a = Foo::A;
}
```

[breaking-change]
2014-11-17 07:35:51 -08:00
Nick Cameron
ca08540a00 Fix fallout from coercion removal 2014-11-17 22:41:33 +13:00
Brendan Zabarauskas
e965ba85ca Remove lots of numeric traits from the preludes
Num, NumCast, Unsigned, Float, Primitive and Int have been removed.
2014-11-13 03:46:03 +11:00
Brendan Zabarauskas
46333d527b Deprecate Zero and One traits 2014-11-13 02:04:31 +11:00
Brendan Zabarauskas
0da49dcf13 Deprecate Bounded trait 2014-11-13 02:02:44 +11:00
Brendan Zabarauskas
e51cc089da Move checked arithmetic operators into Int trait 2014-11-13 02:02:44 +11:00
Valerii Hiora
a722f70207 Properly static lib packaging
Fixes #18574
2014-11-07 19:14:22 +02:00
Alex Crichton
11a4f7b4c9 rollup merge of #18683 : thestinger/typo 2014-11-06 13:53:25 -08:00
Alex Crichton
4fa22d951f rollup merge of #18647 : jbcrail/rename-dragonfly 2014-11-06 13:31:52 -08:00
Alex Crichton
b5ca21ee92 rollup merge of #18636 : luqmana/armf 2014-11-06 13:31:35 -08:00
Daniel Micay
cfae691e46 fix typo in librustc target spec 2014-11-06 00:17:56 -05:00
Joseph Crail
1d4b024542 Add missing dragonfly module. 2014-11-05 10:37:08 -05:00
Joseph Crail
a31e3d6de3 Rename misspelled module reference. 2014-11-05 10:37:08 -05:00
Nick Cameron
04dd61d1ec Make trans::adt know that some structs are unsized 2014-11-05 16:53:09 +13:00
Luqman Aden
2c09da7d1e librustc_back: Fix triple for linux armhf. 2014-11-04 18:13:37 -05:00
Corey Richardson
61aeab4c9e Update for collections reform 2014-11-04 05:35:53 -05:00
Corey Richardson
70dedbb1a2 Don't use pie on Android 2014-11-04 05:07:47 -05:00
Corey Richardson
244bb14fd5 Same fix for dragonfly 2014-11-04 05:07:47 -05:00
Corey Richardson
4a6f4c9606 Same fix for mac32 2014-11-04 05:07:47 -05:00
Corey Richardson
0e03503f53 Use -m32 on 32bit Linux 2014-11-04 05:07:47 -05:00
Corey Richardson
6b130e3dd9 Implement flexible target specification
Removes all target-specific knowledge from rustc. Some targets have changed
during this, but none of these should be very visible outside of
cross-compilation. The changes make our targets more consistent.

iX86-unknown-linux-gnu is now only available as i686-unknown-linux-gnu. We
used to accept any value of X greater than 1. i686 was released in 1995, and
should encompass the bare minimum of what Rust supports on x86 CPUs.

The only two windows targets are now i686-pc-windows-gnu and
x86_64-pc-windows-gnu.

The iOS target has been renamed from arm-apple-ios to arm-apple-darwin.

A complete list of the targets we accept now:

arm-apple-darwin
arm-linux-androideabi
arm-unknown-linux-gnueabi
arm-unknown-linux-gnueabihf

i686-apple-darwin
i686-pc-windows-gnu
i686-unknown-freebsd
i686-unknown-linux-gnu

mips-unknown-linux-gnu
mipsel-unknown-linux-gnu

x86_64-apple-darwin
x86_64-unknown-freebsd
x86_64-unknown-linux-gnu
x86_64-pc-windows-gnu

Closes #16093

[breaking-change]
2014-11-04 05:07:47 -05:00
Alex Crichton
00975e041d rollup merge of #18398 : aturon/lint-conventions-2
Conflicts:
	src/libcollections/slice.rs
	src/libcore/failure.rs
	src/libsyntax/parse/token.rs
	src/test/debuginfo/basic-types-mut-globals.rs
	src/test/debuginfo/simple-struct.rs
	src/test/debuginfo/trait-pointers.rs
2014-10-30 17:37:22 -07: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
Aaron Turon
e0ad0fcb95 Update code with new lint names 2014-10-28 08:54:21 -07:00
Luqman Aden
7210a5af87 librustc: Stop generating visit glue and remove from TyDesc. 2014-10-16 11:15:36 -04:00
bors
c7e0724274 auto merge of #17733 : jgallagher/rust/while-let, r=alexcrichton
This is *heavily* based on `if let` (#17634) by @jakub- and @kballard

This should close #17687
2014-10-13 19:37:40 +00:00
Michael Gehring
151aaaf46b Fix cfg warnings in librustc_back 2014-10-11 18:33:17 +02:00
John Gallagher
45fd623762 Handle while let desugaring 2014-10-10 20:30:32 -04:00
bors
f9fc49c06e auto merge of #17853 : alexcrichton/rust/issue-17718, r=pcwalton
This change is an implementation of [RFC 69][rfc] which adds a third kind of
global to the language, `const`. This global is most similar to what the old
`static` was, and if you're unsure about what to use then you should use a
`const`.

The semantics of these three kinds of globals are:

* A `const` does not represent a memory location, but only a value. Constants
  are translated as rvalues, which means that their values are directly inlined
  at usage location (similar to a #define in C/C++). Constant values are, well,
  constant, and can not be modified. Any "modification" is actually a
  modification to a local value on the stack rather than the actual constant
  itself.

  Almost all values are allowed inside constants, whether they have interior
  mutability or not. There are a few minor restrictions listed in the RFC, but
  they should in general not come up too often.

* A `static` now always represents a memory location (unconditionally). Any
  references to the same `static` are actually a reference to the same memory
  location. Only values whose types ascribe to `Sync` are allowed in a `static`.
  This restriction is in place because many threads may access a `static`
  concurrently. Lifting this restriction (and allowing unsafe access) is a
  future extension not implemented at this time.

* A `static mut` continues to always represent a memory location. All references
  to a `static mut` continue to be `unsafe`.

This is a large breaking change, and many programs will need to be updated
accordingly. A summary of the breaking changes is:

* Statics may no longer be used in patterns. Statics now always represent a
  memory location, which can sometimes be modified. To fix code, repurpose the
  matched-on-`static` to a `const`.

      static FOO: uint = 4;
      match n {
          FOO => { /* ... */ }
          _ => { /* ... */ }
      }

  change this code to:

      const FOO: uint = 4;
      match n {
          FOO => { /* ... */ }
          _ => { /* ... */ }
      }

* Statics may no longer refer to other statics by value. Due to statics being
  able to change at runtime, allowing them to reference one another could
  possibly lead to confusing semantics. If you are in this situation, use a
  constant initializer instead. Note, however, that statics may reference other
  statics by address, however.

* Statics may no longer be used in constant expressions, such as array lengths.
  This is due to the same restrictions as listed above. Use a `const` instead.

[breaking-change]
Closes #17718 

[rfc]: https://github.com/rust-lang/rfcs/pull/246
2014-10-10 00:07:08 +00:00
Brian Anderson
5c92a8e054 Use the same html_root_url for all docs 2014-10-09 10:50:13 -07:00
Alex Crichton
831f909484 rustc: Convert statics to constants 2014-10-09 09:44:51 -07:00
Nick Cameron
2d3823441f Put slicing syntax behind a feature gate.
[breaking-change]

If you are using slicing syntax you will need to add #![feature(slicing_syntax)] to your crate.
2014-10-07 15:49:53 +13:00
Nick Cameron
59976942ea Use slice syntax instead of slice_to, etc. 2014-10-07 15:49:53 +13:00
P1start
e3ca987f74 Rename the file permission statics in std::io to be uppercase
For example, this renames `GroupRWX` to `GROUP_RWX`, and deprecates the old
name. Code using these statics should be updated accordingly.
2014-10-06 16:43:34 +13:00
P1start
94bcd3539c Set the non_uppercase_statics lint to warn by default 2014-10-03 20:39:56 +13:00
Aaron Turon
d2ea0315e0 Revert "Use slice syntax instead of slice_to, etc."
This reverts commit 40b9f5ded5.
2014-10-02 11:48:07 -07:00
Aaron Turon
7bf56df4c8 Revert "Put slicing syntax behind a feature gate."
This reverts commit 95cfc35607.
2014-10-02 11:47:51 -07:00
Nick Cameron
95cfc35607 Put slicing syntax behind a feature gate.
[breaking-change]

If you are using slicing syntax you will need to add #![feature(slicing_syntax)] to your crate.
2014-10-02 13:23:36 +13:00
Nick Cameron
40b9f5ded5 Use slice syntax instead of slice_to, etc. 2014-10-02 13:19:45 +13:00
bors
ff2616e847 auto merge of #17630 : sfackler/rust/cfg-warnings, r=brson
Closes #17490
2014-10-01 09:22:15 +00:00
bors
2f15dcd4d3 auto merge of #17584 : pcwalton/rust/range-patterns-dotdotdot, r=nick29581
This breaks code that looks like:

    match foo {
        1..3 => { ... }
    }

Instead, write:

    match foo {
        1...3 => { ... }
    }

Closes #17295.

r? @nick29581
2014-10-01 03:17:24 +00:00
Steven Fackler
d2caea2beb Fix librustc_back 2014-09-30 12:52:47 -07:00
Kevin Ballard
0e6ff432dc Desugar 'if let' into the appropriate 'match' 2014-09-30 18:54:02 +02:00
Patrick Walton
416144b827 librustc: Forbid .. in range patterns.
This breaks code that looks like:

    match foo {
        1..3 => { ... }
    }

Instead, write:

    match foo {
        1...3 => { ... }
    }

Closes #17295.

[breaking-change]
2014-09-30 09:11:26 -07:00
Nick Cameron
31a7e38759 Implement slicing syntax.
`expr[]`, `expr[expr..]`, `expr[..expr]`,`expr[expr..expr]`

Uses the Slice and SliceMut traits.

Allows ... as well as .. in range patterns.
2014-09-19 11:15:49 +12:00
Aaron Turon
fc525eeb4e Fallout from renaming 2014-09-16 14:37:48 -07:00
Daniel Micay
d206f05132 remove the closure_exchange_malloc lang item 2014-09-15 18:16:33 -04:00
bors
13037a3727 auto merge of #17163 : pcwalton/rust/impls-next-to-struct, r=alexcrichton
type they provide an implementation for.

This breaks code like:

    mod foo {
        struct Foo { ... }
    }

    impl foo::Foo {
        ...
    }

Change this code to:

    mod foo {
        struct Foo { ... }

        impl Foo {
            ...
        }
    }

Closes #17059.

RFC #155.

[breaking-change]

r? @brson
2014-09-14 08:11:04 +00:00
Eduard Burtescu
b06212864f rustc: fix fallout from using ptr::P. 2014-09-14 04:20:34 +03:00
Patrick Walton
467bea04fa librustc: Forbid inherent implementations that aren't adjacent to the
type they provide an implementation for.

This breaks code like:

    mod foo {
        struct Foo { ... }
    }

    impl foo::Foo {
        ...
    }

Change this code to:

    mod foo {
        struct Foo { ... }

        impl Foo {
            ...
        }
    }

Additionally, if you used the I/O path extension methods `stat`,
`lstat`, `exists`, `is_file`, or `is_dir`, note that these methods have
been moved to the the `std::io::fs::PathExtensions` trait. This breaks
code like:

    fn is_it_there() -> bool {
        Path::new("/foo/bar/baz").exists()
    }

Change this code to:

    use std::io::fs::PathExtensions;

    fn is_it_there() -> bool {
        Path::new("/foo/bar/baz").exists()
    }

Closes #17059.

RFC #155.

[breaking-change]
2014-09-13 02:07:39 -07:00
bors
8780d9c6b5 auto merge of #17134 : vberger/rust/lint_unused_extern_crate, r=alexcrichton
This PR creates a new lint : ``unused_extern_crate``, which do pretty much the same thing as ``unused_import``, but for ``extern crate`` statements. It is related to feature request #10385.

I adapted the code tracking used imports so that it tracks extern crates usage as well. This was mainly trial and error and while I believe all cases are covered, there might be some code I added that is useless (long compile times didn't give me the opportunity to check this in detail).

Also, I removed some unused ``extern crate`` statements from the libs, that where spotted by this new lint.
2014-09-12 19:05:53 +00:00
Eduard Burtescu
7ef6ff0669 Track the visited AST's lifetime throughout Visitor. 2014-09-12 14:24:45 +03:00
Eduard Burtescu
a09dbf28e6 Remove largely unused context from Visitor. 2014-09-12 14:24:45 +03:00
Victor Berger
8e61612889 Removing unused extern crates. 2014-09-12 11:24:31 +02:00
P1start
bf274bc18b Implement tuple and tuple struct indexing
This allows code to access the fields of tuples and tuple structs:

    let x = (1i, 2i);
    assert_eq!(x.1, 2);

    struct Point(int, int);
    let origin = Point(0, 0);
    assert_eq!(origin.0, 0);
    assert_eq!(origin.1, 0);
2014-09-10 10:25:12 +12:00
Joseph Crail
b7bfe04b2d Fix spelling errors and capitalization. 2014-09-03 23:10:38 -04:00
Nick Cameron
3e626375d8 DST coercions and DST structs
[breaking-change]

1. The internal layout for traits has changed from (vtable, data) to (data, vtable). If you were relying on this in unsafe transmutes, you might get some very weird and apparently unrelated errors. You should not be doing this! Prefer not to do this at all, but if you must, you should use raw::TraitObject rather than hardcoding rustc's internal representation into your code.

2. The minimal type of reference-to-vec-literals (e.g., `&[1, 2, 3]`) is now a fixed size vec (e.g., `&[int, ..3]`) where it used to be an unsized vec (e.g., `&[int]`). If you want the unszied type, you must explicitly give the type (e.g., `let x: &[_] = &[1, 2, 3]`). Note in particular where multiple blocks must have the same type (e.g., if and else clauses, vec elements), the compiler will not coerce to the unsized type without a hint. E.g., `[&[1], &[1, 2]]` used to be a valid expression of type '[&[int]]'. It no longer type checks since the first element now has type `&[int, ..1]` and the second has type &[int, ..2]` which are incompatible.

3. The type of blocks (including functions) must be coercible to the expected type (used to be a subtype). Mostly this makes things more flexible and not less (in particular, in the case of coercing function bodies to the return type). However, in some rare cases, this is less flexible. TBH, I'm not exactly sure of the exact effects. I think the change causes us to resolve inferred type variables slightly earlier which might make us slightly more restrictive. Possibly it only affects blocks with unreachable code. E.g., `if ... { fail!(); "Hello" }` used to type check, it no longer does. The fix is to add a semicolon after the string.
2014-08-26 12:38:51 +12:00
Nick Cameron
34d607f9c9 Use the slice repr for ~[T] 2014-08-26 12:37:45 +12:00
Patrick Walton
67deb2e65e libsyntax: Remove the use foo = bar syntax from the language in favor
of `use bar as foo`.

Change all uses of `use foo = bar` to `use bar as foo`.

Implements RFC #47.

Closes #16461.

[breaking-change]
2014-08-18 09:19:10 -07:00
bors
6b5ec40d45 auto merge of #16435 : vadimcn/rust/windows, r=pcwalton
Using "win32" to mean "Windows" is confusing, especially now, that Rust supports win64 builds.
Let's call spade a spade.
2014-08-15 00:46:19 +00:00
Patrick Walton
9907fa4acc librustc: Stop assuming that implementations and traits only contain
methods.

This paves the way to associated items by introducing an extra level of
abstraction ("impl-or-trait item") between traits/implementations and
methods. This new abstraction is encoded in the metadata and used
throughout the compiler where appropriate.

There are no functional changes; this is purely a refactoring.
2014-08-14 11:40:22 -07:00
Vadim Chugunov
98332b1a06 Replace all references to "Win32" with "Windows".
For historical reasons, "Win32" has been used in Rust codebase to mean "Windows OS in general".
This is confusing, especially now, that Rust supports Win64 builds.

[breaking-change]
2014-08-12 00:10:26 -07:00
Niko Matsakis
fcab98038c Temporary bootstrapping hack: introduce syntax for r egion bounds like 'b:'a,
meaning `'b outlives 'a`. Syntax currently does nothing but is needed for full
fix to #5763. To use this syntax, the issue_5763_bootstrap feature guard is
required.
2014-08-07 07:23:59 -04:00
Alex Crichton
1ae1461fbf rustc: Link entire archives of native libraries
As discovered in #15460, a particular #[link(kind = "static", ...)] line is not
actually guaranteed to link the library at all. The reason for this is that if
the external library doesn't have any referenced symbols in the object generated
by rustc, the entire library is dropped by the linker.

For dynamic native libraries, this is solved by passing -lfoo for all downstream
compilations unconditionally. For static libraries in rlibs this is solved
because the entire archive is bundled in the rlib. The only situation in which
this was a problem was when a static native library was linked to a rust dynamic
library.

This commit brings the behavior of dylibs in line with rlibs by passing the
--whole-archive flag to the linker when linking native libraries. On OSX, this
uses the -force_load flag. This flag ensures that the entire archive is
considered candidate for being linked into the final dynamic library.

This is a breaking change because if any static library is included twice in the
same compilation unit then the linker will start emitting errors about duplicate
definitions now. The fix for this would involve only statically linking to a
library once.

Closes #15460
[breaking-change]
2014-08-04 11:02:26 -07:00
Palmer Cox
fd69365ead Rewrite read_u32v_be() and write_u32_be() to make sure that all memory access is properly aligned 2014-08-02 01:21:02 -04:00
bors
9826e801be auto merge of #16073 : mneumann/rust/dragonfly2, r=alexcrichton
Not included are two required patches:

* LLVM: segmented stack support for DragonFly [1]

* jemalloc: simple configure patches

[1]: http://reviews.llvm.org/D4705
2014-07-31 14:41:34 +00:00
Stuart Pernsteiner
4d8de63fb3 speed up static linking by combining ar invocations 2014-07-29 13:54:40 -07:00
Michael Neumann
2e2f53fad2 Port Rust to DragonFlyBSD
Not included are two required patches:

* LLVM: segmented stack support for DragonFly [1]

* jemalloc: simple configure patches

[1]: http://reviews.llvm.org/D4705
2014-07-29 16:44:39 +02:00
Patrick Walton
caa564bea3 librustc: Stop desugaring for expressions and translate them directly.
This makes edge cases in which the `Iterator` trait was not in scope
and/or `Option` or its variants were not in scope work properly.

This breaks code that looks like:

    struct MyStruct { ... }

    impl MyStruct {
        fn next(&mut self) -> Option<int> { ... }
    }

    for x in MyStruct { ... } { ... }

Change ad-hoc `next` methods like the above to implementations of the
`Iterator` trait. For example:

    impl Iterator<int> for MyStruct {
        fn next(&mut self) -> Option<int> { ... }
    }

Closes #15392.

[breaking-change]
2014-07-24 18:58:12 -07:00
Alex Crichton
707cf47ac8 Register new snapshots 2014-07-19 20:38:00 -07:00
Patrick Walton
02adaca4dc librustc: Implement unboxed closures with mutable receivers 2014-07-18 09:01:37 -07:00
Brian Anderson
a008fc84aa Fix rebase fallout. Sorry. 2014-07-14 12:27:56 -07:00
Brian Anderson
c199790077 rustc: Move util::sha2 to rustc_back 2014-07-14 12:27:08 -07:00
Brian Anderson
46266bd606 rustc: Move util::fs to rustc_back 2014-07-14 12:27:07 -07:00
Brian Anderson
be018645d8 rustc_back: Update crate docs
Indicate that anything that can be extracted here should and that things with
syntax deps should be split out someday.
2014-07-14 12:27:07 -07:00
Brian Anderson
504d4599e2 rustc: Move archive to rustc_back 2014-07-14 12:27:07 -07:00
Brian Anderson
930abc1567 Extract rpath to rustc_back::rpath 2014-07-14 12:27:07 -07:00
Brian Anderson
cf360f328a Extract librustc_back from librustc 2014-07-14 12:27:07 -07:00