Rename InstCombine to InstSimplify
```
╭ ➜ ben@archlinux:~/rust
╰ ➤ rg -i instcombine
src/doc/rustc-dev-guide/src/mir/optimizations.md
134:may have been misapplied. Examples of this are `InstCombine` and `ConstantPropagation`.
src/ci/docker/host-x86_64/disabled/dist-x86_64-haiku/llvm-config.sh
38: instcombine instrumentation interpreter ipo irreader lanai \
tests/codegen/slice_as_from_ptr_range.rs
4:// min-llvm-version: 15.0 (because this is a relatively new instcombine)
```
r? `@scottmcm`
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.
