1. 08 1月, 2015 1 次提交
    • B
      Preliminary feature staging · c27133e2
      Brian Anderson 提交于
      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
      c27133e2
  2. 07 1月, 2015 5 次提交
    • A
      More test fixes · a6400082
      Alex Crichton 提交于
      a6400082
    • A
      Register new snapshots · e2f97f51
      Alex Crichton 提交于
      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
      e2f97f51
    • A
      Fallout from stabilization · caca9b2e
      Aaron Turon 提交于
      caca9b2e
    • S
      core: split into fmt::Show and fmt::String · 44440e5c
      Sean McArthur 提交于
      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]
      44440e5c
    • N
      Replace full slice notation with index calls · f7ff37e4
      Nick Cameron 提交于
      f7ff37e4
  3. 06 1月, 2015 3 次提交
  4. 04 1月, 2015 4 次提交
  5. 03 1月, 2015 1 次提交
    • A
      std: Stabilize the prelude module · 56290a00
      Alex Crichton 提交于
      This commit is an implementation of [RFC 503][rfc] which is a stabilization
      story for the prelude. Most of the RFC was directly applied, removing reexports.
      Some reexports are kept around, however:
      
      * `range` remains until range syntax has landed to reduce churn.
      * `Path` and `GenericPath` remain until path reform lands. This is done to
        prevent many imports of `GenericPath` which will soon be removed.
      * All `io` traits remain until I/O reform lands so imports can be rewritten all
        at once to `std::io::prelude::*`.
      
      This is a breaking change because many prelude reexports have been removed, and
      the RFC can be consulted for the exact list of removed reexports, as well as to
      find the locations of where to import them.
      
      [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0503-prelude-stabilization.md
      [breaking-change]
      
      Closes #20068
      56290a00
  6. 02 1月, 2015 3 次提交
    • N
      Fix orphan checking (cc #19470). (This is not a complete fix of #19470 because... · c61a0092
      Niko Matsakis 提交于
      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.
      c61a0092
    • A
      std: Enforce Unicode in fmt::Writer · e423fcf0
      Alex Crichton 提交于
      This commit is an implementation of [RFC 526][rfc] which is a change to alter
      the definition of the old `fmt::FormatWriter`. The new trait, renamed to
      `Writer`, now only exposes one method `write_str` in order to guarantee that all
      implementations of the formatting traits can only produce valid Unicode.
      
      [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0526-fmt-text-writer.md
      
      One of the primary improvements of this patch is the performance of the
      `.to_string()` method by avoiding an almost-always redundant UTF-8 check. This
      is a breaking change due to the renaming of the trait as well as the loss of the
      `write` method, but migration paths should be relatively easy:
      
      * All usage of `write` should move to `write_str`. If truly binary data was
        being written in an implementation of `Show`, then it will need to use a
        different trait or an altogether different code path.
      
      * All usage of `write!` should continue to work as-is with no modifications.
      
      * All usage of `Show` where implementations just delegate to another should
        continue to work as-is.
      
      [breaking-change]
      
      Closes #20352
      e423fcf0
    • N
      Fallout - change array syntax to use `;` · 7e2b9ea2
      Nick Cameron 提交于
      7e2b9ea2
  7. 31 12月, 2014 1 次提交
  8. 30 12月, 2014 2 次提交
    • A
      std: Second pass stabilization for `comm` · bc83a009
      Alex Crichton 提交于
      This commit is a second pass stabilization for the `std::comm` module,
      performing the following actions:
      
      * The entire `std::comm` module was moved under `std::sync::mpsc`. This movement
        reflects that channels are just yet another synchronization primitive, and
        they don't necessarily deserve a special place outside of the other
        concurrency primitives that the standard library offers.
      * The `send` and `recv` methods have all been removed.
      * The `send_opt` and `recv_opt` methods have been renamed to `send` and `recv`.
        This means that all send/receive operations return a `Result` now indicating
        whether the operation was successful or not.
      * The error type of `send` is now a `SendError` to implement a custom error
        message and allow for `unwrap()`. The error type contains an `into_inner`
        method to extract the value.
      * The error type of `recv` is now `RecvError` for the same reasons as `send`.
      * The `TryRecvError` and `TrySendError` types have had public reexports removed
        of their variants and the variant names have been tweaked with enum
        namespacing rules.
      * The `Messages` iterator is renamed to `Iter`
      
      This functionality is now all `#[stable]`:
      
      * `Sender`
      * `SyncSender`
      * `Receiver`
      * `std::sync::mpsc`
      * `channel`
      * `sync_channel`
      * `Iter`
      * `Sender::send`
      * `Sender::clone`
      * `SyncSender::send`
      * `SyncSender::try_send`
      * `SyncSender::clone`
      * `Receiver::recv`
      * `Receiver::try_recv`
      * `Receiver::iter`
      * `SendError`
      * `RecvError`
      * `TrySendError::{mod, Full, Disconnected}`
      * `TryRecvError::{mod, Empty, Disconnected}`
      * `SendError::into_inner`
      * `TrySendError::into_inner`
      
      This is a breaking change due to the modification of where this module is
      located, as well as the changing of the semantics of `send` and `recv`. Most
      programs just need to rename imports of `std::comm` to `std::sync::mpsc` and
      add calls to `unwrap` after a send or a receive operation.
      
      [breaking-change]
      bc83a009
    • A
      std: Stabilize the prelude module · c32d03f4
      Alex Crichton 提交于
      This commit is an implementation of [RFC 503][rfc] which is a stabilization
      story for the prelude. Most of the RFC was directly applied, removing reexports.
      Some reexports are kept around, however:
      
      * `range` remains until range syntax has landed to reduce churn.
      * `Path` and `GenericPath` remain until path reform lands. This is done to
        prevent many imports of `GenericPath` which will soon be removed.
      * All `io` traits remain until I/O reform lands so imports can be rewritten all
        at once to `std::io::prelude::*`.
      
      This is a breaking change because many prelude reexports have been removed, and
      the RFC can be consulted for the exact list of removed reexports, as well as to
      find the locations of where to import them.
      
      [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0503-prelude-stabilization.md
      [breaking-change]
      
      Closes #20068
      c32d03f4
  9. 27 12月, 2014 2 次提交
  10. 22 12月, 2014 2 次提交
    • A
      serialize: Fully deprecate the library · a76a8027
      Alex Crichton 提交于
      This commit completes the deprecation story for the in-tree serialization
      library. The compiler will now emit a warning whenever it encounters
      `deriving(Encodable)` or `deriving(Decodable)`, and the library itself is now
      marked `#[unstable]` for when feature staging is enabled.
      
      All users of serialization can migrate to the `rustc-serialize` crate on
      crates.io which provides the exact same interface as the libserialize library
      in-tree. The new deriving modes are named `RustcEncodable` and `RustcDecodable`
      and require `extern crate "rustc-serialize" as rustc_serialize` at the crate
      root in order to expand correctly.
      
      To migrate all crates, add the following to your `Cargo.toml`:
      
          [dependencies]
          rustc-serialize = "0.1.1"
      
      And then add the following to your crate root:
      
          extern crate "rustc-serialize" as rustc_serialize;
      
      Finally, rename `Encodable` and `Decodable` deriving modes to `RustcEncodable`
      and `RustcDecodable`.
      
      [breaking-change]
      a76a8027
    • A
      Fallout of std::str stabilization · 082bfde4
      Alex Crichton 提交于
      082bfde4
  11. 19 12月, 2014 5 次提交
    • J
      libtest: use `#[deriving(Copy)]` · ce924377
      Jorge Aparicio 提交于
      ce924377
    • A
      Revise std::thread API to join by default · a27fbac8
      Aaron Turon 提交于
      This commit is part of a series that introduces a `std::thread` API to
      replace `std::task`.
      
      In the new API, `spawn` returns a `JoinGuard`, which by default will
      join the spawned thread when dropped. It can also be used to join
      explicitly at any time, returning the thread's result. Alternatively,
      the spawned thread can be explicitly detached (so no join takes place).
      
      As part of this change, Rust processes now terminate when the main
      thread exits, even if other detached threads are still running, moving
      Rust closer to standard threading models. This new behavior may break code
      that was relying on the previously implicit join-all.
      
      In addition to the above, the new thread API also offers some built-in
      support for building blocking abstractions in user space; see the module
      doc for details.
      
      Closes #18000
      
      [breaking-change]
      a27fbac8
    • A
      Fallout from new thread API · 43ae4b33
      Aaron Turon 提交于
      43ae4b33
    • A
      enumset fallout · 67d3823f
      Alexis Beingessner 提交于
      67d3823f
    • A
      s/Tree/BTree · 0bd4dc68
      Alexis Beingessner 提交于
      0bd4dc68
  12. 14 12月, 2014 2 次提交
  13. 09 12月, 2014 1 次提交
    • N
      librustc: Make `Copy` opt-in. · 096a2860
      Niko Matsakis 提交于
      This change makes the compiler no longer infer whether types (structures
      and enumerations) implement the `Copy` trait (and thus are implicitly
      copyable). Rather, you must implement `Copy` yourself via `impl Copy for
      MyType {}`.
      
      A new warning has been added, `missing_copy_implementations`, to warn
      you if a non-generic public type has been added that could have
      implemented `Copy` but didn't.
      
      For convenience, you may *temporarily* opt out of this behavior by using
      `#![feature(opt_out_copy)]`. Note though that this feature gate will never be
      accepted and will be removed by the time that 1.0 is released, so you should
      transition your code away from using it.
      
      This breaks code like:
      
          #[deriving(Show)]
          struct Point2D {
              x: int,
              y: int,
          }
      
          fn main() {
              let mypoint = Point2D {
                  x: 1,
                  y: 1,
              };
              let otherpoint = mypoint;
              println!("{}{}", mypoint, otherpoint);
          }
      
      Change this code to:
      
          #[deriving(Show)]
          struct Point2D {
              x: int,
              y: int,
          }
      
          impl Copy for Point2D {}
      
          fn main() {
              let mypoint = Point2D {
                  x: 1,
                  y: 1,
              };
              let otherpoint = mypoint;
              println!("{}{}", mypoint, otherpoint);
          }
      
      This is the backwards-incompatible part of #13231.
      
      Part of RFC #3.
      
      [breaking-change]
      096a2860
  14. 07 12月, 2014 5 次提交
  15. 06 12月, 2014 1 次提交
  16. 03 12月, 2014 1 次提交
  17. 27 11月, 2014 1 次提交