about summary refs log tree commit diff
path: root/src/librbml
AgeCommit message (Collapse)AuthorLines
2015-01-21rollup merge of #21258: aturon/stab-3-indexAlex Crichton-1/+1
Conflicts: src/libcore/ops.rs src/librustc_typeck/astconv.rs src/libstd/io/mem.rs src/libsyntax/parse/lexer/mod.rs
2015-01-21Fallout from stabilization.Aaron Turon-1/+1
2015-01-20std: Rename Show/String to Debug/DisplayAlex Crichton-0/+8
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-19lower FnMut to FnOnce since json-hack is no longer requiredOliver 'ker' Schneider-2/+2
Conflicts: src/libserialize/serialize.rs
2015-01-17Set allow(unstable) in crates that use unstable featuresBrian Anderson-0/+1
Lets them build with the -dev, -nightly, or snapshot compiler
2015-01-12cleanup: `&foo[0..a]` -> `&foo[..a]`Jorge Aparicio-1/+1
2015-01-08rollup merge of #20754: nikomatsakis/int-featureAlex Crichton-0/+1
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-08Remove warning from the libraries.Huon Wilson-0/+1
This adds the int_uint feature to *every* library, whether or not it needs it.
2015-01-08Improvements to feature stagingBrian Anderson-1/+1
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-07rollup merge of #20721: japaric/snapAlex Crichton-3/+3
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-07Preliminary feature stagingBrian Anderson-0/+1
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-07use slicing sugarJorge Aparicio-3/+3
2015-01-06Register new snapshotsAlex Crichton-471/+2
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-06rollup merge of #20481: seanmonstar/fmt-show-stringAlex Crichton-30/+30
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-06core: split into fmt::Show and fmt::StringSean McArthur-30/+30
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-07Replace full slice notation with index callsNick Cameron-3/+3
2015-01-05Replace #[phase] with #[plugin] / #[macro_use] / #[no_link]Keegan McAllister-1/+8
2015-01-04serialize: Use assoc types + less old_orphan_checkAlex Crichton-1/+464
This commit moves the libserialize crate (and will force the hand of the rustc-serialize crate) to not require the `old_orphan_check` feature gate as well as using associated types wherever possible. Concretely, the following changes were made: * The error type of `Encoder` and `Decoder` is now an associated type, meaning that these traits have no type parameters. * The `Encoder` and `Decoder` type parameters on the `Encodable` and `Decodable` traits have moved to the corresponding method of the trait. This movement alleviates the dependency on `old_orphan_check` but implies that implementations can no longer be specialized for the type of encoder/decoder being implemented. Due to the trait definitions changing, this is a: [breaking-change]
2015-01-03Remove deprecated functionalityAlex Crichton-9/+10
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-03sed -i -s 's/#\[deriving(/#\[derive(/g' **/*.rsJorge Aparicio-4/+4
2015-01-02Fallout - change array syntax to use `;`Nick Cameron-1/+1
2014-12-30Fallout from stabilizationAaron Turon-1/+2
2014-12-30Fallout from mut slicesNick Cameron-1/+1
2014-12-19librbml: use `#[deriving(Copy)]`Jorge Aparicio-8/+3
2014-12-18librustc: Always parse `macro!()`/`macro![]` as expressions if notPatrick Walton-2/+2
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-15serialize: Change some FnOnce bounds to FnMutAlex Crichton-6/+8
Relax some of the bounds on the decoder methods back to FnMut to help accomodate some more flavorful variants of decoders which may need to run the closure more than once when it, for example, attempts to find the first successful enum to decode. This a breaking change due to the bounds for the trait switching, and clients will need to update from `FnOnce` to `FnMut` as well as likely making the local function binding mutable in order to call the function. [breaking-change]
2014-12-13librbml: use unboxed closures in free functionsJorge Aparicio-7/+18
2014-12-13librbml: fix falloutJorge Aparicio-124/+133
2014-12-08librustc: Make `Copy` opt-in.Niko Matsakis-0/+6
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]
2014-12-05Utilize fewer reexportsCorey Farwell-2/+4
In regards to: https://github.com/rust-lang/rust/issues/19253#issuecomment-64836729 This commit: * Changes the #deriving code so that it generates code that utilizes fewer reexports (in particur Option::* and Result::*), which is necessary to remove those reexports in the future * Changes other areas of the codebase so that fewer reexports are utilized
2014-11-26Remove special casing for some meta attributesSteven Fackler-1/+0
Descriptions and licenses are handled by Cargo now, so there's no reason to keep these attributes around.
2014-11-20Rename remaining Failures to PanicSubhash Bhushan-1/+1
2014-11-17Switch to purely namespaced enumsSteven Fackler-1/+4
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-17Fix fallout from coercion removalNick Cameron-11/+11
2014-11-13Remove lots of numeric traits from the preludesBrendan Zabarauskas-2/+3
Num, NumCast, Unsigned, Float, Primitive and Int have been removed.
2014-11-01Tuple deserialization should not failDan Burkert-4/+6
2014-11-01libserialize: tuple-arity should be provided to `Decoder::read_tuple`Dan Burkert-4/+11
Currently `Decoder` implementations are not provided the tuple arity as a parameter to `read_tuple`. This forces all encoder/decoder combos to serialize the arity along with the elements. Tuple-arity is always known statically at the decode site, because it is part of the type of the tuple, so it could instead be provided as an argument to `read_tuple`, as it is to `read_struct`. The upside to this is that serialized tuples could become smaller in encoder/decoder implementations which choose not to serialize type (arity) information. For example, @TyOverby's [binary-encode](https://github.com/TyOverby/binary-encode) format is currently forced to serialize the tuple-arity along with every tuple, despite the information being statically known at the decode site. A downside to this change is that the tuple-arity of serialized tuples can no longer be automatically checked during deserialization. However, for formats which do serialize the tuple-arity, either explicitly (rbml) or implicitly (json), this check can be added to the `read_tuple` method. The signature of `Deserialize::read_tuple` and `Deserialize::read_tuple_struct` are changed, and thus binary backwards-compatibility is broken. This change does *not* force serialization formats to change, and thus does not break decoding values serialized prior to this change. [breaking-change]
2014-10-30rollup merge of #18398 : aturon/lint-conventions-2Alex Crichton-1/+1
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-29Rename 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-10-28Update code with new lint namesAaron Turon-1/+1
2014-10-09Use the same html_root_url for all docsBrian Anderson-1/+1
2014-10-09Revert "Update html_root_url for 0.12.0 release"Brian Anderson-1/+1
This reverts commit 2288f332301b9e22db2890df256322650a7f3445.
2014-10-07Update html_root_url for 0.12.0 releaseBrian Anderson-1/+1
2014-10-07Put slicing syntax behind a feature gate.Nick Cameron-1/+2
[breaking-change] If you are using slicing syntax you will need to add #![feature(slicing_syntax)] to your crate.
2014-10-07Use slice syntax instead of slice_to, etc.Nick Cameron-4/+4
2014-10-02Revert "Use slice syntax instead of slice_to, etc."Aaron Turon-4/+4
This reverts commit 40b9f5ded50ac4ce8c9323921ec556ad611af6b7.
2014-10-02Revert "Put slicing syntax behind a feature gate."Aaron Turon-2/+1
This reverts commit 95cfc35607ccf5f02f02de56a35a9ef50fa23a82.
2014-10-02Put slicing syntax behind a feature gate.Nick Cameron-1/+2
[breaking-change] If you are using slicing syntax you will need to add #![feature(slicing_syntax)] to your crate.
2014-10-02Use slice syntax instead of slice_to, etc.Nick Cameron-4/+4
2014-09-21Fix fallout from Vec stabilizationAlex Crichton-1/+1
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-04-25 13:57:35 +0000