summary refs log tree commit diff
path: root/src/librustc/metadata/creader.rs
AgeCommit message (Collapse)AuthorLines
2015-04-29rollup merge of #24711: alexcrichton/fs2.1Alex Crichton-3/+4
This commit is an implementation of [RFC 1044][rfc] which adds additional surface area to the `std::fs` module. All new APIs are `#[unstable]` behind assorted feature names for each one. [rfc]: https://github.com/rust-lang/rfcs/pull/1044 The new APIs added are: * `fs::canonicalize` - bindings to `realpath` on unix and `GetFinalPathNameByHandle` on windows. * `fs::symlink_metadata` - similar to `lstat` on unix * `fs::FileType` and accessor methods as `is_{file,dir,symlink}` * `fs::Metadata::file_type` - accessor for the raw file type * `fs::DirEntry::metadata` - acquisition of metadata which is free on Windows but requires a syscall on unix. * `fs::DirEntry::file_type` - access the file type which may not require a syscall on most platforms. * `fs::DirEntry::file_name` - access just the file name without leading components. * `fs::PathExt::symlink_metadata` - convenience method for the top-level function. * `fs::PathExt::canonicalize` - convenience method for the top-level function. * `fs::PathExt::read_link` - convenience method for the top-level function. * `fs::PathExt::read_dir` - convenience method for the top-level function. * `std::os::raw` - type definitions for raw OS/C types available on all platforms. * `std::os::$platform` - new modules have been added for all currently supported platforms (e.g. those more specific than just `unix`). * `std::os::$platform::raw` - platform-specific type definitions. These modules are populated with the bare essentials necessary for lowing I/O types into their raw representations, and currently largely consist of the `stat` definition for unix platforms. This commit also deprecates `Metadata::{modified, accessed}` in favor of inspecting the raw representations via the lowering methods of `Metadata`. Closes https://github.com/rust-lang/rust/issues/24796
2015-04-29Fix zero-normalization of the pos of a `MultiByteChar`.Felix S. Klock II-1/+1
Fix #24687
2015-04-27std: Expand the area of std::fsAlex Crichton-3/+4
This commit is an implementation of [RFC 1044][rfc] which adds additional surface area to the `std::fs` module. All new APIs are `#[unstable]` behind assorted feature names for each one. [rfc]: https://github.com/rust-lang/rfcs/pull/1044 The new APIs added are: * `fs::canonicalize` - bindings to `realpath` on unix and `GetFinalPathNameByHandle` on windows. * `fs::symlink_metadata` - similar to `lstat` on unix * `fs::FileType` and accessor methods as `is_{file,dir,symlink}` * `fs::Metadata::file_type` - accessor for the raw file type * `fs::DirEntry::metadata` - acquisition of metadata which is free on Windows but requires a syscall on unix. * `fs::DirEntry::file_type` - access the file type which may not require a syscall on most platforms. * `fs::DirEntry::file_name` - access just the file name without leading components. * `fs::PathExt::symlink_metadata` - convenience method for the top-level function. * `fs::PathExt::canonicalize` - convenience method for the top-level function. * `fs::PathExt::read_link` - convenience method for the top-level function. * `fs::PathExt::read_dir` - convenience method for the top-level function. * `std::os::raw` - type definitions for raw OS/C types available on all platforms. * `std::os::$platform` - new modules have been added for all currently supported platforms (e.g. those more specific than just `unix`). * `std::os::$platform::raw` - platform-specific type definitions. These modules are populated with the bare essentials necessary for lowing I/O types into their raw representations, and currently largely consist of the `stat` definition for unix platforms. This commit also deprecates `Metadata::{modified, accessed}` in favor of inspecting the raw representations via the lowering methods of `Metadata`.
2015-04-14Positive case of `len()` -> `is_empty()`Tamir Duberstein-1/+1
`s/(?<!\{ self)(?<=\.)len\(\) == 0/is_empty()/g`
2015-04-05Work towards a non-panicing parser (libsyntax)Phil Dawes-1/+4
- Functions in parser.rs return PResult<> rather than panicing - Other functions in libsyntax call panic! explicitly for now if they rely on panicing behaviour. - 'panictry!' macro added as scaffolding while converting panicing functions. (This does the same as 'unwrap()' but is easier to grep for and turn into try!()) - Leaves panicing wrappers for the following functions so that the quote_* macros behave the same: - parse_expr, parse_item, parse_pat, parse_arm, parse_ty, parse_stmt
2015-03-27rustc: Remove support for hyphens in crate namesAlex Crichton-15/+5
This commit removes parser support for `extern crate "foo" as bar` as the renamed crate is now required to be an identifier. Additionally this commit enables hard errors on crate names that contain hyphens in them, they must now solely contain alphanumeric characters or underscores. If the crate name is inferred from the file name, however, the file name `foo-bar.rs` will have the crate name inferred as `foo_bar`. If a binary is being emitted it will have the name `foo-bar` and a library will have the name `libfoo_bar.rlib`. This commit is a breaking change for a number of reasons: * Old syntax is being removed. This was previously only issuing warnings. * The output for the compiler when input is received on stdin is now `rust_out` instead of `rust-out`. * The crate name for a crate in the file `foo-bar.rs` is now `foo_bar` which can affect infrastructure such as logging. [breaking-change]
2015-03-24rustc: Add support for `extern crate foo as bar`Alex Crichton-12/+20
The compiler will now issue a warning for crates that have syntax of the form `extern crate "foo" as bar`, but it will still continue to accept this syntax. Additionally, the string `foo-bar` will match the crate name `foo_bar` to assist in the transition period as well. This patch will land hopefully in tandem with a Cargo patch that will start translating all crate names to have underscores instead of hyphens. cc #23533
2015-03-09remove uses of as_slice where deref coercions can be usedRicho Healey-1/+1
2015-03-06Add #[allow_internal_unstable] to track stability for macros better.Huon Wilson-0/+1
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-04std: Deprecate std::old_io::fsAlex Crichton-3/+5
This commit deprecates the majority of std::old_io::fs in favor of std::fs and its new functionality. Some functions remain non-deprecated but are now behind a feature gate called `old_fs`. These functions will be deprecated once suitable replacements have been implemented. The compiler has been migrated to new `std::fs` and `std::path` APIs where appropriate as part of this change.
2015-03-04Encode codemap and span information in crate metadata.Michael Woerister-3/+133
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-23Rollup merge of #22664 - lfairy:just-say-no, r=alexcrichtonManish Goregaokar-0/+2
Leading hyphens already don't work (#22661), so no code should break from this change. Closes #22661.
2015-02-22Disallow crate names with leading hyphensChris Wong-1/+3
Leading hyphens already don't work (#22661), so no code should break from this change. Closes #22661.
2015-02-20Remove remaining uses of `[]`. This time I tried to use deref coercions ↵Niko Matsakis-11/+11
where possible.
2015-02-18Replace all uses of `&foo[]` with `&foo[..]` en masse.Niko Matsakis-6/+6
2015-02-12creader: Clean up macro/plugin APIKeegan McAllister-47/+29
Step towards #22198.
2015-02-11rustc: Do not link to pluginsAlex Crichton-1/+1
This flag seems to have erroneously been set to `true`.
2015-02-09Use a crate attribute to load pluginsKeegan McAllister-4/+4
#[plugin] #[no_link] extern crate bleh; becomes a crate attribute #![plugin(bleh)] The feature gate is still required. It's almost never correct to link a plugin into the resulting library / executable, because it will bring all of libsyntax and librustc with it. However if you really want this behavior, you can get it with a separate `extern crate` item in addition to the `plugin` attribute. Fixes #21043. Fixes #20769. [breaking-change]
2015-02-07Auto merge of #21978 - Potpourri:error-extern-crate-staticlib, r=alexcrichtonbors-1/+3
Add special error for this case and help message `please recompile this crate using --crate-type lib`, also list found candidates. See issue #14416 r? @alexcrichton
2015-02-06Update to last version, remove "[]" as much as possibleGuillaumeGomez-2/+2
2015-02-06librustc has been updatedGuillaumeGomez-6/+6
2015-02-06Improve error message, when found staticlib instead cratePotpourri-1/+3
2015-02-04remove all kind annotations from closuresJorge Aparicio-1/+1
2015-02-02rollup merge of #21830: japaric/for-cleanupAlex Crichton-3/+3
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-3/+3
2015-01-30rustc: Use --extern to always overrideAlex Crichton-0/+1
Previously if --extern was specified it would not override crates in the standard distribution, leading to issues like #21771. This commit alters the behavior such that if --extern is passed then it will always override any other choice of crates and no previous match will be used (unless it is the same path as --extern). Closes #21771
2015-01-21rustc: fix fallout of merging ast::ViewItem into ast::Item.Eduard Burtescu-31/+25
2015-01-16rustc: Fix a leak in dependency= pathsAlex Crichton-26/+38
With the addition of separate search paths to the compiler, it was intended that applications such as Cargo could require a `--extern` flag per `extern crate` directive in the source. The system can currently be subverted, however, due to the `existing_match()` logic in the crate loader. When loading crates we first attempt to match an `extern crate` directive against all previously loaded crates to avoid reading metadata twice. This "hit the cache if possible" step was erroneously leaking crates across the search path boundaries, however. For example: extern crate b; extern crate a; If `b` depends on `a`, then it will load crate `a` when the `extern crate b` directive is being processed. When the compiler reaches `extern crate a` it will use the previously loaded version no matter what. If the compiler was not invoked with `-L crate=path/to/a`, it will still succeed. This behavior is allowing `extern crate` declarations in Cargo without a corresponding declaration in the manifest of a dependency, which is considered a bug. This commit fixes this problem by keeping track of the origin search path for a crate. Crates loaded from the dependency search path are not candidates for crates which are loaded from the crate search path. As a result of this fix, this is a likely a breaking change for a number of Cargo packages. If the compiler starts informing that a crate can no longer be found, it likely means that the dependency was forgotten in your Cargo.toml. [breaking-change]
2015-01-09Make the metadata loader use the appropriate Target structureJohn Kåre Alsaker-0/+3
Fixes #19907
2015-01-08Add test for -Z extra-pluginsManish Goregaokar-2/+2
2015-01-08libsyntax: add COMMAND_LINE_SP and use it for spans generated from the ↵Manish Goregaokar-2/+2
command line
2015-01-08librustc_driver: Add support for loading plugins via command line (fixes #15446)Manish Goregaokar-1/+1
2015-01-08librustc::plugin : make PluginLoader usable for loading argument-specified ↵Manish Goregaokar-0/+1
plugins
2015-01-08librustc::metadata : Allow passing a string to read_plugin_metadataManish Goregaokar-7/+24
2015-01-07use slicing sugarJorge Aparicio-20/+20
2015-01-06More test fixesAlex Crichton-1/+1
2015-01-07falloutNick Cameron-4/+4
2015-01-07Replace full slice notation with index callsNick Cameron-16/+18
2015-01-06rustc: Turn off multiple versions of crate warningAlex Crichton-25/+0
This warning has been around in the compiler for quite some time now, but the real place for a warning like this, if it should exist, is in Cargo, not in the compiler itself. It's a first-class feature of Cargo that multiple versions of a crate can be compiled into the same executable, and we shouldn't be warning about our first-class features.
2015-01-05Allow selective macro importKeegan McAllister-1/+4
2015-01-05Move #[macro_reexport] to extern crateKeegan McAllister-0/+1
2015-01-05Replace #[phase] with #[plugin] / #[macro_use] / #[no_link]Keegan McAllister-6/+1
2015-01-05creader: Load parts of plugin metadata on demandKeegan McAllister-50/+98
2015-01-05Reformat metadata for exported macrosKeegan McAllister-4/+36
Instead of copy-pasting the whole macro_rules! item from the original .rs file, we serialize a separate name, attributes list, and body, the latter as pretty-printed TTs. The compilation of macro_rules! macros is decoupled somewhat from the expansion of macros in item position. This filters out comments, and facilitates selective imports.
2015-01-05creader: Use a single structKeegan McAllister-53/+41
2015-01-05creader: Convert free functions to Env methodsKeegan McAllister-264/+267
2015-01-04[breaking change] Update entry API as part of RFC 509.Ben Foppa-2/+2
2014-12-31rustc: unbox closures used in let bindingsJorge Aparicio-1/+1
2014-12-23rustc: Add knowledge of separate lookup pathsAlex Crichton-8/+13
This commit adds support for the compiler to distinguish between different forms of lookup paths in the compiler itself. Issue #19767 has some background on this topic, as well as some sample bugs which can occur if these lookup paths are not separated. This commits extends the existing command line flag `-L` with the same trailing syntax as the `-l` flag. Each argument to `-L` can now have a trailing `:all`, `:native`, `:crate`, or `:dependency`. This suffix indicates what form of lookup path the compiler should add the argument to. The `dependency` lookup path is used when looking up crate dependencies, the `crate` lookup path is used when looking for immediate dependencies (`extern crate` statements), and the `native` lookup path is used for probing for native libraries to insert into rlibs. Paths with `all` are used for all of these purposes (the default). The default compiler lookup path (the rustlib libdir) is by default added to all of these paths. Additionally, the `RUST_PATH` lookup path is added to all of these paths. Closes #19767
2014-12-21Fallout of std::str stabilizationAlex Crichton-20/+20