This class originated in the very first commit of `rustdoc_ng`, and was used
to add a color border around the item decl based on its kind.
4fd061c426/src/rustdoc_ng/html/static/main.css (L102-L106)
The item decl no longer has a border, and there aren't any
kind-specific styles in modern rustdoc's rendering of this UI item.
Most of this commit is updating test cases so that they use `item-decl` to
find the `<pre>` tag instead of relying on the fact that the class name
had `rust {kind}` in it while other `<pre>` tags only had class `rust`.
As @bjorn3 pointed out [here], I used the wrong stability attribute in #98368
when making `std::os::fd` public. I set it to Rust 1.63, which was when
io-safety was stabilized, but it should be Rust 1.66, which was when
`std::os::fd` was stabilized.
[here]: https://github.com/rust-lang/rust/pull/98368#discussion_r1063721420
Remove various double spaces in the libraries.
I was just pretty bothered by this when reading the source for a function, and was suggested to check if this happened elsewhere.
rustdoc: remove `docblock` class from notable trait popover
This commit builds on b72de9be74dd5ac1d8b23d5ece03a7690274a14c, which removes the `docblock` class from the All Items page, and 9457380ac902db3febf92077c5b645db55998ad4, which removes the `docblock` class from the item decl.
Fixes#92974
Stop probing for statx unless necessary
As is the current toy program:
fn main() -> std::io::Result<()> {
use std::fs;
let metadata = fs::metadata("foo.txt")?;
assert!(!metadata.is_dir());
Ok(())
}
... observed under strace will issue:
[snip]
statx(0, NULL, AT_STATX_SYNC_AS_STAT, STATX_ALL, NULL) = -1 EFAULT (Bad address) statx(AT_FDCWD, "foo.txt", AT_STATX_SYNC_AS_STAT, STATX_ALL, {stx_mask=STATX_ALL|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFREG|0644, stx_size=0, ...}) = 0
While statx is not necessarily always present, checking for it can be delayed to the first error condition. Said condition may very well never happen, in which case the check got avoided altogether.
Note this is still suboptimal as there still will be programs issuing it, but bulk of the problem is removed.
Tested by forbidding the syscall for the binary and observing it correctly falls back to newfstatat.
While here tidy up the commentary, in particular by denoting some problems with the current approach.
Switch to `EarlyBinder` for `const_param_default` and `impl_trait_ref` queries
Part of the work to close#105779 and implement https://github.com/rust-lang/types-team/issues/78.
Several queries `X` have a `bound_X` variant that wraps the output in `EarlyBinder`. This PR adds `EarlyBinder` to the return type of `const_param_default` and `impl_trait_ref`, and removes their `bound_X` variants.
r? `@lcnr`
Rollup of 10 pull requests
Successful merges:
- #106046 (Fix mir-opt tests for big-endian platforms)
- #106470 (tidy: Don't include wasm32 in compiler dependency check)
- #106566 (Emit a single error for contiguous sequences of unknown tokens)
- #106644 (Update the wasi-libc used for the wasm32-wasi target)
- #106665 (Add note when `FnPtr` vs. `FnDef` impl trait)
- #106752 (Emit a hint for bad call return types due to generic arguments)
- #106788 (Tweak E0599 and elaborate_predicates)
- #106831 (Use GitHub yaml templates for ICE, Docs and Diagnostics tickets)
- #106846 (Improve some comments and names in parser)
- #106848 (Fix wrong path in triage bot autolabel for wg-trait-solver-refactor)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Cranelift makes api breaking changes often enough that this workflow
fails half of the time. As such in practice I completely ignore it's
result and push an update to a branch after Cranelift branches to test
everything on CI. In this update I immediately fix the fallout of api
breaking changes.
Enabling CAS for BPF targets (#105708) breaks the build of core library.
The failure occurs both when building rustc for BPF targets and when
building crates for BPF targets with the current nightly.
The LLVM BPF backend does not correctly lower all `atomicrmw` operations
and crashes for unsupported ones.
Before we can enable CAS for BPF in Rust, we need to fix the LLVM BPF
backend first.
Fixes#106795
Signed-off-by: Michal Rostecki <vadorovsky@gmail.com>
Use GitHub yaml templates for ICE, Docs and Diagnostics tickets
The GitHub yaml templates allow us to define HTML forms with validation for issue templates, instead of the current markdown based templates which only let us introduce text into the user editable text area. The form lets us make some fields mandatory, as well as add text that won't pollute the user's text and titles that won't be interfered with by enterprising users.
Emit a hint for bad call return types due to generic arguments
When the return type of a function call depends on the type of an argument, e.g.
```
fn foo<T>(x: T) -> T {
x
}
```
and the expected type is set due to either an explicitly typed binding, or because the call to the function is in a tail position without semicolon, the current error implies that the argument in the call has the wrong type.
This new hint highlights that the expected type doesn't match the returned type, which matches the argument type, and that that's why we're flagging the argument type.
Fixes#43608.
Add note when `FnPtr` vs. `FnDef` impl trait
I encountered an instance where an `FnPtr` implemented a trait, but I was passing an `FnDef`. I was confused for an hour and to examine the source code of the trait's crate's tests in order to understand how to cast it properly (it didn't help that it was behind a reference). To the end user, it might not be immediately obvious that they are different and how to convert from an `FnDef` to an `FnPtr`, but it is necessary to cast to the generic function in order to compile. It is thus useful to suggest `as` in the help note, (even if the `Fn` output implements the trait).
Update the wasi-libc used for the wasm32-wasi target
This commit updates the wasi-libc revision used to build with the wasm32-wasi target. This notably pulls in WebAssembly/wasi-libc#377 which is needed to fix a use case I've been working on recently. This should be a relatively small update hopefully and is not expected to have any user impact.
Emit a single error for contiguous sequences of unknown tokens
Closes#106101
On encountering a sequence of identical source characters which are unknown tokens, note the amount of subsequent characters and advance past them silently. The old behavior was to emit an error and 'help' note for every single one.
`@rustbot` label +A-diagnostics +A-parser
tidy: Don't include wasm32 in compiler dependency check
This changes the tidy compiler dependency check so that it does not include wasm32-unknown-unknown dependencies in the PERMITTED_RUSTC_DEPENDENCIES. This just helps keep the list cleaner under the assumption that the compiler will never work on wasm32-unknown-unknown.
This also fixes a bug in the check to verify there are no unused dependencies in the PERMITTED_RUSTC_DEPENDENCIES. Previously the check was verifying that the dependency was used *anywhere* in the workspace, when it should have been checking if it was used for the compiler.
There's also just a little general cleanup here. For example, the old `normal_deps_of_r` function was changed a while ago to return *all* dependencies, but the function name and description wasn't updated to remove `normal_`.
Fix mir-opt tests for big-endian platforms
The test cases src/test/mir-opt/building/custom/consts.rs and src/test/mir-opt/const_prop/mutable_variable_no_prop.rs are currently failing on big-endian platforms as the binary encoding of some constants is hard-coded in the MIR test files. Fix this by choosing constant values that have the same encoding on big- and little-endian platforms.
The test case src/test/mir-opt/issues/issue_75439.rs is failing as well, but since the purpose of the test is to validate handling of big-endian integer encodings on a little-endian platform, it does not make much sense to run it on big-endian platforms in the first place - we can just ignore it there.
Fixed part of https://github.com/rust-lang/rust/issues/105383.
