Cleanup `debuginfo_compression` unstable flag
It isn't necessary to declare the option as a top-level flag when it is accessible from `unstable_opts`.
cc rust-lang/rust#120953
Document `panic!` in `Iterator::last` for #149707
This PR adds a section `# Panics` to the method `Iterator::last` equal to the section `# Panics` of the method `Iterator::count`, because now, after the changes made in Rust 1.92.0, both methods in `std::iter::Repeat` panics instead of doing an infinite loop.
`Iterator::count` already has documentation for this behavior ("This function might panic if the iterator has more than `usize::MAX` elements."), but `Iterator::last` does not. This PR adds documentation for this panic in the same way as `Iterator::count` does.
Issue: rust-lang/rust#149707
resolve: Preserve binding scopes in ambiguity errors
It allows to get rid of `AmbiguityErrorMisc`, `Flags` and `extern_prelude_flag_binding`.
Also keep all encountered bindings in `resolve_ident_in_scope_set`, it allows to get rid of `extern_prelude_item_binding`.
This also unblocks https://github.com/rust-lang/rust/pull/149681 because the newly preserved data will help to fix the regressions in https://github.com/rust-lang/rust/pull/149681#issuecomment-3679059703 in a reasonable way.
Make `asm_experimental_arch` work in `allow_internal_unstable` macros
This change makes it possible to use unstable `asm!`, usually requiring `feature(asm_experimental_arch)`, in proc-macros with the `allow_internal_unstable` attribute.
The test was added on a target where `asm!` is unstable: Wasm. However, this affects *any* target with an unstable `asm!` implementation.
Added a `# Panics` section to `Iterator::last` to match `Iterator::count`, after the change made in Rust 1.92.0 where now `std::iter::Repeat` panics in these methods instead of doing an infinite `loop`.
Cites https://github.com/rust-lang/rust/issues/149707
Use more principled check for generics in const ops
Fixesrust-lang/rust#144547.
Fixesrust-lang/rust#140891.
In the future, we likely want to make the check less likely to be missed by reducing the number of external entry points to HIR type lowering.
Note: If this causes pass->error regressions (not truly regressions because those cases were mistakenly accepted), they can easily be avoided for the time being by only running the check if `is_self_alias` is true or mgca is enabled.
- **Fix parsing of mgca const blocks in array repeat exprs**
- **Use more principled check for generics in const ops**
Instead of using a visitor in typeck, we just check, whenever lowering a
use of a param, whether the parent item is an MCG anon const during hir
ty lowering (and instantiate_value_path). If so, we report an error
since MCG anon consts should never be able to use generics. All other
kinds of anon consts are at least syntactically allowed to use generic
params.
We use a `TypeFolder` to accomplish this; this way, we look at the
fully explicit semantic representation of the type/const/whatever and
don't miss subtle cases like `Self` type aliases.
Update triagebot config for `compiler-errors`, `tests/{run-make,run-make-cargo}` and `fallback` adhoc_group
- Commit 1: Updates triagebot entries for `compiler-errors` (context: https://github.com/rust-lang/team/pull/2205)
- Commit 2: Expand `tests/{run-make,run-make-cargo}` reviewer pool to the `compiler` `adhoc_group` instead of just me for weighting reasons, so I don't become the sole assigned reviewer even when I'm off rotation.
- Commit 3: Add myself to `fallback` adhoc_group so there's `n > 1` pool there, in case one of the reviewers go off rotation.
Add regression test for issue #99173Closerust-lang/rust#99173.
Adds a regression test for rust-lang/rust#99173, which was an ICE that occurred when a proc-macro generated code that invoked another proc-macro returning an empty `TokenStream`.
test and document that `proc_macro::Ident` is NFC-normalized
Previously, this was not tested at all and the test suite would pass even when replacing the `normalize_and_validate_ident` implementation with a `panic!`.
cleanup: move c-variadic arguments handling into compute_inputs_and_output
Previously, ``unnormalized_input_tys`` needs to be mutable because the c_variadic arguments are added to ``unnormalized_input_tys`` outside of ``compute_inputs_and_output``. This could have been done together in ``compute_inputs_and_output``.
Enable thumb interworking on ARMv7A/R and ARMv8R bare-metal targets
This flag enables the `#[instruction_set(arm::t32)]` for the armv7a/armv7r/armv8r targets, which all support Thumb interwork but were missing this flag.
Target maintainers are `@chrisnc,` `@rust-lang/arm-maintainers,` `@rust-embedded/arm` (including me).
`crate::io::Result` → `io::Result` in most places
I don't know why many places refer to the type as `crate::io::Result` when `crate::io` is already imported.
fix(bootstrap/dist)!: change dist path for `rustc-docs` to avoid clashing
Closesrust-lang/rust#75833, part of https://github.com/rust-lang/rustup/issues/3717:
> I'd like to know if we can assign another folder name to `rustc-docs`?
> [...]
> [`@ThePuzzlemaker](https://github.com/ThePuzzlemaker)'s` `share/doc/rust/html/nightly-rustc` does look a bit weird to me (`nightly-rustc` has nothing to do with the current `rustc`, i.e. the Rustc Book, but they somehow appear similar just looking at the names).
>
> I personally would like to see something like `share/doc/rust/html/rustc-docs` or `share/doc/rust/html/rustc-api` for this component.
_https://github.com/rust-lang/rust/issues/75833#issuecomment-2002503223_
The TLDR is that currently the "rustc book"'s path clashes with "rustc APIs" (i.e. `rustc-docs`), so we change the path of the latter to make it distributable via rustup.
I'm new to `bootstrap` so please feel free to point out any inconsistencies or any extra work I'll need to do to fully land this somewhat breaking change.
Remove `feature(string_deref_patterns)`
The older `string_deref_patterns` feature has been superseded by the newer and more general `deref_patterns` feature. Removing string-deref-patterns allows us to get rid of a few tricky special cases in match lowering, which are different from the special cases used by deref-patterns.
The handful of existing tests for `string_deref_patterns` have been migrated to use `deref_patterns` instead. Current nightly users of the older feature should hopefully be able to migrate to the newer feature without too much trouble.
Note that `deref_patterns` is currently marked as an “incomplete” feature, because it doesn't have an accepted RFC. But `string_deref_patterns` doesn't appear to have ever had an accepted RFC either, so arguably it should have been marked incomplete too.
---
- Tracking issue for both features: https://github.com/rust-lang/rust/issues/87121
- Original implementation: https://github.com/rust-lang/rust/pull/98914
- [Zulip thread: Can we remove `#![feature(string_deref_patterns)]`?](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Can.20we.20remove.20.60.23!.5Bfeature.28string_deref_patterns.29.5D.60.3F/with/565787352)
RISC-V: Implement (Zkne or Zknd) intrinsics correctly
On rust-lang/stdarch#1765, it has been pointed out that two RISC-V (64-bit only) intrinsics to perform AES key scheduling have wrong target feature.
`aes64ks1i` and `aes64ks2` instructions require *either* Zkne (scalar cryptography: AES encryption) or Zknd (scalar cryptography: AES decryption) extension (or both) but corresponding Rust intrinsics (in `core::arch::riscv64`) required *both* Zkne and Zknd extensions.
An excerpt from the original intrinsics:
```rust
#[target_feature(enable = "zkne", enable = "zknd")]
```
To fix that, we need to:
1. Represent a condition where *either* Zkne or Zknd is available and
2. Workaround an issue: `llvm.riscv.aes64ks1i` / `llvm.riscv.aes64ks2` LLVM intrinsics require either Zkne or Zknd extension.
This PR attempts to resolve them by:
1. Adding a perma-unstable RISC-V target feature: `zkne_or_zknd` (implied from both `zkne` and `zknd`) and
2. Using inline assembly to construct machine code directly (because `zkne_or_zknd` alone cannot imply neither Zkne nor Zknd, we cannot use LLVM intrinsics).
The author confirmed that we can construct an AES key scheduling function with decent performance using fixed `aes64ks1i` and `aes64ks2` intrinsics (with optimization enabled).
Corretly link URL in internal Windows docs
```
warning: this URL is not a hyperlink
--> library/std/src/sys/pal/windows/mod.rs:337:5
|
337 | /// https://docs.microsoft.com/en-us/cpp/intrinsics/fastfail
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: bare URLs are not automatically turned into clickable links
= note: `#[warn(rustdoc::bare_urls)]` on by default
help: use an automatic link instead
|
337 | /// <https://docs.microsoft.com/en-us/cpp/intrinsics/fastfail>
| + +
```
Allow inline calls to offload intrinsic
Removes explicit insertion point handling and recovers the pointer at the end of the saved basic block.
r? `@ZuseZ4`
fixes: https://github.com/rust-lang/rust/issues/150413
joboet