Constify `[u8]::is_ascii` (unstably)
UTF-8 checking in `const fn`-stabilized back in 1.63 (#97367), but apparently somehow ASCII checking was never const-ified, despite being simpler.
New constness-tracking issue for `is_ascii`: #111090
I noticed this working on `ascii::Char`: #110998
Support return-type bounds on associated methods from supertraits
Support `T: Trait<method(): Bound>` when `method` comes from a supertrait, aligning it with the behavior of associated type bounds (both equality and trait bounds).
The only wrinkle is that I have to extend `super_predicates_that_define_assoc_type` to look for *all* items, not just `AssocKind::Ty`. This will also be needed to support `feature(associated_const_equality)` as well, which is subtly broken when it comes to supertraits, though this PR does not fix those yet. There's a slight chance there's a perf regression here, in which case I guess I could split it out into a separate query.
This function/lang_item was introduced in #104321 as a temporary workaround of future lowering.
The usage and need for it went away in #104833.
After a bootstrap update, the function itself can be removed from `std`.
Rollup of 7 pull requests
Successful merges:
- #105583 (Operand::extract_field: only cast llval if it's a pointer and replace bitcast w/ pointercast.)
- #110094 (clean up `transmute`s in `core`)
- #111150 (added TraitAlias to check_item() for missing_docs)
- #111293 (rustc --explain E0726 - grammar fixing (it's => its + add a `the` where it felt right to do so))
- #111300 (Emit while_true lint spanning the entire loop condition)
- #111301 (Remove calls to `mem::forget` and `mem::replace` in `Option::get_or_insert_with`.)
- #111303 (update Rust Unstable Book docs for `--extern force`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Remove calls to `mem::forget` and `mem::replace` in `Option::get_or_insert_with`.
This removes the unneeded calls to `mem::forget` and `mem::replace` in `Option::get_or_insert_with`.
Emit while_true lint spanning the entire loop condition
The lint that suggests `loop {}` instead of `while true {}` has functionality to 'pierce' parenthesis in cases like `while (true) {}`. In these cases, the emitted span only went to the hi of the `true` itself, not spanning the entire loop condition.
Before:
```
warning: denote infinite loops with `loop { ... }`
--> /tmp/foobar.rs:2:5
|
2 | while ((((((true)))))) {}
| ^^^^^^^^^^^^^^^^ help: use `loop`
|
= note: `#[warn(while_true)]` on by default
```
After:
```
warning: denote infinite loops with `loop { ... }`
--> /tmp/foobar.rs:2:5
|
2 | while ((((((true)))))) {}
| ^^^^^^^^^^^^^^^^^^^^^^ help: use `loop`
|
= note: `#[warn(while_true)]` on by default
```
This is especially a problem for rustfix.
added TraitAlias to check_item() for missing_docs
As in issue #111025 the `missing_docs` was not being triggered for trait aliases. I added `TraitAlias` to the pattern match for check_item(), and the lint seems to be behaving appropriately
clean up `transmute`s in `core`
* Use `transmute_unchecked` instead of `transmute_copy` for `MaybeUninit::transpose`.
* Use manual transmute for `Option<Ordering>` → `i8`.
Operand::extract_field: only cast llval if it's a pointer and replace bitcast w/ pointercast.
Fixes#105439.
Also cc `@erikdesjardins,` looks like another place to cleanup as part of #105545
Migrate bootstrap to Clap-based argument parsing
Supercedes #108083
I chose to re-do the work rather than rebase the onto the large changes since the original PR. If it's preferred I can instead force-push the original PR to this version.
cc `@jyn514` `@albertlarsan68`
Expand the LLVM coverage of `--print target-cpus`
We've been relying on a custom patch to add `MCSubtargetInfo::getCPUTable`
for `rustc --print target-cpus`, and just printing that it's not supported
on external LLVM builds. LLVM `main` now has `getAllProcessorDescriptions`
that can replace ours, so now we try to use that. In addition, the fallback
path can at least print the native and default cpu options.
There were also some mismatches in the function signatures here between
`LLVM_RUSTLLVM` and otherwise; this is now mitigated by sharing these
functions and only using cpp to adjust the function bodies.
Output LLVM optimization remark kind in `-Cremark` output
Since https://github.com/rust-lang/rust/pull/90833, the optimization remark kind has not been printed. Therefore it wasn't possible to easily determine from the log (in a programmatic way) which remark kind was produced. I think that the most interesting remarks are the missed ones, which can lead users to some code optimization.
Maybe we could also change the format closer to the "old" one:
```
note: optimization remark for tailcallelim at /checkout/src/libcore/num/mod.rs:1:0: marked this call a tail call candidate
```
I wanted to programatically parse the remarks so that they could work e.g. with https://github.com/OfekShilon/optview2. However, now that I think about it, probably the proper solution is to tell rustc to output them to YAML and then use the YAML as input for the opt remark visualization tools. The flag for enabling this does not seem to work though (https://github.com/rust-lang/rust/issues/96705#issuecomment-1117632322).
Still I think that it's good to output the remark kind anyway, it's an important piece of information.
r? ```@tmiasko```
Fix the test directories suggested by `./x.py suggest`
It seems that these paths were correct when #106249 was being written, but since then #106458 has been merged (moving `src/test/` to `tests/`), making the tool's suggestions incorrect.
Remove aws cli install.
All runner images have the AWS CLI 2 installed, so there isn't a really strong reason to install our own version anymore.
The version we were installing was 1.27.122. The runner images currently have 2.11.x (the exact version varies by image).
I do not have the means to really test if the new version has any issues. I looked at all the `aws` commands, and none of them seem to be doing anything unusual. The page at https://docs.aws.amazon.com/cli/latest/userguide/cliv2-migration-changes.html contains a list of all the breaking changes, and I didn't see anything that looked important.
The lint that suggests `loop {}` instead of `while true {}` has functionality to 'pierce' parenthesis
in cases like `while (true) {}`. In these cases, the emitted span only went to the hi of the `true`
itself, not spanning the entire loop condition.
Before:
```
warning: denote infinite loops with `loop { ... }`
--> /tmp/foobar.rs:2:5
|
2 | while ((((((true)))))) {}
| ^^^^^^^^^^^^^^^^ help: use `loop`
|
= note: `#[warn(while_true)]` on by default
```
After:
```
warning: denote infinite loops with `loop { ... }`
--> /tmp/foobar.rs:2:5
|
2 | while ((((((true)))))) {}
| ^^^^^^^^^^^^^^^^^^^^^^ help: use `loop`
|
= note: `#[warn(while_true)]` on by default
```
