summary refs log tree commit diff
path: root/src/librustc_metadata/creader.rs
AgeCommit message (Collapse)AuthorLines
2016-09-24Load macros from `#[macro_use]` extern crates in `resolve`.Jeffrey Seyfried-1/+1
2016-09-23Load extern crates in `resolve`.Jeffrey Seyfried-109/+74
2016-09-20rustc_metadata: replace RBML with a simple and type-safe scheme.Eduard Burtescu-172/+39
2016-09-20rustc_metadata: move all encoding/decoding helpers to methods.Eduard Burtescu-17/+18
2016-09-20rustc_metadata: use the shorthand encoding for predicates also.Eduard Burtescu-1/+0
2016-09-20rustc_metadata: group information into less tags.Eduard Burtescu-35/+30
2016-09-20rustc_metadata: move more RBML tags to auto-serialization.Eduard Burtescu-13/+1
2016-09-20rustc_metadata: go only through rustc_serialize in astencode.Eduard Burtescu-14/+16
2016-09-04Auto merge of #36203 - petrochenkov:uvsdot, r=nrcbors-8/+8
Replace `_, _` with `..` in patterns This is how https://github.com/rust-lang/rust/issues/33627 looks in action. Looks especially nice in leftmost/rightmost positions `(first, ..)`/`(.., last)`. I haven't touched libsyntax intentionally because the feature is still unstable.
2016-09-04Rollup merge of #36070 - gavinb:master, r=jonathandturnerManish Goregaokar-4/+6
Update error format for E0458, E0459 Fixes #35933, #35932 Part of #35233 r? @jonathandturner
2016-09-04Replace `_, _` with `..`Vadim Petrochenkov-8/+8
2016-09-02rustc: Implement custom derive (macros 1.1)Alex Crichton-56/+148
This commit is an implementation of [RFC 1681] which adds support to the compiler for first-class user-define custom `#[derive]` modes with a far more stable API than plugins have today. [RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md The main features added by this commit are: * A new `rustc-macro` crate-type. This crate type represents one which will provide custom `derive` implementations and perhaps eventually flower into the implementation of macros 2.0 as well. * A new `rustc_macro` crate in the standard distribution. This crate will provide the runtime interface between macro crates and the compiler. The API here is particularly conservative right now but has quite a bit of room to expand into any manner of APIs required by macro authors. * The ability to load new derive modes through the `#[macro_use]` annotations on other crates. All support added here is gated behind the `rustc_macro` feature gate, both for the library support (the `rustc_macro` crate) as well as the language features. There are a few minor differences from the implementation outlined in the RFC, such as the `rustc_macro` crate being available as a dylib and all symbols are `dlsym`'d directly instead of having a shim compiled. These should only affect the implementation, however, not the public interface. This commit also ended up touching a lot of code related to `#[derive]`, making a few notable changes: * Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't sure how to keep this behavior and *not* expose it to custom derive. * Derive attributes no longer have access to unstable features by default, they have to opt in on a granular level. * The `derive(Copy,Clone)` optimization is now done through another "obscure attribute" which is just intended to ferry along in the compiler that such an optimization is possible. The `derive(PartialEq,Eq)` optimization was also updated to do something similar. --- One part of this PR which needs to be improved before stabilizing are the errors and exact interfaces here. The error messages are relatively poor quality and there are surprising spects of this such as `#[derive(PartialEq, Eq, MyTrait)]` not working by default. The custom attributes added by the compiler end up becoming unstable again when going through a custom impl. Hopefully though this is enough to start allowing experimentation on crates.io! syntax-[breaking-change]
2016-08-29E0458 Update error format #35932Gavin Baker-2/+3
- Fixes #35932 - Part of #35233 r? @jonathandturner
2016-08-29E0459 Update error format #35933Gavin Baker-2/+3
- Fixes #35933 - Part of #35233 r? @jonathandturner
2016-08-25Refactor away `AttrMetaMethods`.Jeffrey Seyfried-1/+1
2016-08-25Refactor away `AttrNestedMetaItemMethods`.Jeffrey Seyfried-1/+1
2016-08-25Implement RFC#1559: allow all literals in attributes.Sergio Benitez-2/+1
2016-08-24Update E0445 and E0454 to new error formatMohit Agarwal-2/+4
Fixes #35922. Fixes #35930. Part of #35233. r? @GuillaumeGomez
2016-08-11Remove the 'cfg' field from session::config::Options.Michael Woerister-3/+7
The 'cfg' in the Options struct is only the commandline-specified subset of the crate configuration and it's almost always wrong to read that instead of the CrateConfig in HIR crate node.
2016-07-28Store `crate_disambiguator` as an `InternedString`Niko Matsakis-1/+1
We used to use `Name`, but the session outlives the tokenizer, which means that attempts to read this field after trans has complete otherwise panic. All reads want an `InternedString` anyhow.
2016-07-11Avoid passing around the thread-local interner in `librustc_metadata`.Jeffrey Seyfried-1/+0
2016-07-02make the metadata lock more robust and bump the metadata encoding versionAriel Ben-Yehuda-21/+2
check the metadata lock when loading rather than afterwards Fixes #33733 Fixes #33015
2016-06-28refactor rustc_metadata to use CamelCase names and IndexVecAriel Ben-Yehuda-42/+38
2016-06-26Rollup merge of #33943 - jseyfried:libsyntax_cleanup, r=nrcJeffrey Seyfried-2/+2
Miscellaneous low priority cleanup in `libsyntax`.
2016-06-23Move errors from libsyntax to its own crateJonathan Turner-6/+7
2016-06-16Add an abs_path member to FileMap, use it when writing debug info.Ted Mielczarek-0/+2
When items are inlined from extern crates, the filename in the debug info is taken from the FileMap that's serialized in the rlib metadata. Currently this is just FileMap.name, which is whatever path is passed to rustc. Since libcore and libstd are built by invoking rustc with relative paths, they wind up with relative paths in the rlib, and when linked into a binary the debug info uses relative paths for the names, but since the compilation directory for the final binary, tools trying to read source filenames will wind up with bad paths. We noticed this in Firefox with source filenames from libcore/libstd having bad paths. This change stores an absolute path in FileMap.abs_path, and uses that if available for writing debug info. This is not going to magically make debuggers able to find the source, but it will at least provide sensible paths.
2016-06-15prefer `if let` to match with `None => ()` arm in some placesZack M. Davis-23/+20
Casual grepping revealed some places in the codebase (some of which antedated `if let`'s December 2014 stabilization in c200ae5a) where we were using a match with a `None => ()` arm where (in the present author's opinion) an `if let` conditional would be more readable. (Other places where matching to the unit value did seem to better express the intent were left alone.) It's likely that we don't care about making such trivial, non-functional, sheerly æsthetic changes. But if we do, this is a patch.
2016-06-14Remove the type parameter from `syntax::visit::Visitor`Jeffrey Seyfried-2/+2
2016-05-25rustc: use a simpler scheme for plugin registrar symbol names.Eduard Burtescu-5/+9
2016-05-20Auto merge of #33625 - alexcrichton:rustbuild-moar-tests, r=aturonbors-49/+80
rustbuild: Touch up some test suites This adds in some missing test suites, primarily a few pretty suites. It also starts optimizing tests by default as the current test suite does, but also recognizes `--disable-optimize-tests`. Currently the optimization of tests isn't recognized by crate tests because Cargo doesn't support the ability to compile an unoptimized test suite against an optimized library. Perhaps a feature to add, though!
2016-05-20rustc: Fix again order-dependence in extern crateAlex Crichton-49/+80
Originally fixed in #29961 the bug was unfortunately still present in the face of crates using `#[macro_use]`. This commit refactors for the two code paths to share common logic to ensure that they both pick up the same bug fix. Closes #33762
2016-05-20Auto merge of #33553 - alexcrichton:cdylibs, r=brsonbors-0/+1
rustc: Add a new crate type, cdylib This commit is an implementation of [RFC 1510] which adds a new crate type, `cdylib`, to the compiler. This new crate type differs from the existing `dylib` crate type in a few key ways: * No metadata is present in the final artifact * Symbol visibility rules are the same as executables, that is only reachable `extern` functions are visible symbols * LTO is allowed * All libraries are always linked statically This commit is relatively simple by just plubming the compiler with another crate type which takes different branches here and there. The only major change is an implementation of the `Linker::export_symbols` function on Unix which now actually does something. This helps restrict the public symbols from a cdylib on Unix. With this PR a "hello world" `cdylib` is 7.2K while the same `dylib` is 2.4MB, which is some nice size savings! [RFC 1510]: https://github.com/rust-lang/rfcs/pull/1510 Closes #33132
2016-05-19rustc: Add a new crate type, cdylibAlex Crichton-0/+1
This commit is an implementation of [RFC 1510] which adds a new crate type, `cdylib`, to the compiler. This new crate type differs from the existing `dylib` crate type in a few key ways: * No metadata is present in the final artifact * Symbol visibility rules are the same as executables, that is only reachable `extern` functions are visible symbols * LTO is allowed * All libraries are always linked statically This commit is relatively simple by just plubming the compiler with another crate type which takes different branches here and there. The only major change is an implementation of the `Linker::export_symbols` function on Unix which now actually does something. This helps restrict the public symbols from a cdylib on Unix. With this PR a "hello world" `cdylib` is 7.2K while the same `dylib` is 2.4MB, which is some nice size savings! [RFC 1510]: https://github.com/rust-lang/rfcs/pull/1510 Closes #33132
2016-05-18allow retracing paths across cratesNiko Matsakis-0/+1
For external crates, we must build up a map that goes from the DefKey to the DefIndex. We do this by iterating over each index that is found in the metadata and loading the associated DefKey.
2016-05-11Make LocalCrateReader private to creader.Ms2ger-8/+19
2016-05-10Correct typo in LocalCrateReader::definitions.Ms2ger-4/+4
2016-05-10Store a reference rather than a RefCell in LocalCrateReader.Ms2ger-5/+4
2016-05-09rustc: Implement custom panic runtimesAlex Crichton-30/+122
This commit is an implementation of [RFC 1513] which allows applications to alter the behavior of panics at compile time. A new compiler flag, `-C panic`, is added and accepts the values `unwind` or `panic`, with the default being `unwind`. This model affects how code is generated for the local crate, skipping generation of landing pads with `-C panic=abort`. [RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md Panic implementations are then provided by crates tagged with `#![panic_runtime]` and lazily required by crates with `#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic runtime must match the final product, and if the panic strategy is not `abort` then the entire DAG must have the same panic strategy. With the `-C panic=abort` strategy, users can expect a stable method to disable generation of landing pads, improving optimization in niche scenarios, decreasing compile time, and decreasing output binary size. With the `-C panic=unwind` strategy users can expect the existing ability to isolate failure in Rust code from the outside world. Organizationally, this commit dismantles the `sys_common::unwind` module in favor of some bits moving part of it to `libpanic_unwind` and the rest into the `panicking` module in libstd. The custom panic runtime support is pretty similar to the custom allocator support with the only major difference being how the panic runtime is injected (takes the `-C panic` flag into account).
2016-05-02replace fileline_{help,note} with {help,note}Niko Matsakis-2/+2
The extra filename and line was mainly there to keep the indentation relative to the main snippet; now that this doesn't include filename/line-number as a prefix, it is distracted.
2016-04-20debugging, misc fixesNick Cameron-4/+7
2016-04-20def_collector and crate reader operate on AST instead of HIRNick Cameron-54/+26
And move extern crate reading earlier in the driver
2016-04-20Trivial refactoringNick Cameron-9/+8
2016-04-06rustc: move rustc_front to rustc::hir.Eduard Burtescu-4/+4
2016-03-31librustc_metadata: use bug!(), span_bug!()Benjamin Herr-3/+3
2016-03-25renumber error from E0522 to E0523Niko Matsakis-1/+1
another name was added in the meantime
2016-03-25pacify the merciless tidy: s/E0521/E0522Niko Matsakis-1/+1
Gah. I always find it confusing that make tidy gives me the highest error code, but not the **next** error code.
2016-03-25renumber diagnostic to avoid conflictNiko Matsakis-1/+1
specialization nabbed E0520
2016-03-25track the extern-crate def-id rather than pathNiko Matsakis-27/+59
We used to track, for each crate, a path that led to the extern-crate that imported it. Instead of that, track the def-id of the extern crate, along with a bit more information, and derive the path on the fly.
2016-03-25store krate information more uniformlyNiko Matsakis-1/+1
make DefPath store krate and enable uniform access to crate_name/crate_disambiguator
2016-03-25Add a "link-guard" to avoid accidentally linking to a wrong dylib at runtime.Michael Woerister-2/+2
We want to prevent compiling something against one version of a dynamic library and then, at runtime accidentally using a different version of the dynamic library. With the old symbol-naming scheme this could not happen because every symbol had the SVH in it and you'd get an error by the dynamic linker when using the wrong version of a dylib. With the new naming scheme this isn't the case any more, so this patch adds the "link-guard" to prevent this error case. This is implemented as follows: - In every crate that we compile, we emit a function called "__rustc_link_guard_<crate-name>_<crate-svh>" - The body of this function contains calls to the "__rustc_link_guard" functions of all dependencies. - An executable contains a call to it's own "__rustc_link_guard" function. As a consequence the "__rustc_link_guard" function call graph mirrors the crate graph and the dynamic linker will fail if a wrong dylib is loaded somewhere because its "__rustc_link_guard" function will contain a different SVH in its name.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-12 18:39:03 +0000