| Age | Commit message (Collapse) | Author | Lines |
|---|
|
rustc_metadata: Give decoder access to whole crate store
Pre-requisite for https://github.com/rust-lang/rust/pull/68941.
r? @eddyb
|
|
fix various typos
|
|
|
|
|
|
CrateMetadata`
|
|
|
|
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.
|
|
use .copied() instead of .map(|x| *x) on iterators
|
|
|
|
|
|
|
|
use is_empty() instead of len() == x to determine if structs are empty.
|
|
Remove unneeded calls to format!()
|
|
|
|
|
|
Generalized article_and_description
r? @matthewjasper
The logic of finding the right word and article to print seems to be repeated elsewhere... this is an experimental method to unify this logic...
|
|
instead of a hand rolled one.
|
|
|
|
|
|
|
|
Fixes #68690
When we generate the proc macro harness, we now explicitly recorder the
order in which we generate entries. We then use this ordering data to
deserialize the correct proc-macro-data from the crate metadata.
|
|
Remove unused feature gates
I think many of the remaining unstable things can be easily be replaced with stable things. I have kept the `#![feature(nll)]` even though it is only necessary in `libstd`, to make regressions of it harder.
|
|
|
|
|
|
Step stage0 to bootstrap from 1.42
This also includes a commit which fixes the rustfmt downloading logic to redownload when the rustfmt channel changes, and bumps rustfmt to a more recent version.
|
|
|
|
For now, this is all the crate contains, but more
attribute logic & types will be moved there over time.
|
|
|
|
Address inconsistency in using "is" with "declared here"
"is" was generally used for NLL diagnostics, but not other diagnostics. Using "is" makes the diagnostics sound more natural and readable, so it seems sensible to commit to them throughout.
r? @Centril
|
|
rustc: Allow cdylibs to link against dylibs
Previously, rustc mandated that cdylibs could only link against rlibs as dependencies (not dylibs).
This commit disables that restriction and tests that it works in a simple case.
I don't have a windows rustc dev environment, so I guessed at the MSVC test code, I'm hoping the CI can run that for me.
Additionally, we might want to consider emitting (through cargo or rustc) some metadata to help C users of a cdylib figure out where all the dylibs they need are. I don't think that should be needed to land this change, as it will still be usable by homogeneous build systems without it.
My new test was templated off the `tests/run-make-fulldeps/cdylib` test. It seemed more appropriate to have it as a separate test, since both foo.rs and bar.rs would need to be replicated to make that test cover both cases, but I can do that if it would be preferred.
If I'm doing anything out of order/process, please let me know; this is only my second change to rustc and the prior one was trivial.
r? alexcrichton
|
|
|
|
Previously, rustc mandated that cdylibs could only link against rlibs as
dependencies (not dylibs).
This commit disables that restriction and tests that it works in a
simple case.
|
|
Avoid declaring a fake dependency edge
When we're producing an rlib, we do not need anything more than an rmeta file
for each of our dependencies (this is indeed utilized by Cargo for pipelining).
Previously, we were still storing the paths of possible rlib/dylib crates, which
meant that they could still plausibly be accessed. With -Zbinary-dep-depinfo,
that meant that Cargo thought that rustc was using both the rlib and an (earlier
emitted) rmeta, and so needed a recompile, as the rlib may have finished writing
*after* compilation started (for more detail, see issue 68149).
This commit changes metadata loading to not store the filepaths of dylib/rlib if
we're going to end up creating an rlib only.
Fixes #68149.
|
|
When we're producing an rlib, we do not need anything more than an rmeta file
for each of our dependencies (this is indeed utilized by Cargo for pipelining).
Previously, we were still storing the paths of possible rlib/dylib crates, which
meant that they could still plausibly be accessed. With -Zbinary-dep-depinfo,
that meant that Cargo thought that rustc was using both the rlib and an (earlier
emitted) rmeta, and so needed a recompile, as the rlib may have finished writing
*after* compilation started (for more detail, see issue 68149).
This commit changes metadata loading to not store the filepaths of dylib/rlib if
we're going to end up creating an rlib only.
|
|
Remove `rustc_error_codes` deps except in `rustc_driver`
Remove dependencies on `rustc_error_codes` in all crates except for `rustc_driver`.
This has some benefits:
1. Adding a new error code when hacking on the compiler only requires rebuilding at most `rustc_error_codes`, `rustc_driver`, and the reflexive & transitive closure of the crate where the new error code is being added and its reverse dependencies. This improves time-to-UI-tests (TTUT).
2. Adding an error description to an error code only requires rebuilding `rustc_error_codes` and `rustc_driver`. This should substantially improve TTUT.
r? @petrochenkov
cc @rust-lang/wg-diagnostics
|
|
|
|
|
|
|
|
found via clippy
|
|
|
|
Point at the span for the definition of crate foreign ADTs
Follow up to #65421. Partially addresses #65386. Blocked on #53081.
|
|
Extract `rustc_ast_passes`, move gating, & refactor linting
Based on https://github.com/rust-lang/rust/pull/67770.
This PR extracts a crate `rustc_ast_passes`:
- `ast_validation.rs`, which is contributed by `rustc_passes` (now only has HIR based passes) -- the goal here is to improve recompilation of the parser,
- `feature_gate.rs`, which is contributed by `syntax` and performs post-expansion-gating & final erroring for pre-expansion gating,
- `show_span`, which is contributed by `syntax`.
To facilitate this, we first have to also:
- Move `{leveled_}feature_err{_err}` from `syntax::feature_gate::check` into `rustc_session::parse`.
- Move `get_features` into `rustc_parse::config`, the only place it is used.
- Move some some lint datatypes and traits, e.g. `LintBuffer`, `BufferedEarlyLint`, `BuiltinLintDiagnostics`, `LintPass`, and `LintArray` into `rustc_session::lint`.
- Move all the hard-wired lint `static`s into `rustc_session::lint::builtin`.
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
