| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This is the next step in getting rid of the broken C abi for
wasm32-unknown-unknown.
|
|
|
|
|
|
In order to avoid diagnostics suggesting stdlib-private dependencies,
make everything that is a direct dependency of any `std` crates private
by default. Note that this will be overridden, if the same crate is
public elsewhere in the crate graph then that overrides the private
default.
It may also be feasible to do this in the library crate, marking `std`'s
dependencies private via Cargo. However, given that the feature is still
rather unstable, doing this within the compiler seems more
straightforward.
Fixes: https://github.com/rust-lang/rust/issues/135232 [1]
|
|
Currently `root` or `crate_root` is used to refer to an instance of
`CrateRoot` (representation of a crate's serialized metadata), but the
name `root` sometimes also refers to a `CratePath` representing a "root"
node in the dependency graph. In order to disambiguate, rename all
instances of the latter to `dep_root`.
|
|
|
|
`rustc_span::symbol` defines some things that are re-exported from
`rustc_span`, such as `Symbol` and `sym`. But it doesn't re-export some
closely related things such as `Ident` and `kw`. So you can do `use
rustc_span::{Symbol, sym}` but you have to do `use
rustc_span::symbol::{Ident, kw}`, which is inconsistent for no good
reason.
This commit re-exports `Ident`, `kw`, and `MacroRulesNormalizedIdent`,
and changes many `rustc_span::symbol::` qualifiers in `compiler/` to
`rustc_span::`. This is a 200+ net line of code reduction, mostly
because many files with two `use rustc_span` items can be reduced to
one.
|
|
|
|
|
|
Allow injecting a profiler runtime into `#![no_core]` crates
An alternative to #133300, allowing `-Cinstrument-coverage` to be used with `-Zbuild-std`.
The incompatibility between `profiler_builtins` and `#![no_core]` crates appears to have been caused by profiler_builtins depending on core, and therefore conflicting with core (or minicore).
But that's a false dependency, because the profiler doesn't contain any actual Rust code. So we can just mark the profiler itself as `#![no_core]`, and remove the incompatibility error.
---
For context, the error was originally added by #79958.
|
|
|
|
Now that the profiler runtime is itself `#![no_core]`, it can be a dependency
of other no_core crates, including core.
|
|
inject_panic_runtime(): Avoid double negation for 'any non rlib'
<details>
<summary>This PR originally did more things .Click to expand to see.</summary>
By not trying to inject a profiler runtime when only building an rlib. This logic already exists for the panic runtime.
This makes
RUSTFLAGS="-Cinstrument-coverage" cargo build -Zbuild-std=std,profiler_builtins
work. Note that you probably also need
`RUST_COMPILER_RT_FOR_PROFILER=$src/llvm-project/compiler-rt` in your environment.
cc #79401
# Demonstration
Before this fix you get these errors:
```console
$ rm -rf target ; RUST_COMPILER_RT_FOR_PROFILER=/home/martin/src/llvm-project/compiler-rt RUSTFLAGS="-Cinstrument-coverage" cargo +nightly build --release -Zbuild-std=std,profiler_builtins
error: `profiler_builtins` crate (required by compiler options) is not compatible with crate attribute `#![no_core]`
error[E0152]: found duplicate lang item `manually_drop`
= note: first definition in `core` loaded from /home/martin/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-d453bab70303062c.rlib
= note: second definition in the local crate (`core`)
```
With the fix the build succeeds:
```console
$ rm -rf target ; RUST_COMPILER_RT_FOR_PROFILER=/home/martin/src/llvm-project/compiler-rt RUSTFLAGS="-Cinstrument-coverage" cargo +stage1 build --release -Zbuild-std=std,profiler_builtins
Finished `release` profile [optimized] target(s) in 45.57s
```
And we can check code coverage. My example program looks like this:
```rs
fn main() {
if std::env::args_os().nth(1) == Some("write-file".into()) {
std::fs::write("hello.txt", "Hello, world!").unwrap();
} else {
println!("Hello, world!");
}
}
```
when the program prints to stdout:
```
$ LLVM_PROFILE_FILE=stdout.profraw ./target/release/hello-world
Hello, world!
```
we can see that `fs::write()` is not being used (note the `0`'s):
```console
$ /home/martin/src/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-profdata merge -sparse stdout.profraw -o stdout.profdata
$ /home/martin/src/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-cov show target/release/hello-world --sources /home/martin/src/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/src/rust/library/std/src/fs.rs --instr-profile stdout.profdata --color | grep -A 3 'pub fn write(&mut self, write: b
ool) -> &mut Self {'
1357| 0| pub fn write(&mut self, write: bool) -> &mut Self {
1358| 0| self.0.write(write);
1359| 0| self
1360| 0| }
```
but when we print to a file:
```console
$ LLVM_PROFILE_FILE=file.profraw ./target/release/hello-world write-file
```
the code coverage shows `fs::write()` as being used (note the `1`'s):
```console
$ /home/martin/src/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-profdata merge -sparse file.profraw -o file.profdata
$ /home/martin/src/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-cov show target/release/hello-world --sources /home/martin/src/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/src/rust/library/std/src/fs.rs --instr-profile file.profdata --color | grep -A 3 'pub fn write(&mut self, write: bool) -> &mut Self {'
1357| 1| pub fn write(&mut self, write: bool) -> &mut Self {
1358| 1| self.0.write(write);
1359| 1| self
1360| 1| }
```
</summary>
|
|
|
|
|
|
fmt
fix cfg for windows
remove unused imports
address comments
update libc to 0.2.164
fmt
remove unused imports
|
|
Over in Zed we've noticed that loading crates for a large-ish workspace can take almost 200ms. We've pinned it down to how rustc searches for paths, as it performs a linear search over the list of candidate paths. In our case the candidate list had about 20k entries which we had to iterate over for each dependency being loaded.
This commit introduces a simple FilesIndex that's just a sorted Vec under the hood. Since crates are looked up by both prefix and suffix, we perform a range search on said Vec (which constraints the search space based on prefix) and follow up with a linear scan of entries with matching suffixes.
FilesIndex is also pre-filtered before any queries are performed using available target information; query prefixes/sufixes are based on the target we are compiling for, so we can remove entries that can never match up front.
Overall, this commit brings down build time for us in dev scenarios by about 6%.
100ms might not seem like much, but this is a constant cost that each of our workspace crates has to pay, even when said crate is miniscule.
|
|
This changes the naming to the new naming, used by `--print
target-tuple`.
It does not change all locations, but many.
|
|
|
|
|
|
|
|
|
|
The previous commit updated `rustfmt.toml` appropriately. This commit is
the outcome of running `x fmt --all` with the new formatting options.
|
|
This paves the way for tracking more state (e.g. error tainting) in the diagnostic context handle
|
|
|
|
|
|
|
|
|
|
|
|
This ensures all diagnostic messages are created at diagnostic emission
time, making them translatable.
|
|
|
|
|
|
|
|
This way it's like `Definitions`, which creates `DefId`s by interning `DefPathData`s, but for interning stable crate hashes
|
|
|
|
Fixed the `private-dependency` bug
Fixed the private-dependency bug: If the directly dependent crate is loaded last and is not configured with `--extern`, it may be incorrectly set to `private-dependency`
Fixes #122756
|
|
loaded last and is not configured with `--extern`, it may be incorrectly set to `private-dependency`
|
|
osiewicz:metadata-register-crate-store-crate-name-in-profile, r=Nadrieril
rustc-metadata: Store crate name in self-profile of metadata_register_crate
When profiling a build of Zed, I found myself in need of names of crates that take the longest to register in downstream crates.
|
|
When profiling a build of Zed, I found myself in need of names of crates that take the longest to register in downstream crates.
|
|
|
|
r=davidtwco
Rework `untranslatable_diagnostic` lint
Currently it only checks calls to functions marked with `#[rustc_lint_diagnostics]`. This PR changes it to check calls to any function with an `impl Into<{D,Subd}iagnosticMessage>` parameter. This greatly improves its coverage and doesn't rely on people remembering to add `#[rustc_lint_diagnostics]`. It also lets us add `#[rustc_lint_diagnostics]` to a number of functions that don't have an `impl Into<{D,Subd}iagnosticMessage>`, such as `Diag::span`.
r? ``@davidtwco``
|
|
Currently it only checks calls to functions marked with
`#[rustc_lint_diagnostics]`. This commit changes it to check calls to
any function with an `impl Into<{D,Subd}iagMessage>` parameter. This
greatly improves its coverage and doesn't rely on people remembering to
add `#[rustc_lint_diagnostics]`.
The commit also adds `#[allow(rustc::untranslatable_diagnostic)`]
attributes to places that need it that are caught by the improved lint.
These places that might be easy to convert to translatable diagnostics.
Finally, it also:
- Expands and corrects some comments.
- Does some minor formatting improvements.
- Adds missing `DecorateLint` cases to
`tests/ui-fulldeps/internal-lints/diagnostics.rs`.
|
|
Fix duplicated path in the "not found dylib" error
While working on the gcc backend, I couldn't figure out why I had this error:
```
error: couldn't load codegen backend /checkout/compiler/rustc_codegen_gcc/target/release/librustc_codegen_gcc.so/checkout/compiler/rustc_codegen_gcc/target/release/librustc_codegen_gcc.so: cannot open shared object file: No such file or directory
```
As you can see, the path is duplicated for some reason. After investigating a bit more, I realized that `libloading::Error::LoadLibraryExW` starts with the path of the not found dylib, making it appear twice in our error afterward (because we do render it like this: `{path}{err}`, and since the `err` starts with the path...).
Thanks to `````@bjorn3````` for linking me to https://github.com/rust-lang/rust/pull/121392. :)
|
|
Existing names for values of this type are `sess`, `parse_sess`,
`parse_session`, and `ps`. `sess` is particularly annoying because
that's also used for `Session` values, which are often co-located, and
it can be difficult to know which type a value named `sess` refers to.
(That annoyance is the main motivation for this change.) `psess` is nice
and short, which is good for a name used this much.
The commit also renames some `parse_sess_created` values as
`psess_created`.
|
|
|
|
Unify dylib loading between proc macros and codegen backends
As bonus this makes the errors when failing to load a proc macro more informative to match the backend loading errors. In addition it makes it slightly easier to patch rustc to work on platforms that don't support dynamic linking like wasm.
|
|
Currently `has_errors` excludes lint errors. This commit changes it to
include lint errors.
The motivation for this is that for most places it doesn't matter
whether lint errors are included or not. But there are multiple places
where they must be includes, and only one place where they must not be
included. So it makes sense for `has_errors` to do the thing that fits
the most situations, and the new `has_errors_excluding_lint_errors`
method in the one exceptional place.
The same change is made for `err_count`. Annoyingly, this requires the
introduction of `err_count_excluding_lint_errs` for one place, to
preserve existing error printing behaviour. But I still think the change
is worthwhile overall.
|
|
As bonus this makes the errors when failing to load a proc macro more
informative to match the backend loading errors. In addition it makes it
slightly easier to patch rustc to work on platforms that don't support
dynamic linking like wasm.
|
|
|
|
|
