about summary refs log tree commit diff
path: root/src/librustc_metadata/rmeta/decoder
AgeCommit message (Collapse)AuthorLines
2020-04-28Use the query system to allocate.Camille GILLOT-11/+7
2020-04-26fix more clippy warningsMatthias Krüger-1/+1
clippy::{redundant_pattern_matching, clone_on_copy, iter_cloned_collect, option_as_ref_deref, match_ref_pats}
2020-04-19Dogfood more or_patterns in the compilerJosh Stone-5/+2
2020-04-05Remove unneeded Lrc in query results.Camille GILLOT-1/+3
2020-04-05Remove Arcs in queries.Camille GILLOT-2/+1
2020-04-05Allocate query Vecs on the arena.Camille GILLOT-1/+1
2020-03-30rustc -> rustc_middle part 3 (rustfmt)Mazdak Farrokhzad-7/+7
2020-03-30rustc -> rustc_middle part 2Mazdak Farrokhzad-7/+7
2020-03-26Make QueryConfig argument a type.Camille GILLOT-1/+1
2020-03-24Rollup merge of #70077 - Aaron1011:feature/new-def-path-ident, r=petrochenkovMazdak Farrokhzad-3/+3
Store idents for `DefPathData` into crate metadata Previously, we threw away the `Span` associated with a definition's identifier when we encoded crate metadata, causing us to lose location and hygiene information. We now store the identifier's `Span` in a side table, which gets encoded into the crate metadata. When we decode items from the metadata, we combine the name and span back into an `Ident`. This improves the output of several tests, which previously had messages suppressed due to dummy spans. This is a prerequisite for #68686, since throwing away a `Span` means that we lose hygiene information.
2020-03-22Store idents for `DefPathData` into crate metadataAaron Hill-3/+3
Previously, we threw away the `Span` associated with a definition's identifier when we encoded crate metadata, causing us to lose location and hygiene information. We now store the identifier's `Span` in the crate metadata. When we decode items from the metadata, we combine the name and span back into an `Ident`. This improves the output of several tests, which previously had messages suppressed due to dummy spans. This is a prerequisite for #68686, since throwing away a `Span` means that we lose hygiene information.
2020-03-21{rustc::hir::map -> rustc_hir}::definitionsMazdak Farrokhzad-2/+2
2020-03-21Rollup merge of #70092 - eddyb:hir-items-are-just-nodes, r=ZoxcMazdak Farrokhzad-1/+1
hir: replace "items" terminology with "nodes" where appropriate. The newly added `HirOwnerItems` confused me before I realized that "items" there actually referred to HIR nodes, not `hir:Item` or "item-like" (which we should IMO replace with "owner"). I suspect the naming had something to do with `ItemLocalId`'s use of "item". That is, `ItemLocalId` could be interpreted to mean one of two things: * `IntraItemNodeId` i.e. `IntraOwnerNodeId` * this is IMO correct, and I'd even like to rename it, but I didn't want to throw that into this PR * `IntraOwnerItemId` * this is what `HirOwnerItems` would seem to imply r? @Zoxc cc @michaelwoerister @nikomatsakis
2020-03-20remove redundant returns (clippy::needless_return)Matthias Krüger-1/+1
2020-03-19hir: replace "items" terminology with "nodes" where appropriate.Eduard-Mihai Burtescu-1/+1
2020-03-16use direct imports for `rustc::{lint, session}`.Mazdak Farrokhzad-1/+1
2020-03-15Auto merge of #68944 - Zoxc:hir-map, r=eddybbors-1/+1
Use queries for the HIR map r? @eddyb cc @michaelwoerister
2020-03-14Replace `HirBody` with `hir_owner_items` in testsJohn Kåre Alsaker-1/+1
2020-03-14rustc_metadata: Remove `rmeta::MacroDef`Vadim Petrochenkov-12/+4
Use `ast::MacroDef` instead. Also remove `Session::imported_macro_spans`, external macros have spans now.
2020-03-10Auto merge of #66364 - Centril:cleanup-macro-def, r=petrochenkov,eddybbors-27/+14
Cleanup `rmeta::MacroDef` Avoid using rountrip parsing in the encoder and in `fn load_macro_untracked`. The main reason I was interested in this was to remove `rustc_parse` as a dependency of `rustc_metadata` but it seems like this had other benefits as well. Fixes #49511. r? @eddyb cc @matthewjasper @estebank @petrochenkov
2020-03-10Store `TokenStream` in `rmeta::MacroDef`.Mazdak Farrokhzad-27/+14
This removes a hack from `load_macro_untracked` in which parsing is used.
2020-03-05rustc_metadata: Give decoder access to whole crate storeVadim Petrochenkov-1/+1
2020-03-02Auto merge of #69432 - petrochenkov:alldeps, r=eddybbors-9/+1
rustc_metadata: Load metadata for indirect macro-only dependencies Imagine this dependency chain between crates ``` Executable crate -> Library crate -> Macro crate ``` where "Library crate" uses the macros from "Macro crate" for some code generation, but doesn't reexport them any further. Currently, when compiling "Executable crate" we don't even load metadata for it, because why would we want to load any metadata from "Macro crate" if it already did all its code generation job when compiling "Library crate". Right? Wrong! Hygiene data and spans (https://github.com/rust-lang/rust/issues/68686, https://github.com/rust-lang/rust/pull/68941) from "Macro crate" still may need to be decoded from "Executable crate". So we'll have to load them properly. Questions: - How this will affect compile times for larger crate trees in practice? How to measure it? Hygiene/span encoding/decoding will necessarily slow down compilation because right now we just don't do some work that we should do, but this introduces a whole new way to slow down things. E.g. loading metadata for `syn` (and its dependencies) when compiling your executable if one of its library dependencies uses it. - We are currently detecting whether a crate reexports macros from "Macro crate" or not, could we similarly detect whether a crate "reexports spans" and keep it unloaded if it doesn't? Or at least "reexports important spans" affecting hygiene, we can probably lose spans that only affect diagnostics.
2020-02-29Rename `syntax` to `rustc_ast` in source codeVadim Petrochenkov-5/+5
2020-02-24rustc_metadata: Load metadata for indirect macro-only dependenciesVadim Petrochenkov-9/+1
2020-02-22add generator_kind queryMark Mansi-0/+1
2020-01-11Auto merge of #65912 - estebank:variants-orig, r=petrochenkovbors-0/+4
Point at the span for the definition of crate foreign ADTs Follow up to #65421. Partially addresses #65386. Blocked on #53081.
2020-01-10Auto merge of #65241 - tmiasko:no-std-san, r=alexcrichtonbors-1/+0
build-std compatible sanitizer support ### Motivation When using `-Z sanitizer=*` feature it is essential that both user code and standard library is instrumented. Otherwise the utility of sanitizer will be limited, or its use will be impractical like in the case of memory sanitizer. The recently introduced cargo feature build-std makes it possible to rebuild standard library with arbitrary rustc flags. Unfortunately, those changes alone do not make it easy to rebuild standard library with sanitizers, since runtimes are dependencies of std that have to be build in specific environment, generally not available outside rustbuild process. Additionally rebuilding them requires presence of llvm-config and compiler-rt sources. The goal of changes proposed here is to make it possible to avoid rebuilding sanitizer runtimes when rebuilding the std, thus making it possible to instrument standard library for use with sanitizer with simple, although verbose command: ``` env CARGO_TARGET_X86_64_UNKNOWN_LINUX_GNU_RUSTFLAGS=-Zsanitizer=thread cargo test -Zbuild-std --target x86_64-unknown-linux-gnu ``` ### Implementation * Sanitizer runtimes are no long packed into crates. Instead, libraries build from compiler-rt are used as is, after renaming them into `librusc_rt.*`. * rustc obtains runtimes from target libdir for default sysroot, so that they are not required in custom build sysroots created with build-std. * The runtimes are only linked-in into executables to address issue #64629. (in previous design it was hard to avoid linking runtimes into static libraries produced by rustc as demonstrated by sanitizer-staticlib-link test, which still passes despite changes made in #64780). cc @kennytm, @japaric, @firstyear, @choller
2020-01-10Point at the span for the definition of crate foreign ADTsEsteban Küber-0/+4
2020-01-09add CStore::item_generics_num_lifetimesMazdak Farrokhzad-4/+4
2020-01-09Remove sanitizer_runtime attributeTomasz Miąsko-1/+0
2020-01-05Remove rustc_hir reexports in rustc::hir.Mazdak Farrokhzad-2/+2
2020-01-04extract Export, ExportMap from hir::defMazdak Farrokhzad-20/+19
2020-01-04DefId{Map,Set} -> rustc::hir::def_idMazdak Farrokhzad-2/+1
2020-01-02Normalize `syntax::symbol` imports.Mazdak Farrokhzad-1/+1
2020-01-02Normalize `syntax::source_map` imports.Mazdak Farrokhzad-2/+2
2020-01-01Rename `syntax_pos` to `rustc_span` in source codeVadim Petrochenkov-1/+1
2019-12-22Format the worldMark Rousskov-62/+68
2019-12-13Require stable/unstable annotations for the constness of all stable ↵Oliver Scherer-0/+3
functions with a `const` modifier
2019-12-02syntax: Use `ast::MacArgs` for macro definitionsVadim Petrochenkov-1/+4
2019-11-28rustc: Move some queries to `rustc_metadata`Vadim Petrochenkov-21/+12
2019-11-28rustc_metadata: Move `has_global_allocator` from session to cstoreVadim Petrochenkov-0/+4
2019-11-28rustc_metadata: Privatize some fields and methods of `CStore`Vadim Petrochenkov-2/+2
After it's moved to `creader.rs`
2019-11-28rustc_metadata: Merge `cstore.rs` into `creader.rs`Vadim Petrochenkov-3/+3
2019-11-28rustc_metadata: Cleanup generation of crate dependency listsVadim Petrochenkov-1/+1
2019-11-17rustc_metadata: Remove `CrateMetadata::is_proc_macro_crate`Vadim Petrochenkov-1/+1
2019-11-17rustc_metadata: Move `CrateMetadata` into `decoder.rs`Vadim Petrochenkov-1/+1
It allows to make most of its fields private
2019-11-11Move allocator_kind to CrateStoreMark Rousskov-0/+5
Similarly to the previous commit, there's no need for this to be in Session and have a Once around it.
2019-11-11Move injected_panic_runtime to CrateStoreMark Rousskov-0/+4
This was essentially a "query" previously (with no key, just always run once when resolving the crate dependencies), and remains so, just now in a way that isn't on Session. This removes the need for the `Once` as well.
2019-11-10Auto merge of #65324 - Centril:organize-syntax, r=petrochenkovbors-2/+2
Split libsyntax apart In this PR the general idea is to separate the AST, parser, and friends by a more data / logic structure (tho not fully realized!) by separating out the parser and macro expansion code from libsyntax. Specifically have now three crates instead of one (libsyntax): - libsyntax: - concrete syntax tree (`syntax::ast`) - definition of tokens and token-streams (`syntax::{token, tokenstream}`) -- used by `syntax::ast` - visitors (`syntax::visit`, `syntax::mut_visit`) - shared definitions between `libsyntax_expand` - feature gating (`syntax::feature_gate`) -- we could possibly move this out to its own crater later. - attribute and meta item utilities, including used-marking (`syntax::attr`) - pretty printer (`syntax::print`) -- this should possibly be moved out later. For now I've reduced down the dependencies to a single essential one which could be broken via `ParseSess`. This entails that e.g. `Debug` impls for `Path` cannot reference the pretty printer. - definition of `ParseSess` (`syntax::sess`) -- this is used by `syntax::{attr, print, feature_gate}` and is a common definition used by the parser and other things like librustc. - the `syntax::source_map` -- this includes definitions used by `syntax::ast` and other things but could ostensibly be moved `syntax_pos` since that is more related to this module. - a smattering of misc utilities not sufficiently important to itemize -- some of these could be moved to where they are used (often a single place) but I wanted to limit the scope of this PR. - librustc_parse: - parser (`rustc_parse::parser`) -- reading a file and such are defined in the crate root tho. - lexer (`rustc_parse::lexer`) - validation of meta grammar (post-expansion) in (`rustc_parse::validate_attr`) - libsyntax_expand -- this defines the infra for macro expansion and conditional compilation but this is not libsyntax_ext; we might want to merge them later but currently libsyntax_expand is depended on by librustc_metadata which libsyntax_ext is not. - conditional compilation (`syntax_expand::config`) -- moved from `syntax::config` to here - the bulk of this crate is made up of the old `syntax::ext` r? @estebank