bump conflicting_repr_hints lint to be shown in dependencies
This has been a future compatibility lint for years, let's bump it up to be shown in dependencies (so that hopefully we can then make it a hard error fairly soon).
Cc https://github.com/rust-lang/rust/issues/68585
compiletest: use `std::fs::remove_dir_all` now that it is available
It turns out `aggressive_rm_rf` is not sufficiently aggressive (RAGEY) on Windows and obviously handles Windows symlinks incorrectly. Instead of rolling our own version, let's use `std::fs::remove_dir_all` now that it's available (well, it's been available for a good while, but probably wasn't available when this helper was written).
cc #129187 since basically this is failing due to similar problems.
Blocker for #128562.
Fixes#129155.
Fixes#126334.
Update `library/Cargo.toml` in weekly job
Before the workspace split, the library was covered by the weekly `cargo update` cron job. Now that the library has its own workspace, it doesn't get these updates.
Add `library/Cargo.toml` to the job so updates happen again.
improve submodule updates
During config parsing, some bootstrap logic (e.g., `download-ci-llvm`) checks certain sources (for `download-ci-llvm`, it's `src/llvm-project`) and acts based on their state. This means that if path is a git submodule, bootstrap needs to update it before checking its state. Otherwise it may make incorrect assumptions by relying on outdated sources. To enable submodule updates during config parsing, we need to move the `update_submodule` function from the `Build` to `Config`, so we can access to it during the parsing process.
Closes#122787
bootstrap: fix clean's remove_dir_all implementation
It turns out bootstrap's `clean.rs`'s hand-rolled `rm_rf` (which probably comes before `std::fs::remove_dir_all` was stable) is very broken on native Windows around both read-only files/directories and especially symbolic links. So instead of rolling our own, just use `std::fs::remove_dir_all`.
This is a blocker for compiletest's own `rm_rf` implementation #129155 which happens to be also buggy, which in turn is a blocker for the rmake.rs test port #128562 that heavily exercises symlinks (I was reviewing #128562 and testing it on native Windows which is how I found out).
I also left a FIXME for `detect_src_and_out` due to a failing assertion on native Windows (opened #129188):
```
---- core::config::tests::detect_src_and_out stdout ----
thread 'core::config::tests::detect_src_and_out' panicked at src\core\config\tests.rs:72:13:
assertion `left == right` failed
left: "E:\\tmp"
right: "C:\\tmp"
```
Fixes#112544 (because now we handle Windows symlinks properly).
try-job: x86_64-msvc
try-job: i686-mingw
try-job: test-various
try-job: armhf-gnu
try-job: aarch64-apple
try-job: aarch64-gnu
Point at explicit `'static` obligations on a trait
Given `trait Any: 'static` and a `struct` with a `Box<dyn Any + 'a>` field, point at the `'static` bound in `Any` to explain why `'a: 'static`.
```
error[E0478]: lifetime bound not satisfied
--> f202.rs:2:12
|
2 | value: Box<dyn std::any::Any + 'a>,
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
note: lifetime parameter instantiated with the lifetime `'a` as defined here
--> f202.rs:1:14
|
1 | struct Hello<'a> {
| ^^
note: but lifetime parameter must outlive the static lifetime
--> /home/gh-estebank/rust/library/core/src/any.rs:113:16
|
113 | pub trait Any: 'static {
| ^^^^^^^
```
Partially address #33652.
Improve diagnostic-related lints: `untranslatable_diagnostic` & `diagnostic_outside_of_impl`
Summary:
- Made `untranslatable_diagnostic` point to problematic arguments instead of the function call
(I found this misleading while working on some `A-translation` PRs: my first impression was that
the methods themselves were not translation-aware and needed to be changed,
while in reality the problem was with the hardcoded strings passed as arguments).
- Made the shared pass of `untranslatable_diagnostic` & `diagnostic_outside_of_impl` more efficient.
`@rustbot` label D-imprecise-spans A-translation
Implement `debug_more_non_exhaustive`
This implements the ACP at https://github.com/rust-lang/libs-team/issues/248, adding `.finish_non_exhaustive()` for `DebugTuple`, `DebugSet`, `DebugList`, and `DebugMap`.
Also used this as an opportunity to make some documentation and tests more readable by using raw strings instead of escaped quotes.
Tracking issue: https://github.com/rust-lang/rust/issues/127942
use old ctx if has same expand environment during decode span
Fixes#112680
The root reason why #112680 failed with incremental compilation on the second attempt is the difference in `opaque` between the span of the field [`ident`](https://github.com/rust-lang/rust/blob/master/compiler/rustc_hir_typeck/src/expr.rs#L2348) and the span in the incremental cache at `tcx.def_ident_span(field.did)`.
- Let's call the span of `ident` as `span_a`, which is generated by [`apply_mark_internal`](https://github.com/rust-lang/rust/blob/master/compiler/rustc_span/src/hygiene.rs#L553-L554). Its content is similar to:
```rs
span_a_ctx -> SyntaxContextData {
opaque: span_a_ctx,
opaque_and_semitransparent: span_a_ctx,
// ....
}
```
- And call the span of `tcx.def_ident_span` as `span_b`, which is generated by [`decode_syntax_context`](https://github.com/rust-lang/rust/blob/master/compiler/rustc_span/src/hygiene.rs#L1390). Its content is:
```rs
span_b_ctx -> SyntaxContextData {
opaque: span_b_ctx,
// note `span_b_ctx` is not same as `span_a_ctx`
opaque_and_semitransparent: span_b_ctx,
// ....
}
```
Although they have the same `parent` (both refer to the root) and `outer_expn`, I cannot find the specific connection between them. Therefore, I chose a solution that may not be the best: give up the incremental compile cache to ensure we can use `span_a` in this case.
r? `@petrochenkov` Do you have any advice on this? Or perhaps this solution is acceptable?
Rollup of 10 pull requests
Successful merges:
- #128627 (Special case DUMMY_SP to emit line 0/column 0 locations on DWARF platforms.)
- #128843 (Minor Refactor: Remove a Redundant Conditional Check)
- #129179 (CFI: Erase regions when projecting ADT to its transparent non-1zst field)
- #129281 (Tweak unreachable lint wording)
- #129312 (Fix stability attribute of `impl !Error for &str`)
- #129332 (Avoid extra `cast()`s after `CStr::as_ptr()`)
- #129339 (Make `ArgAbi::make_indirect_force` more specific)
- #129344 (Use `bool` in favor of `Option<()>` for diagnostics)
- #129345 (Use shorthand field initialization syntax more aggressively in the compiler)
- #129355 (fix comment on PlaceMention semantics)
r? `@ghost`
`@rustbot` modify labels: rollup
Given `trait Any: 'static` and a `struct` with a `Box<dyn Any + 'a>` field, point at the `'static` bound in `Any` to explain why `'a: 'static`.
```
error[E0478]: lifetime bound not satisfied
--> f202.rs:2:12
|
2 | value: Box<dyn std::any::Any + 'a>,
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
note: lifetime parameter instantiated with the lifetime `'a` as defined here
--> f202.rs:1:14
|
1 | struct Hello<'a> {
| ^^
note: but lifetime parameter must outlive the static lifetime
--> /home/gh-estebank/rust/library/core/src/any.rs:113:16
|
113 | pub trait Any: 'static {
| ^^^^^^^
```
Partially address #33652.
Use shorthand field initialization syntax more aggressively in the compiler
Caught these when cleaning up #129344 and decided to run clippy to find the rest
Use `bool` in favor of `Option<()>` for diagnostics
We originally only supported `Option<()>` for optional notes/labels, but we now support `bool`. Let's use that, since it usually leads to more readable code.
I'm not removing the support from the derive macro, though I guess we could error on it... 🤔
Make `ArgAbi::make_indirect_force` more specific
As the method is only needed for making ignored ZSTs indirect on some ABIs, rename and add a doc-comment and `self.mode` check to make it harder to accidentally misuse. Addresses review feedback from https://github.com/rust-lang/rust/pull/125854#discussion_r1721047899.
r? ``@RalfJung``
Avoid extra `cast()`s after `CStr::as_ptr()`
These used to be `&str` literals that did need a pointer cast, but that
became a no-op after switching to `c""` literals in #118566.
CFI: Erase regions when projecting ADT to its transparent non-1zst field
The output from `FieldDef::ty` (or `TyCtxt::type_of`) may have free regions (well, `'static`) -- erase it.
Fixes#129169Fixes#123685
Minor Refactor: Remove a Redundant Conditional Check
The existing code checks `where_bounds.is_empty()` twice when
it can be combined into one. Now, after combining, the refactored code reads
better and feels straightforward.
The diff doesn't make it clear. So, the current code looks like this:
``` rust
if !where_bounds.is_empty() {
err.help(format!(
"consider introducing a new type parameter `T` and adding `where` constraints:\
\n where\n T: {qself_str},\n{}",
where_bounds.join(",\n"),
));
}
let reported = err.emit();
if !where_bounds.is_empty() {
return Err(reported);
}
```
The proposed changes:
``` rust
if !where_bounds.is_empty() {
err.help(format!(
"consider introducing a new type parameter `T` and adding `where` constraints:\
\n where\n T: {qself_str},\n{}",
where_bounds.join(",\n"),
));
let reported = err.emit();
return Err(reported);
}
err.emit();
```
Special case DUMMY_SP to emit line 0/column 0 locations on DWARF platforms.
Line 0 has a special meaning in DWARF. From the version 5 spec:
The compiler may emit the value 0 in cases
where an instruction cannot be attributed to any
source line.
DUMMY_SP spans cannot be attributed to any line. However, because rustc internally stores line numbers starting at zero, lookup_debug_loc() adjusts every line number by one. Special casing DUMMY_SP to actually emit line 0 ensures rustc communicates to the debugger that there's no meaningful source code for this instruction, rather than telling the debugger to jump to line 1 randomly.
Add a precondition check for Layout::from_size_align_unchecked
Ran into this while looking into https://github.com/rust-lang/miri/issues/3679. This is of course not the cause of the ICE, but the reproducer doesn't encounter a precondition check and it ought to.
Rollup of 9 pull requests
Successful merges:
- #128662 (Lint on tail expr drop order change in Edition 2024)
- #128932 (skip updating when external binding is existed)
- #129270 (Don't consider locals to shadow inner items' generics)
- #129277 (Update annotate-snippets to 0.11)
- #129294 (Stabilize `iter::repeat_n`)
- #129308 (fix: simple typo in compiler directory)
- #129309 (ctfe: make CompileTimeInterpCx type alias public)
- #129314 (fix a broken link in `mir/mod.rs`)
- #129318 (Remove unneeded conversion to `DefId` for `ExtraInfo`)
r? `@ghost`
`@rustbot` modify labels: rollup
modularize rustdoc's write_shared
Refactor src/librustdoc/html/render/write_shared.rs to reduce code duplication, adding unit tests
* Extract + unit test code for sorting and rendering JSON, which is duplicated 9 times in the current impl
* Extract + unit test code for encoding JSON as single quoted strings, which is duplicated twice in the current impl
* Unit tests for cross-crate information file formats
* Generic interface to add new kinds of cross-crate information files in the future
* Intended to match current behavior exactly, except for a merge info comment it adds to the bottom of cci files
* This PR is intended to reduce the review burden from my [mergeable rustdoc rfc](https://github.com/rust-lang/rfcs/pull/3662) implementation PR, which is a [small commit based on this branch](https://github.com/EtomicBomb/rust/tree/rfc). This code is agnostic to the RFC and does not include any of the flags discussed there, but cleanly enables the addition of these flags in the future because it is more modular
Remove unneeded conversion to `DefId` for `ExtraInfo`
I'm working on adding support for "unit test doctests" and this first cleanup came up so just sending it ahead of the rest.
r? ``@notriddle``
fix a broken link in `mir/mod.rs`
I discovered that the internal link in mir/mod.rs is broken, so I will fix it. The AddCallGuards is now located under rustc_mir_transform.
The PR at that time is as follows.
c5fc2609f0
ctfe: make CompileTimeInterpCx type alias public
`CompileTimeMachine` is already public so there is no good reason to not also make this public.
Also add comment explaining why `CompileTimeMachine` is public.
