summary refs log tree commit diff
path: root/src/librustc_metadata/creader.rs
AgeCommit message (Collapse)AuthorLines
2017-01-16Implement `#[proc_macro_attribute]`Austin Bonander-0/+10
* Add support for `#[proc_macro]` * Reactivate `proc_macro` feature and gate `#[proc_macro_attribute]` under it * Have `#![feature(proc_macro)]` imply `#![feature(use_extern_macros)]`, error on legacy import of proc macros via `#[macro_use]`
2017-01-09metadata: Add is_exported_symbol() method to CrateStore.Michael Woerister-0/+3
2016-12-29Change --crate-type metadata to --emit=metadataNick Cameron-2/+1
2016-12-16definitions: Add some timing stats for DefPathTable decoding.Michael Woerister-1/+6
2016-12-16definitions: Store DefPath data in separate table in metadataMichael Woerister-1/+1
2016-12-05Consider only libs that aren't excluded by #[link(cfg=...)]Vadim Chugunov-4/+20
2016-12-02Rename _all_ library instances.Vadim Chugunov-1/+0
2016-12-01Tighten up error checking of library renames.Vadim Chugunov-5/+37
2016-12-01Remove the "linked_from" feature.Vadim Chugunov-22/+1
2016-12-01Implement native library kind and name overrides from the command line.Vadim Chugunov-8/+14
2016-12-01Emit 'dllimport' attribute for dylib foreign items on Windows.Vadim Chugunov-25/+53
2016-11-28Avoid loading needless proc-macro dependencies.Jeffrey Seyfried-18/+13
2016-11-24Delay error reporting of filename mismatch.Paul Lietar-0/+3
When cross compiling with procedural macros, the crate loader starts by looking for a target crate, before trying with a host crate. Rather than emitting an error immediately if the host and target extension differ, the compiler should delay it until both attempts have failed. Fixes #37899 r? @jseyfried
2016-11-22Auto merge of #37681 - nrc:crate-metadata, r=@alexcrichtonbors-4/+9
add --crate-type metadata r? @alexcrichton
2016-11-23Rebasing and review changesNick Cameron-2/+1
2016-11-21Auto merge of #37824 - jseyfried:symbols, r=eddybbors-40/+37
Clean up `ast::Attribute`, `ast::CrateConfig`, and string interning This PR - removes `ast::Attribute_` (changing `Attribute` from `Spanned<Attribute_>` to a struct), - moves a `MetaItem`'s name from the `MetaItemKind` variants to a field of `MetaItem`, - avoids needlessly wrapping `ast::MetaItem` with `P`, - moves string interning into `syntax::symbol` (`ast::Name` is a reexport of `symbol::Symbol` for now), - replaces `InternedString` with `Symbol` in the AST, HIR, and various other places, and - refactors `ast::CrateConfig` from a `Vec` to a `HashSet`. r? @eddyb
2016-11-21Use `Symbol` instead of `InternedString` in the AST, HIR, and various other ↵Jeffrey Seyfried-38/+35
places.
2016-11-20Move `syntax::util::interner` -> `syntax::symbol`, cleanup.Jeffrey Seyfried-3/+3
2016-11-21Read in rmeta cratesNick Cameron-2/+7
2016-11-21Add --crate-type metadataNick Cameron-1/+2
With the same semantics as -Zno-trans
2016-11-20Fix bug in proc-macro dependencies.Jeffrey Seyfried-0/+3
2016-11-20Refactor `MetaItemKind` to use `Name`s instead of `InternedString`s.Jeffrey Seyfried-3/+3
2016-11-18Fix bug in loading proc macro dependencies.Jeffrey Seyfried-4/+4
2016-11-16rustc: Implement #[link(cfg(..))] and crt-staticAlex Crichton-14/+35
This commit is an implementation of [RFC 1721] which adds a new target feature to the compiler, `crt-static`, which can be used to select how the C runtime for a target is linked. Most targets dynamically linke the C runtime by default with the notable exception of some of the musl targets. [RFC 1721]: https://github.com/rust-lang/rfcs/blob/master/text/1721-crt-static.md This commit first adds the new target-feature, `crt-static`. If enabled, then the `cfg(target_feature = "crt-static")` will be available. Targets like musl will have this enabled by default. This feature can be controlled through the standard target-feature interface, `-C target-feature=+crt-static` or `-C target-feature=-crt-static`. Next this adds an gated and unstable `#[link(cfg(..))]` feature to enable the `crt-static` semantics we want with libc. The exact behavior of this attribute is a little squishy, but it's intended to be a forever-unstable implementation detail of the liblibc crate. Specifically the `#[link(cfg(..))]` annotation means that the `#[link]` directive is only active in a compilation unit if that `cfg` value is satisfied. For example when compiling an rlib, these directives are just encoded and ignored for dylibs, and all staticlibs are continued to be put into the rlib as usual. When placing that rlib into a staticlib, executable, or dylib, however, the `cfg` is evaluated *as if it were defined in the final artifact* and the library is decided to be linked or not. Essentially, what'll happen is: * On MSVC with `-C target-feature=-crt-static`, the `msvcrt.lib` library will be linked to. * On MSVC with `-C target-feature=+crt-static`, the `libcmt.lib` library will be linked to. * On musl with `-C target-feature=-crt-static`, the object files in liblibc.rlib are removed and `-lc` is passed instead. * On musl with `-C target-feature=+crt-static`, the object files in liblibc.rlib are used and `-lc` is not passed. This commit does **not** include an update to the liblibc module to implement these changes. I plan to do that just after the 1.14.0 beta release is cut to ensure we get ample time to test this feature. cc #37406
2016-11-10Support `#[macro_reexport]`ing custom derives.Jeffrey Seyfried-79/+57
2016-11-10Improve macro reexports.Jeffrey Seyfried-82/+35
2016-11-10Register and stability check `#[no_link]` crates.Jeffrey Seyfried-27/+25
2016-11-10Refactor `explicitly_linked: bool` -> `dep_kind: DepKind`.Jeffrey Seyfried-16/+17
2016-11-10Clean up `CrateSource`.Jeffrey Seyfried-30/+19
2016-11-09Rollup merge of #37614 - keeperofdakeys:proc_macro, r=jseyfriedEduard-Mihai Burtescu-2/+6
macros 1.1: Allow proc_macro functions to declare attributes to be mark as used This PR allows proc macro functions to declare attribute names that should be marked as used when attached to the deriving item. There are a few questions for this PR. - Currently this uses a separate attribute named `#[proc_macro_attributes(..)]`, is this the best choice? - In order to make this work, the `check_attribute` function had to be modified to not error on attributes marked as used. This is a pretty large change in semantics, is there a better way to do this? - I've got a few clones where I don't know if I need them (like turning `item` into a `TokenStream`), can these be avoided? - Is switching to `MultiItemDecorator` the right thing here? Also fixes https://github.com/rust-lang/rust/issues/37563.
2016-11-08Allow proc_macro functions to whitelist specific attributesJosh Driver-2/+6
By using a second attribute `attributes(Bar)` on proc_macro_derive, whitelist any attributes with the name `Bar` in the deriving item. This allows a proc_macro function to use custom attribtues without a custom attribute error or unused attribute lint.
2016-11-08Replace FnvHasher use with FxHasher.Nicholas Nethercote-6/+6
This speeds up compilation by 3--6% across most of rustc-benchmarks.
2016-10-31Changed most vec! invocations to use square bracesiirelu-8/+8
Most of the Rust community agrees that the vec! macro is clearer when called using square brackets [] instead of regular brackets (). Most of these ocurrences are from before macros allowed using different types of brackets. There is one left unchanged in a pretty-print test, as the pretty printer still wants it to have regular brackets.
2016-10-29Move `CrateConfig` from `Crate` to `ParseSess`.Jeffrey Seyfried-8/+1
2016-10-24Clean up `CrateLoader::process_item`.Jeffrey Seyfried-62/+32
2016-10-24Refactor away `CrateLoader::load_macros`.Jeffrey Seyfried-14/+14
2016-10-24Refactor away `metadata::creader::Macros`.Jeffrey Seyfried-58/+30
2016-10-24Refactor away fields `MacroDef::{use_locally, export}`.Jeffrey Seyfried-3/+0
2016-10-24Import macros in `resolve` instead of in `metadata::macro_import`.Jeffrey Seyfried-8/+69
2016-10-22Rename `loader.rs` -> `locator.rs`.Jeffrey Seyfried-15/+15
2016-10-22Move `Library` into `creader.rs`.Jeffrey Seyfried-4/+10
2016-10-22Remove `CrateReader`, use `CrateLoader` instead.Jeffrey Seyfried-34/+14
2016-10-17Auto merge of #36969 - nnethercote:rename-Parser-fields, r=eddybbors-1/+1
Clarify the positions of the lexer and parser The lexer and parser use unclear names to indicate their positions in the source code. I propose the following renamings. Lexer: ``` pos -> next_pos # it's actually the next pos! last_pos -> pos # it's actually the current pos! curr -> ch # the current char curr_is -> ch_is # tests the current char col (unchanged) # the current column ``` parser ``` - last_span -> prev_span # the previous token's span - last_token_kind -> prev_token_kind # the previous token's kind - LastTokenKind -> PrevTokenKind # ditto (but the type) - token (unchanged) # the current token - span (unchanged) # the current span ``` Things to note: - This proposal removes all uses of "last", which is an unclear word because it could mean (a) previous, (b) final, or (c) most recent, i.e. current. - The "current" things (ch, col, token, span) consistently lack a prefix. The "previous" and "next" things consistently have a prefix.
2016-10-06rustc: Rename rustc_macro to proc_macroAlex Crichton-6/+6
This commit blanket renames the `rustc_macro` infrastructure to `proc_macro`, which reflects the general consensus of #35900. A follow up PR to Cargo will be required to purge the `rustc-macro` name as well.
2016-10-05Rename Parser::last_span as prev_span.Nicholas Nethercote-1/+1
This is a [breaking-change] for libsyntax.
2016-09-28Rollup merge of #36794 - japaric:target-panic, r=alexcrichtonJonathan Turner-2/+2
add a panic-strategy field to the target specification Now a target can define its panic strategy in its specification. If a user doesn't specify a panic strategy via the command line, i.e. '-C panic', then the compiler will use the panic strategy defined by the target specification. Custom targets can pick their panic strategy via the "panic-strategy" field of their target specification JSON file. If omitted in the specification, the strategy defaults to "unwind". closes #36647 --- I checked that compiling an executable for a custom target with "panic-strategy" set to "abort" doesn't need the "eh_personality" lang item and also that standard crates compiled for that custom target didn't contained undefined symbols to _Unwind_Resume. But this needs an actual unit test, any suggestion on how to test this? Most of the noise in the diff is due to moving `PanicStrategy` from the `rustc` to the `rustc_back` crate. r? @alexcrichton cc @phil-opp
2016-09-27add a panic-strategy field to the target specificationJorge Aparicio-2/+2
Now a target can define its panic strategy in its specification. If a user doesn't specify a panic strategy via the command line, i.e. '-C panic', then the compiler will use the panic strategy defined by the target specification. Custom targets can pick their panic strategy via the "panic-strategy" field of their target specification JSON file. If omitted in the specification, the strategy defaults to "unwind". closes #36647
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
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-12 17:37:43 +0000