about summary refs log tree commit diff
path: root/src/libsyntax/codemap.rs
AgeCommit message (Collapse)AuthorLines
2015-04-21syntax: Change ExpnId::{from,to}_llvm_cookie to {from,to}_u32Erick Tryzelaar-6/+4
2015-04-21syntax: Replace Vec::map_in_place with stable mut iteratorErick Tryzelaar-9/+11
2015-04-21syntax: Replace String::from_str with the stable String::fromErick Tryzelaar-2/+2
2015-04-21Model lexer: Fix remaining issuesPiotr Czarnecki-2/+0
2015-04-14Negative case of `len()` -> `is_empty()`Tamir Duberstein-3/+3
`s/([^\(\s]+\.)len\(\) [(?:!=)>] 0/!$1is_empty()/g`
2015-04-14Positive case of `len()` -> `is_empty()`Tamir Duberstein-1/+1
`s/(?<!\{ self)(?<=\.)len\(\) == 0/is_empty()/g`
2015-04-11Suppress the macro backtrace for `fileline_note` and `fileline_help`.Ryan Prichard-1/+1
2015-04-10Modify the codemap code to use more slices and to information aboutNiko Matsakis-13/+92
columns within a line, not just the line numbers. Also try to clarify and use the term `line_index` when 0-based.
2015-04-09Debug impls for a few things in syntax::codemapNick Cameron-0/+12
2015-04-01rollup merge of #23860: nikomatsakis/copy-requires-cloneAlex Crichton-2/+2
Conflicts: src/test/compile-fail/coherence-impls-copy.rs
2015-04-01fallout when bootstrapping `rustc`.Felix S. Klock II-2/+2
2015-04-01Fallout in libsyntaxNiko Matsakis-2/+2
2015-03-25Add trivial cast lints.Nick Cameron-3/+3
This permits all coercions to be performed in casts, but adds lints to warn in those cases. Part of this patch moves cast checking to a later stage of type checking. We acquire obligations to check casts as part of type checking where we previously checked them. Once we have type checked a function or module, then we check any cast obligations which have been acquired. That means we have more type information available to check casts (this was crucial to making coercions work properly in place of some casts), but it means that casts cannot feed input into type inference. [breaking change] * Adds two new lints for trivial casts and trivial numeric casts, these are warn by default, but can cause errors if you build with warnings as errors. Previously, trivial numeric casts and casts to trait objects were allowed. * The unused casts lint has gone. * Interactions between casting and type inference have changed in subtle ways. Two ways this might manifest are: - You may need to 'direct' casts more with extra type information, for example, in some cases where `foo as _ as T` succeeded, you may now need to specify the type for `_` - Casts do not influence inference of integer types. E.g., the following used to type check: ``` let x = 42; let y = &x as *const u32; ``` Because the cast would inform inference that `x` must have type `u32`. This no longer applies and the compiler will fallback to `i32` for `x` and thus there will be a type error in the cast. The solution is to add more type information: ``` let x: u32 = 42; let y = &x as *const u32; ```
2015-03-23Add generic conversion traitsAaron Turon-2/+1
This commit: * Introduces `std::convert`, providing an implementation of RFC 529. * Deprecates the `AsPath`, `AsOsStr`, and `IntoBytes` traits, all in favor of the corresponding generic conversion traits. Consequently, various IO APIs now take `AsRef<Path>` rather than `AsPath`, and so on. Since the types provided by `std` implement both traits, this should cause relatively little breakage. * Deprecates many `from_foo` constructors in favor of `from`. * Changes `PathBuf::new` to take no argument (creating an empty buffer, as per convention). The previous behavior is now available as `PathBuf::from`. * De-stabilizes `IntoCow`. It's not clear whether we need this separate trait. Closes #22751 Closes #14433 [breaking-change]
2015-03-10Fix unstable span checksSteven Fackler-1/+1
2015-03-09Rename #[should_fail] to #[should_panic]Steven Fackler-1/+1
2015-03-06Add #[allow_internal_unstable] to track stability for macros better.Huon Wilson-32/+38
Unstable items used in a macro expansion will now always trigger stability warnings, *unless* the unstable items are directly inside a macro marked with `#[allow_internal_unstable]`. IOW, the compiler warns unless the span of the unstable item is a subspan of the definition of a macro marked with that attribute. E.g. #[allow_internal_unstable] macro_rules! foo { ($e: expr) => {{ $e; unstable(); // no warning only_called_by_foo!(); }} } macro_rules! only_called_by_foo { () => { unstable() } // warning } foo!(unstable()) // warning The unstable inside `foo` is fine, due to the attribute. But the `unstable` inside `only_called_by_foo` is not, since that macro doesn't have the attribute, and the `unstable` passed into `foo` is also not fine since it isn't contained in the macro itself (that is, even though it is only used directly in the macro). In the process this makes the stability tracking much more precise, e.g. previously `println!("{}", unstable())` got no warning, but now it does. As such, this is a bug fix that may cause [breaking-change]s. The attribute is definitely feature gated, since it explicitly allows side-stepping the feature gating system.
2015-03-04Encode codemap and span information in crate metadata.Michael Woerister-39/+278
This allows to create proper debuginfo line information for items inlined from other crates (e.g. instantiations of generics). Only the codemap's 'metadata' is stored in a crate's metadata. That is, just filename, line-beginnings, etc. but not the actual source code itself. We are thus missing the opportunity of making Rust the first "open-source-only" programming language out there. Pity.
2015-02-18Replace all uses of `&foo[]` with `&foo[..]` en masse.Niko Matsakis-1/+1
2015-02-05make codemap more robust in face of ill-formed spans.Felix S. Klock II-8/+46
This can be considered partial work on #8256. The main observable change: macro expansion sometimes results in spans where `lo > hi`; so for now, when we have such a span, do not attempt to return a snippet result. (Longer term, we might think about whether we could still present a snippet for the cases where this arises, e.g. perhaps by showing the whole macro as the snippet, assuming that is the sole cause of such spans; or by somehow looking up the closest AST node that holds both `lo` and `hi`, and showing that.) As a drive-by, revised the API to return a `Result` rather than an `Option`, with better information-packed error value that should help us (and maybe also our users) identify the causes of such problems in the future. Ideally the call-sites that really want an actual snippet would be updated to catch the newly added `Err` case and print something meaningful about it, but that is not part of this PR.
2015-02-02rollup merge of #21830: japaric/for-cleanupAlex Crichton-2/+2
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`for x in xs.iter()` -> `for x in &xs`Jorge Aparicio-2/+2
2015-02-02Omit integer suffix when unnecessaryAlfie John-9/+9
See PR # 21378 for context
2015-01-29s/Show/Debug/gJorge Aparicio-8/+8
2015-01-29`for x in range(a, b)` -> `for x in a..b`Jorge Aparicio-1/+1
sed -i 's/in range(\([^,]*\), *\([^()]*\))/in \1\.\.\2/g' **/*.rs
2015-01-24syntax: Don't put quotes around filenames in codemapAlex Crichton-3/+4
This ends up propagating all the way out to the output of dep-info which then makes Cargo think that files are not existent (it thinks the files have quotes in their name) when they in fact do.
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]