BTree: consistently avoid unwrap_unchecked in iterators
Some iterator support functions named `_unchecked` internally use `unwrap`, some use `unwrap_unchecked`. This PR tries settling on `unwrap`. #86195 went up the same road but travelled way further and doesn't seem successful.
r? `@Mark-Simulacrum`
Support pretty printing slices using GDB
Support pretty printing `&[T]`, `&mut [T]` and `&mut str` types using GDB.
Support pretty printing `&mut [T]` and `&mut str` types using LLDB.
Fixes#85219.
At least one of these is already in-tree; it seems plausible that
others might appear too.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
remove trailing newline
fix: test with attribute but missing const
Update compiler/rustc_passes/src/stability.rs
Co-authored-by: Léo Lanteri Thauvin <leseulartichaut@gmail.com>
Add test for extern functions
fix: using span_help instead of span_suggestion
add test for some ABIs + fmt fix
Update compiler/rustc_passes/src/stability.rs
Co-authored-by: Léo Lanteri Thauvin <leseulartichaut@gmail.com>
Refractor and add test for `impl const`
Add test to make sure no output + cleanup condition
-----------------------------
remove stdcall test, failing CI test
C abi is already tested in this, so it is not that useful to test another one.
The tested code is blind to which specific ABI for now, as long as it's not an intrinsic one
Revert "Add "every" as a doc alias for "all"."
This reverts commit 35450365ac (#81697) for "every" and closes#86554 in kind for "some".
The new [doc alias policy](https://std-dev-guide.rust-lang.org/documentation/doc-alias-policy.html) is that we don't want language-specific aliases like these JavaScript names, and we especially don't want to conflict with real names. While "every" is okay in the latter regard, its natural pair "some" makes a doc-search collision with `Option::Some`.
r? ```@m-ou-se```
Clean up rustdoc static files
The `html/static` of rustdoc was starting to be quite a mess... So I moved files in sub-folders to make it easier to follow. Here what remains in `html/static` folder:
```
$ ls
COPYRIGHT.txt css fonts images js LICENSE-APACHE.txt LICENSE-MIT.txt
```
cc ```@jyn514```
r? ```@Manishearth```
Fix ICE when misplaced visibility cannot be properly parsed
Fixes#86895
The issue was that a failure to parse the visibility was causing the original error to be dropped before being emitted.
The resulting error isn't quite as nice as when the visibility is parsed properly, but I'm not sure which error to prioritize here. Displaying both errors might be too confusing.
r? ```@estebank```
Sync rustc_codegen_cranelift
The main hightlight this sync is basic support for AArch64. Most things should work on Linux, but there does seem to be an ABI incompatibility causing proc-macros to crash, see https://github.com/bjorn3/rustc_codegen_cranelift/issues/1184. Thanks to ```@afonso360``` for implementing all Cranelift features that were necessary to compile for AArch64 using cg_clif. Also thanks to ```@shamatar``` for implementing the `llvm.x86.addcarry.64` and `llvm.x86.subborrow.64` llvm intrinsics used by num-bigint (https://github.com/bjorn3/rustc_codegen_cranelift/pull/1178) and ```@eggyal``` for implementing multi-threading support for the lazy jit mode. (https://github.com/bjorn3/rustc_codegen_cranelift/pull/1166)
r? ```@ghost```
```@rustbot``` label +A-codegen +A-cranelift +T-compiler
Recover from `&dyn mut ...` parse errors
Consider this example:
```rust
fn main() {
let r: &dyn mut Trait;
}
```
This currently leads to:
```
error: expected one of `!`, `(`, `;`, `=`, `?`, `for`, lifetime, or path, found keyword `mut`
--> src/main.rs:2:17
|
2 | let r: &dyn mut Trait;
| ^^^ expected one of 8 possible tokens
error: aborting due to previous error
```
However, especially for beginners, I think it is easy to get `&dyn mut` and `&mut dyn` confused. With my changes, I get a help message, and the parser even recovers:
```
error: `mut` must precede `dyn`
--> test.rs:2:12
|
2 | let r: &dyn mut Trait;
| ^^^^^^^^ help: place `mut` before `dyn`: `&mut dyn`
error[E0405]: cannot find trait `Trait` in this scope
--> test.rs:2:21
|
2 | let r: &dyn mut Trait;
| ^^^^^ not found in this scope
error: aborting due to 2 previous errors
```
Support lint tool names in rustc command line options
When rustc is running without a lint tool such as clippy enabled, options for lints such as `clippy::foo` are meant to be ignored. This was already working for those specified by attrs, such as `#![allow(clippy::foo)]`, but this did not work for command line arguments like `-A clippy::foo`. This PR fixes that issue.
Note that we discovered this issue while discussing https://github.com/rust-lang/cargo/issues/5034.
Fixes#86628.
This change merges `check_lint_and_tool_name` into `check_lint_name` in
order to avoid having two very similar functions.
Also adds the `.stderr` file back for the test case, since apparently
it is still needed.
All eabi targets have target_abi = "eabi".
All eabihf targets have target_abi = "eabihf".
armv6_unknown_freebsd and armv7_unknown_freebsd have target_abi = "eabihf".
All abi64 targets have target_abi = "abi64".
All ilp32 targets have target_abi = "ilp32".
All softfloat targets have target_abi = "softfloat".
All *-uwp-windows-* targets have target_abi = "uwp".
All spe targets have target_abi = "spe".
All macabi targets have target_abi = "macabi".
aarch64-apple-ios-sim has target_abi = "sim".
x86_64-fortanix-unknown-sgx has target_abi = "fortanix".
x86_64-unknown-linux-gnux32 has target_abi = "x32".
Add FIXME entries for targets for which existing values need to change
once cfg_target_abi becomes stable. (All of them are tier 3 targets.)
Add a test for target_abi in `--print cfg`.
Add an `abi` field to `TargetOptions`, defaulting to "". Support using
`cfg(target_abi = "...")` for conditional compilation on that field.
Gated by `feature(cfg_target_abi)`.
Add a test for `target_abi`, and a test for the feature gate.
Add `target_abi` to tidy as a platform-specific cfg.
This does not add an abi to any existing target.
