summary refs log tree commit diff
path: root/src/librustc_metadata/creader.rs
AgeCommit message (Collapse)AuthorLines
2020-04-18Add an option to inhibit automatic injection of profiler_builtinsAmanieu d'Antras-1/+3
2020-03-30rustc -> rustc_middle part 3 (rustfmt)Mazdak Farrokhzad-3/+5
2020-03-30rustc -> rustc_middle part 2Mazdak Farrokhzad-3/+3
2020-03-24normalize some imports, prefer direct ones.Mazdak Farrokhzad-1/+1
2020-03-21Rollup merge of #69965 - mark-i-m:codegen-utils, r=eddybMazdak Farrokhzad-5/+2
Refactorings to get rid of rustc_codegen_utils r? @eddyb cc #45276 After this, the only modules left in `rustc_codegen_utils` are - `link`: a bunch of linking-related functions (many dealing with file names). These are mostly consumed by save analysis, rustc_driver, rustc_interface, and of course codegen. I assume they live here because we don't want a dependency of save analysis on codegen... Perhaps they can be moved to librustc? - ~`symbol_names` and `symbol_names_test`: honestly it seems odd that `symbol_names_test` is not a submodule of `symbol_names`. It seems like these could honestly live in their own crate or move to librustc. Already name mangling is exported as the `symbol_name` query.~ (move it to its own crate) I don't mind doing either of the above as part of this PR or a followup if you want.
2020-03-20remove redundant returns (clippy::needless_return)Matthias Krüger-1/+1
2020-03-19Refactorings to begin getting rid of rustc_codegen_utilsMark Mansi-5/+2
2020-03-19rustc: use LocalDefId instead of DefIndex in hir::map::definitions.Eduard-Mihai Burtescu-2/+2
2020-03-16use direct imports for `rustc::{lint, session}`.Mazdak Farrokhzad-5/+4
2020-03-05rustc_metadata: Give decoder access to whole crate storeVadim Petrochenkov-4/+20
2020-03-02Auto merge of #69432 - petrochenkov:alldeps, r=eddybbors-6/+3
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-3/+3
2020-02-27Remove unneeded calls to format!()Björn Steinbrink-4/+1
2020-02-24rustc_metadata: Load metadata for indirect macro-only dependenciesVadim Petrochenkov-6/+3
2020-01-24Normalise diagnostics with respect to "the X is declared/defined here"varkor-1/+1
2020-01-18remove rustc_error_codes deps except in rustc_driverMazdak Farrokhzad-1/+0
2020-01-10Auto merge of #65241 - tmiasko:no-std-san, r=alexcrichtonbors-104/+1
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-10nix syntax::errors & prefer rustc_errors over errorsMazdak Farrokhzad-10/+8
2020-01-09add CStore::item_generics_num_lifetimesMazdak Farrokhzad-2/+1
2020-01-09Link sanitizer runtimes instead of injecting crate dependenciesTomasz Miąsko-104/+1
2020-01-08- remove syntax::{span_warn!, span_err!, span_fatal!. struct_err!}Mazdak Farrokhzad-3/+5
- remove syntax::{help!, span_help!, span_note!} - remove unused syntax::{struct_span_fatal, struct_span_err_or_warn!, span_err_or_warn!} - lintify check_for_bindings_named_same_as_variants + conflicting_repr_hints - inline syntax::{struct_span_warn!, diagnostic_used!} - stringify_error_code! -> error_code! & use it more. - find_plugin_registrar: de-fatalize an error - de-fatalize metadata errors - move type_error_struct! to rustc_typeck - struct_span_err! -> rustc_errors
2020-01-05Remove rustc_hir reexports in rustc::hir.Mazdak Farrokhzad-2/+2
2020-01-02Normalize `syntax::edition` imports.Mazdak Farrokhzad-1/+1
2020-01-02Normalize `syntax::symbol` imports.Mazdak Farrokhzad-1/+1
2020-01-01Rename `syntax_pos` to `rustc_span` in source codeVadim Petrochenkov-1/+1
2019-12-30Rename `libsyntax_ext` and `libsyntax_expand` in codeVadim Petrochenkov-1/+1
2019-12-22Format the worldMark Rousskov-160/+204
2019-12-11Rollup merge of #67074 - ehuss:extern-options, r=petrochenkovMazdak Farrokhzad-7/+8
Add options to --extern flag. This changes the `--extern` flag so that it can take a series of options that changes its behavior. The general syntax is `[opts ':'] name ['=' path]` where `opts` is a comma separated list of options. Two options are supported, `priv` which replaces `--extern-private` and `noprelude` which avoids adding the crate to the extern prelude. ```text --extern priv:mylib=/path/to/libmylib.rlib --extern noprelude:alloc=/path/to/liballoc.rlib ``` `noprelude` is to be used by Cargo's build-std feature in order to use `--extern` to reference standard library crates. This also includes a second commit which adds the `aux-crate` directive to compiletest. I can split this off into a separate PR if desired, but it helps with defining these kinds of tests. It is based on #54020, and can be used in the future to replace and simplify some of the Makefile tests.
2019-12-09Add options to --extern flag.Eric Huss-7/+8
2019-12-06Rename to `then_some` and `then`varkor-1/+1
2019-12-06Use `to_option` in various placesvarkor-5/+2
2019-11-28rustc: Move some queries to `rustc_metadata`Vadim Petrochenkov-0/+5
2019-11-28rustc_metadata: Avoid some side effects during speculative crate resolutionVadim Petrochenkov-28/+5
Namely, `update_extern_crate`. Also, stop tracking visited crates in `update_extern_crate`, the rank check does the same thing (prevents visiting dependencies if the rank didn't change), but more precisely.
2019-11-28rustc_metadata: Pass SVH by valueVadim Petrochenkov-6/+5
2019-11-28rustc_metadata: Move `has_global_allocator` from session to cstoreVadim Petrochenkov-17/+16
2019-11-28rustc_metadata: Privatize some fields and methods of `CStore`Vadim Petrochenkov-5/+13
After it's moved to `creader.rs`
2019-11-28rustc_metadata: Merge `cstore.rs` into `creader.rs`Vadim Petrochenkov-16/+93
2019-11-28rustc_metadata: Privatize `CrateMetadata::root`Vadim Petrochenkov-15/+15
2019-11-28rustc_metadata: Privatize all fields of `CrateRoot`Vadim Petrochenkov-34/+33
All of them are read-only
2019-11-28rustc_metadata: Privatize `CrateMetadata::dep_kind`Vadim Petrochenkov-5/+3
2019-11-28rustc_metadata: Privatize `CrateMetadata::source`Vadim Petrochenkov-5/+5
2019-11-28rustc_metadata: Privatize `CrateMetadata::extern_crate`Vadim Petrochenkov-30/+6
2019-11-28rustc_metadata: Privatize `CrateMetadata::dependencies`Vadim Petrochenkov-2/+2
2019-11-28rustc_metadata: Cleanup generation of crate dependency listsVadim Petrochenkov-1/+1
2019-11-25Tweak multiple allocators errorEsteban Küber-1/+3
2019-11-17rustc_metadata: Stop leaking `Lazy` from the `rmeta` moduleVadim Petrochenkov-6/+8
2019-11-17rustc_metadata: Move `CrateMetadata` into `decoder.rs`Vadim Petrochenkov-8/+8
It allows to make most of its fields private
2019-11-17rustc_metadata: Give a constructor to `CratePaths`Vadim Petrochenkov-1/+1
2019-11-17rustc_metadata: Minor cleanupVadim Petrochenkov-1/+1
2019-11-17rustc_metadata: Give a constructor to `CrateMetadata`Vadim Petrochenkov-34/+9
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-04-27 19:49:32 +0000