| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Add unstable `--print=crate-root-lint-levels`
This PR implements `--print=crate-root-lint-levels` from MCP 833 https://github.com/rust-lang/compiler-team/issues/833.
Tracking issue: https://github.com/rust-lang/rust/issues/139180
Best reviewed commit by commit.
|
|
|
|
|
|
|
|
Target modifiers fix for bool flags without value
Fixed support of boolean flags without values: `-Zbool-flag` is now consistent with `-Zbool-flag=true` in another crate.
When flag is explicitly set to default value, target modifier will not be set in crate metainfo (`-Zflag=false` when `false` is a default value for the flag).
Improved error notification when target modifier flag is absent in a crate ("-Zflag unset").
Example:
```
note: `-Zreg-struct-return=true` in this crate is incompatible with unset `-Zreg-struct-return` in dependency `default_reg_struct_return`
```
|
|
Rollup of 11 pull requests
Successful merges:
- #138128 (Stabilize `#![feature(precise_capturing_in_traits)]`)
- #138834 (Group test diffs by stage in post-merge analysis)
- #138867 (linker: Fix staticlib naming for UEFI)
- #138874 (Batch mark waiters as unblocked when resuming in the deadlock handler)
- #138875 (Trusty: Fix build for anonymous pipes and std::sys::process)
- #138877 (Ignore doctests only in specified targets)
- #138885 (Fix ui pattern_types test for big-endian platforms)
- #138905 (Add target maintainer information for powerpc64-unknown-linux-musl)
- #138911 (Allow defining opaques in statics and consts)
- #138917 (rustdoc: remove useless `Symbol::is_empty` checks.)
- #138945 (Override PartialOrd methods for bool)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
add FCW to warn about wasm ABI transition
See https://github.com/rust-lang/rust/issues/122532 for context: the "C" ABI on wasm32-unk-unk will change. The goal of this lint is to warn about any function definition and calls whose behavior will be affected by the change. My understanding is the following:
- scalar arguments are fine
- including 128 bit types, they get passed as two `i64` arguments in both ABIs
- `repr(C)` structs (recursively) wrapping a single scalar argument are fine (unless they have extra padding due to over-alignment attributes)
- all return values are fine
`@bjorn3` `@alexcrichton` `@Manishearth` is that correct?
I am making this a "show up in future compat reports" lint to maximize the chances people become aware of this. OTOH this likely means warnings for most users of Diplomat so maybe we shouldn't do this?
IIUC, wasm-bindgen should be unaffected by this lint as they only pass scalar types as arguments.
Tracking issue: https://github.com/rust-lang/rust/issues/138762
Transition plan blog post: https://github.com/rust-lang/blog.rust-lang.org/pull/1531
try-job: dist-various-2
|
|
|
|
Currently, compiling tests for SOLID produces an ICE, because SOLID does
not support executables.
|
|
|
|
Only use the new node hashmap for anonymous nodes
This is a rebase of https://github.com/rust-lang/rust/pull/112469.
cc `@cjgillot`
|
|
Cache current_dll_path output
Computing the current dll path is somewhat expensive relative to other work when compiling `fn main() {}` as `dladdr` needs to iterate over the symbol table of librustc_driver.so until it finds a match.
|
|
As an unstable print request.
|
|
Computing the current dll path is somewhat expensive relative to other
work when compiling `fn main() {}` as `dladdr` needs to iterate over the
symbol table of librustc_driver.so until it finds a match.
|
|
Suggest `-Whelp` when pass `--print lints` to rustc
Closes #138612
|
|
|
|
Represent diagnostic side effects as dep nodes
This changes diagnostic to be tracked as a special dep node (`SideEffect`) instead of having a list of side effects associated with each dep node. `SideEffect` is always red and when forced, it emits the diagnostic and marks itself green. Each emitted diagnostic generates a new `SideEffect` with an unique dep node index.
Some implications of this:
- Diagnostic may now be emitted more than once as they can be emitted once when the `SideEffect` gets marked green and again if the task it depends on needs to be re-executed due to another node being red. It relies on deduplicating of diagnostics to avoid that.
- Anon tasks which emits diagnostics will no longer *incorrectly* be merged with other anon tasks.
- Reusing a CGU will now emit diagnostics from the task generating it.
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
|
|
|
|
`{AllTargetSpecsJson,TargetSpecJson}`
To correspond to their actual print request names, `target-spec-json`
and `all-target-specs-json`, and for consistency with other print name
<-> print kind mappings.
|
|
helpers
To avoid duplicating stability check logic and make the print request
collection logic more straightforward.
|
|
|
|
|
|
Co-authored-by: Jieyou Xu <jieyouxu@outlook.com>
|
|
r=petrochenkov,jieyouxu
Cleanup sysroot locating a bit
All commits should preserve existing behavior.
|
|
|
|
All callers unwrap the result.
|
|
build_session_options always uses materialize_sysroot anyway.
|
|
It's no longer necessary now that `-Wunreachable_pub` is being passed.
|
|
Revert <https://github.com/rust-lang/rust/pull/138084> to buy time to
consider options that avoids breaking downstream usages of cargo on
distributed `rustc-src` artifacts, where such cargo invocations fail due
to inability to inherit `lints` from workspace root manifest's
`workspace.lints` (this is only valid for the source rust-lang/rust
workspace, but not really the distributed `rustc-src` artifacts).
This breakage was reported in
<https://github.com/rust-lang/rust/issues/138304>.
This reverts commit 48caf81484b50dca5a5cebb614899a3df81ca898, reversing
changes made to c6662879b27f5161e95f39395e3c9513a7b97028.
|
|
Use workspace lints for crates in `compiler/`
This is nicer and hopefully less error prone than specifying lints via bootstrap.
r? ``@jieyouxu``
|
|
r=compiler-errors
compiler: Use `size_of` from the prelude instead of imported
Use `std::mem::{size_of, size_of_val, align_of, align_of_val}` from the prelude instead of importing or qualifying them. Apply this change across the compiler.
These functions were added to all preludes in Rust 1.80.
r? ``@compiler-errors``
|
|
(Except for `rustc_codegen_cranelift`.)
It's no longer necessary now that `unreachable_pub` is in the workspace
lints.
|
|
Use `std::mem::{size_of, size_of_val, align_of, align_of_val}` from the
prelude instead of importing or qualifying them.
These functions were added to all preludes in Rust 1.80.
|
|
`-Zteach` is perma-unstable, barely used, the highlighting logic buggy and the flag being passed around is tech-debt. We should likely remove `-Zteach` in its entirely.
|
|
Use `default_field_values` for `rustc_errors::Context`, `rustc_session::config::NextSolverConfig` and `rustc_session::config::ErrorOutputType`
Wanted to see where `#![feature(default_field_values)]` could be used in the codebase. These three seemed like no-brainers. There are a bunch of more places where we could remove manual `Default` impls, but they `derive` other traits that rely on `syn`, which [doesn't yet support `default_field_values`](https://github.com/dtolnay/syn/issues/1774).
|
|
Remove unused `PpMode::needs_hir`
This method was added in #99360 to avoid an overzealous `span_delayed_bug` ICE in specific circumstances, but the only caller was subsequently removed in #136603, which presumably avoids the problem in a more principled way.
|
|
Support raw-dylib link kind on ELF
raw-dylib is a link kind that allows rustc to link against a library without having any library files present.
This currently only exists on Windows. rustc will take all the symbols from raw-dylib link blocks and put them in an import library, where they can then be resolved by the linker.
While import libraries don't exist on ELF, it would still be convenient to have this same functionality. Not having the libraries present at build-time can be convenient for several reasons, especially cross-compilation. With raw-dylib, code linking against a library can be cross-compiled without needing to have these libraries available on the build machine. If the libc crate makes use of this, it would allow cross-compilation without having any libc available on the build machine. This is not yet possible with this implementation, at least against libc's like glibc that use symbol versioning. The raw-dylib kind could be extended with support for symbol versioning in the future.
This implementation is very experimental and I have not tested it very well. I have tested it for a toy example and the lz4-sys crate, where it was able to successfully link a binary despite not having a corresponding library at build-time.
I was inspired by Björn's comments in https://internals.rust-lang.org/t/bundle-zig-cc-in-rustup-by-default/22096/27
Tracking issue: #135694
r? bjorn3
try-job: aarch64-apple
try-job: x86_64-msvc-1
try-job: x86_64-msvc-2
try-job: test-various
|
|
|
|
Remove manual `Default` impl from `config::ErrorOutputType`.
|
|
Use default field values to avoid manual `Default` impl.
|
|
|
|
The embedded bitcode should always be prepared for LTO/ThinLTO
Fixes #115344. Fixes #117220.
There are currently two methods for generating bitcode that used for LTO. One method involves using `-C linker-plugin-lto` to emit object files as bitcode, which is the typical setting used by cargo. The other method is through `-C embed-bitcode=yes`.
When using with `-C embed-bitcode=yes -C lto=no`, we run a complete non-LTO LLVM pipeline to obtain bitcode, then the bitcode is used for LTO. We run the Call Graph Profile Pass twice on the same module.
This PR is doing something similar to LLVM's `buildFatLTODefaultPipeline`, obtaining the bitcode for embedding after running `buildThinLTOPreLinkDefaultPipeline`.
r? nikic
|
|
raw-dylib is a link kind that allows rustc to link against a library
without having any library files present.
This currently only exists on Windows. rustc will take all the symbols
from raw-dylib link blocks and put them in an import library, where they
can then be resolved by the linker.
While import libraries don't exist on ELF, it would still be convenient
to have this same functionality. Not having the libraries present at
build-time can be convenient for several reasons, especially
cross-compilation. With raw-dylib, code linking against a library can be
cross-compiled without needing to have these libraries available on the
build machine. If the libc crate makes use of this, it would allow
cross-compilation without having any libc available on the build
machine. This is not yet possible with this implementation, at least
against libc's like glibc that use symbol versioning.
The raw-dylib kind could be extended with support for symbol versioning
in the future.
This implementation is very experimental and I have not tested it very
well. I have tested it for a toy example and the lz4-sys crate, where it
was able to successfully link a binary despite not having a
corresponding library at build-time.
|
|
Make it so that every structured error annotated with `#[derive(Diagnostic)]` that has a field of type `Ty<'_>`, the printing of that value into a `String` will look at the thread-local storage `TyCtxt` in order to shorten to a length appropriate with the terminal width. When this happen, the resulting error will have a note with the file where the full type name was written to.
```
error[E0618]: expected function, found `((..., ..., ..., ...), ..., ..., ...)``
--> long.rs:7:5
|
6 | fn foo(x: D) { //~ `x` has type `(...
| - `x` has type `((..., ..., ..., ...), ..., ..., ...)`
7 | x(); //~ ERROR expected function, found `(...
| ^--
| |
| call expression requires function
|
= note: the full name for the type has been written to 'long.long-type-14182675702747116984.txt'
= note: consider using `--verbose` to print the full type name to the console
```
|
|
|
|
|
|
|
