summary refs log tree commit diff
path: root/src/librustc_metadata/creader.rs
AgeCommit message (Collapse)AuthorLines
2017-04-22cache attributes of items from foreign cratesAriel Ben-Yehuda-0/+1
this avoids parsing item attributes on each call to `item_attrs`, which takes off 33% (!) of translation time and 50% (!) of trans-item collection time.
2017-04-13remove `LinkMeta` from `SharedCrateContext`Niko Matsakis-3/+3
A number of things were using `crate_hash` that really ought to be using `crate_disambiguator` (e.g., to create the plugin symbol names). They have been updated. It is important to remove `LinkMeta` from `SharedCrateContext` since it contains a hash of the entire crate, and hence it will change whenever **anything** changes (which would then require rebuilding **everything**).
2017-03-27Fix various useless derefs and slicingsOliver Schneider-1/+1
2017-03-23Remove internal liblogAlex Crichton-1/+1
This commit deletes the internal liblog in favor of the implementation that lives on crates.io. Similarly it's also setting a convention for adding crates to the compiler. The main restriction right now is that we want compiler implementation details to be unreachable from normal Rust code (e.g. requires a feature), and by default everything in the sysroot is reachable via `extern crate`. The proposal here is to require that crates pulled in have these lines in their `src/lib.rs`: #![cfg_attr(rustbuild, feature(staged_api, rustc_private))] #![cfg_attr(rustbuild, unstable(feature = "rustc_private", issue = "27812"))] This'll mean that by default they're not using these attributes but when compiled as part of the compiler they do a few things: * Mark themselves as entirely unstable via the `staged_api` feature and the `#![unstable]` attribute. * Allow usage of other unstable crates via `feature(rustc_private)` which is required if the crate relies on any other crates to compile (other than std).
2017-03-21Correctly get source for metadata crate type;Austin Bonander-1/+2
replace `unwrap()` with `expect()`
2017-03-19Auto merge of #40346 - jseyfried:path_and_tokenstream_attr, r=nrcbors-3/+5
`TokenStream`-based attributes, paths in attribute and derive macro invocations This PR - refactors `Attribute` to use `Path` and `TokenStream` instead of `MetaItem`. - supports macro invocation paths for attribute procedural macros. - e.g. `#[::foo::attr_macro] struct S;`, `#[cfg_attr(all(), foo::attr_macro)] struct S;` - supports macro invocation paths for derive procedural macros. - e.g. `#[derive(foo::Bar, super::Baz)] struct S;` - supports arbitrary tokens as arguments to attribute procedural macros. - e.g. `#[foo::attr_macro arbitrary + tokens] struct S;` - supports using arbitrary tokens in "inert attributes" with derive procedural macros. - e.g. `#[derive(Foo)] struct S(#[inert arbitrary + tokens] i32);` where `#[proc_macro_derive(Foo, attributes(inert))]` r? @nrc
2017-03-14Refactor `Attribute` to use `Path` and `TokenStream` instead of `MetaItem`.Jeffrey Seyfried-3/+5
2017-03-12Update usages of 'OSX' (and other old names) to 'macOS'.Corey Farwell-1/+1
As of last year with version 'Sierra', the Mac operating system is now called 'macOS'.
2017-02-28Implement function-like procedural macros ( `#[proc_macro]`)Austin Bonander-1/+10
2017-02-23Better handling of lib defaultsPeter Wagenet-2/+12
2017-02-12Allow using inert attributes from `proc_macro_derive`s with ↵Jeffrey Seyfried-4/+3
`#![feature(proc_macro)]`.
2017-02-08sanitizer supportJorge Aparicio-1/+63
2017-02-05Rollup merge of #39442 - keeperofdakeys:expand-derives, r=jseyfriedCorey Farwell-3/+3
Expand derive macros in the MacroExpander This removes the expand_derives function, and sprinkles the functionality throughout the Invocation Collector, Expander and Resolver. Fixes https://github.com/rust-lang/rust/issues/39326 r? @jseyfried
2017-02-05Rename CustomDerive to ProcMacroDerive for macros 1.1Josh Driver-3/+3
2017-02-04Auto merge of #38426 - vadimcn:nobundle, r=alexcrichtonbors-0/+11
Implement kind="static-nobundle" (RFC 1717) This implements the "static-nobundle" library kind (last item from #37403). Rustc handles "static-nobundle" libs very similarly to dylibs, except that on Windows, uses of their symbols do not get marked with "dllimport". Which is the whole point of this feature.
2017-02-03Don't link "nobundle" libs which had already been included in upstream crate.Vadim Chugunov-0/+3
2017-01-19Feature gateVadim Chugunov-0/+7
2017-01-19Implement the "static-nobundle" library kind (RFC 1717).Vadim Chugunov-0/+1
These are static libraries that are not bundled (as the name implies) into rlibs and staticlibs that rustc generates, and must be present when the final binary artifact is being linked.
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.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-12 18:11:34 +0000