about summary refs log tree commit diff
path: root/src/libsyntax/codemap.rs
AgeCommit message (Collapse)AuthorLines
2015-01-18libsyntax: 0u -> 0us, 0i -> 0isPaul Collier-9/+9
2015-01-17libsyntax: rename functions from uint to usizePaul Collier-22/+22
2015-01-17libsyntax: uint types to usizePaul Collier-17/+17
2015-01-12cleanup: `&foo[0..a]` -> `&foo[..a]`Jorge Aparicio-1/+1
2015-01-08libsyntax: add COMMAND_LINE_SP and use it for spans generated from the ↵Manish Goregaokar-0/+7
command line
2015-01-07rollup merge of #20721: japaric/snapAlex Crichton-6/+5
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-1/+6
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-6/+5
2015-01-06Register new snapshotsAlex Crichton-17/+0
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-3/+3
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-3/+3
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-6/+6
2015-01-04serialize: Use assoc types + less old_orphan_checkAlex Crichton-0/+17
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-03sed -i -s 's/#\[deriving(/#\[derive(/g' **/*.rsJorge Aparicio-10/+10
2015-01-03use assoc types in binop traitsJorge Aparicio-4/+12
2015-01-02std: Stabilize the prelude moduleAlex Crichton-7/+12
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
2015-01-01Feature gate macro argumentsCorey Richardson-0/+32
Uses the same approach as https://github.com/rust-lang/rust/pull/17286 (and subsequent changes making it more correct), where the visitor will skip any pieces of the AST that are from "foreign code", where the spans don't line up, indicating that that piece of code is due to a macro expansion. If this breaks your code, read the error message to determine which feature gate you should add to your crate, and bask in the knowledge that your code won't mysteriously break should you try to use the 1.0 release. Closes #18102 [breaking-change]
2014-12-22rollup merge of #20033: alexcrichton/deprecate-serialiseAlex Crichton-2/+2
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]
2014-12-22serialize: Fully deprecate the libraryAlex Crichton-2/+2
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]
2014-12-21Fallout of std::str stabilizationAlex Crichton-6/+6
2014-12-21rollup merge of #19972: alexcrichton/snapshotsAlex Crichton-36/+0
Conflicts: src/libcollections/string.rs src/libcollections/vec.rs src/snapshots.txt
2014-12-19Register new snapshotsAlex Crichton-36/+0
This does not yet start the movement to rustc-serialize. That detail is left to a future PR.
2014-12-19libsyntax: use `#[deriving(Copy)]`Jorge Aparicio-20/+7
2014-12-18librustc: Always parse `macro!()`/`macro![]` as expressions if notPatrick Walton-1/+1
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-13libsyntax: convert `BytePos`/`CharPos` binops to by valueJorge Aparicio-0/+36
2014-12-13libsyntax: use unboxed closuresJorge Aparicio-1/+3
2014-12-11Register new snapshotsAlex Crichton-1/+1
2014-12-08librustc: Make `Copy` opt-in.Niko Matsakis-0/+14
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-06libsyntax: remove unnecessary `to_string()` callsJorge Aparicio-6/+6
2014-12-06libsyntax: remove unnecessary `as_slice()` callsJorge Aparicio-9/+9
2014-11-26rollup merge of #19329: steveklabnik/doc_style_cleanup2Alex Crichton-12/+6
2014-11-26/*! -> //!Steve Klabnik-12/+6
Sister pull request of https://github.com/rust-lang/rust/pull/19288, but for the other style of block doc comment.
2014-11-25/** -> ///Steve Klabnik-6/+4
This is considered good convention.
2014-11-20Fix an ICE on diagnostics originating in external macrosJakub Bukaj-10/+12
2014-11-17Switch to purely namespaced enumsSteven Fackler-0/+2
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-10-29Rename fail! to panic!Steve Klabnik-4/+4
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-19Remove a large amount of deprecated functionalityAlex Crichton-18/+21
Spring cleaning is here! In the Fall! This commit removes quite a large amount of deprecated functionality from the standard libraries. I tried to ensure that only old deprecated functionality was removed. This is removing lots and lots of deprecated features, so this is a breaking change. Please consult the deprecation messages of the deleted code to see how to migrate code forward if it still needs migration. [breaking-change]
2014-10-09syntax: Convert statics to constantsAlex Crichton-2/+2
2014-10-04Register new snapshotsBjörn Steinbrink-6/+2
2014-09-30librustc: Fix up mutability in method autoderefs if incorrect, andPatrick Walton-0/+5
prefer `Deref` over `DerefMut` in all other circumstances. Closes #12825.
2014-09-28Keep ExpnId abstract by providing conversionsKeegan McAllister-2/+14
2014-09-27Translate inline assembly errors back to source locationsKeegan McAllister-1/+1
Fixes #17552.
2014-09-18Fix fallout in tests from removing the use of Gc in ExpnInfo.Eduard Burtescu-3/+3
2014-09-18syntax: use an index in CodeMap instead of Gc for ExpnInfo.Eduard Burtescu-9/+30
2014-07-21ignore-lexer-test to broken files and remove some tray hyphensCorey Richardson-0/+2
I blame @ChrisMorgan for the hyphens.
2014-07-09syntax: don't parse numeric literals in the lexerCorey Richardson-1/+1
This removes a bunch of token types. Tokens now store the original, unaltered numeric literal (that is still checked for correctness), which is parsed into an actual number later, as needed, when creating the AST. This can change how syntax extensions work, but otherwise poses no visible changes. [breaking-change]
2014-07-09codemap: be less annoying in debug loggingCorey Richardson-5/+4
2014-07-09syntax: doc comments all the thingsCorey Richardson-11/+11
2014-07-08std: Rename the `ToStr` trait to `ToString`, and `to_str` to `to_string`.Richo Healey-2/+2
[breaking-change]
2014-06-13Dump results of analysis phase as CSVNick Cameron-35/+35
Adds the option -Zsave-analysis which will dump the results of syntax and type checking into CSV files. These can be interpreted by tools such as DXR to provide semantic information about Rust programs for code search, cross-reference, etc. Authored by Nick Cameron and Peter Elmers (@pelmers; including enums, type parameters/generics).
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-23 11:37:10 +0000