Mark wrapped intrinsics as inline(always)
This should mitigate having the inliner decide not to inline when the architecture is lacking an implementation of
TargetTransformInfo::areInlineCompatible aware of the target features (e.g. PowerPC as today).
See https://github.com/rust-lang/stdarch/pull/1443#issuecomment-1613788080
Rollup of 8 pull requests
Successful merges:
- #113072 (str docs: remove "Basic usage" text where not useful)
- #113153 (make HashMap::or_insert_with example more simple)
- #113185 (Set `channel = nightly` in dist profile)
- #113186 (document that the panic in collect_intra_doc_links is load-bearing)
- #113187 (No need to distinguish `LocalTy` from `Ty`)
- #113189 (compiletest: Only trim the end of process output)
- #113191 (Update browser-ui-test version and improve GUI test)
- #113206 (User may want to skip tidy check sometimes)
r? `@ghost`
`@rustbot` modify labels: rollup
compiletest: Only trim the end of process output
As of #94196, compiletest automatically trims process stderr/stdout output before printing it, to make failure info more compact.
This causes the first line of `run-coverage` output to be displayed incorrectly, because it uses leading whitespace to align line numbers.
Trimming only the end of the output string should still have the intended effect (e.g. removing trailing newlines), without causing problems for output that deliberately uses leading whitespace on the first line.
## Before
```
--- stdout -------------------------------
1| 1|fn main() { //
2| 1| let num = 9;
3| 1| while num >= 10 {
4| 0| }
5| 1|}
------------------------------------------
stderr: none
```
## After
```
--- stdout -------------------------------
1| 1|fn main() { //
2| 1| let num = 9;
3| 1| while num >= 10 {
4| 0| }
5| 1|}
------------------------------------------
stderr: none
```
No need to distinguish `LocalTy` from `Ty`
I think the distinction between `decl_ty` and `revealed_ty` was from when you were allowed to put `impl Trait` in let bindings... I don't think we need that anymore, and it makes typeck that much more confusing 😆
Side-note: I don't know why we store this in a separate field [`locals`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir_typeck/struct.Inherited.html#structfield.locals) in `Inherited`, rather than just the `TypeckResults`... Might look into changing that next.
Set `channel = nightly` in dist profile
This avoids some channel-specific defaults leaking into local installs. It also makes it easier to set options for compiler/library/codegen profiles in the future, since they can be gated off `channel` instead of being duplicated between all three files.
Here are the exact things `channel` controls today:
68d458bb40/src/bootstrap/llvm.rs (L466-L470)85c4ea0138/src/bootstrap/config.rs (L1374-L1375)85c4ea0138/src/bootstrap/config.rs (L1464-L1465)
``@cuviper`` i expect you don't want any of those to be set in distro builds, right?
Fix loading target specs in compiletest not working with custom targets
In https://github.com/rust-lang/rust/pull/112454#issuecomment-1611351168 it was pointed out that the PR broke blessing mir-opt tests. Since #112418, blessing mir-opt tests generates "synthetic targets", which are custom target specs. Those specs are not included in `--print=all-target-specs-json`, and #112454 required that the current target was returned by that flag.
This PR fixes the breakage by loading the target spec for the current target explicitly, if a custom target is detected.
r? `@oli-obk`
This should mitigate having the inliner decide not to inline when
the architecture is lacking an implementation of
TargetTransformInfo::areInlineCompatible aware of the target
features (e.g. PowerPC as today).
Fix unset e_flags in ELF files generated for AVR targets
Closes#106576
~~Sort-of blocked by gimli-rs/object#500~~ (merged)
I'm not sure whether the list of AVR CPU names is okay here. Maybe it could be moved out-of-line to improve the readability of the function.
Use structured suggestion when telling user about `for<'a>`
```
error[E0637]: `&` without an explicit lifetime name cannot be used here
--> $DIR/E0637.rs:13:13
|
LL | T: Into<&u32>,
| ^ explicit lifetime name needed here
|
help: consider introducing a higher-ranked lifetime here
|
LL | T: for<'a> Into<&'a u32>,
| +++++++ ++
```
Encode item bounds for `DefKind::ImplTraitPlaceholder`
This was lost in a refactoring -- `hir::ItemKind::OpaqueTy` doesn't always map to `DefKind::Opaque`, specifically for RPITITs, so the check was migrated subtly wrong, and unfortunately I never had a test for this 🙃Fixes#113155
r? ``@cjgillot``
Account for late-bound vars from parent arg-position impl trait
We should be reporting an error like we do for late-bound args coming from a parent APIT.
Fixes#113016
suggest `slice::swap` for `mem::swap(&mut x[0], &mut x[1])` borrowck error
Recently saw someone ask why this code (example slightly modified):
```rs
fn main() {
let mut foo = [1, 2];
std::mem::swap(&mut foo[0], &mut foo[1]);
}
```
triggers this error and how to fix it:
```
error[E0499]: cannot borrow `foo[_]` as mutable more than once at a time
--> src/main.rs:4:33
|
4 | std::mem::swap(&mut foo[0], &mut foo[1]);
| -------------- ----------- ^^^^^^^^^^^ second mutable borrow occurs here
| | |
| | first mutable borrow occurs here
| first borrow later used by call
|
= help: consider using `.split_at_mut(position)` or similar method to obtain two mutable non-overlapping sub-slices
```
The current help message is nice and goes in the right direction, but I think we can do better for this specific instance and suggest `slice::swap`, which makes this compile
Stabilize `const_cstr_methods`
This PR seeks to stabilize `const_cstr_methods`. Fixes most of #101719
## New const stable API
```rust
impl CStr {
// depends: memchr
pub const fn from_bytes_with_nul(bytes: &[u8]) -> Result<&Self, FromBytesWithNulError> {...}
// depends: const_slice_index
pub const fn to_bytes(&self) -> &[u8] {}
// depends: pointer casts
pub const fn to_bytes_with_nul(&self) -> &[u8] {}
// depends: str::from_utf8
pub const fn to_str(&self) -> Result<&str, str::Utf8Error> {}
}
```
I don't think any of these methods will have any issue when `CStr` becomes a thin pointer as long as `memchr` is const (which also allows for const `strlen`) .
## Notes
- `from_bytes_until_nul` relies on `const_slice_index`, which relies on `const_trait_impls`, and generally this should be avoided. After talking with Oli, it should be OK in this case because we could replace the ranges with pointer tricks if needed (worst case being those feature gates disappear). https://github.com/rust-lang/rust/pull/107624#discussion_r1101468480
- Making `from_ptr` const is deferred because it depends on `const_eval_select`. I have moved this under the new flag `const_cstr_from_ptr` https://github.com/rust-lang/rust/pull/107624#discussion_r1101555239
cc ``@oli-obk`` I think you're the const expert
``@rustbot`` modify labels: +T-libs-api +needs-fcp
```
error[E0637]: `&` without an explicit lifetime name cannot be used here
--> $DIR/E0637.rs:13:13
|
LL | T: Into<&u32>,
| ^ explicit lifetime name needed here
|
help: consider introducing a higher-ranked lifetime here
|
LL | T: for<'a> Into<&'a u32>,
| +++++++ ++
```
Normalize opaques with late-bound vars again
We have a hack in the compiler where if an opaque has escaping late-bound vars, we skip revealing it even though we *could* reveal it from a technical perspective. First of all, this is weird, since we really should be revealing all opaques in `Reveal::All` mode. Second of all, it causes subtle bugs (linked below).
I attempted to fix this in #100980, which was unfortunately reverted due to perf regressions on codebases that used really deeply nested futures in some interesting ways. The worst of which was #103423, which caused the project to hang on build. Another one was #104842, which was just a slow-down, but not a hang. I took some time afterwards to investigate how to rework `normalize_erasing_regions` to take advantage of better caching, but that effort kinda fizzled out (#104133).
However, recently, I was made aware of more bugs whose root cause is not revealing opaques during codegen. That made me want to fix this again -- in the process, interestingly, I took the the minimized example from https://github.com/rust-lang/rust/issues/103423#issuecomment-1292947043, and it doesn't seem to hang any more...
Thinking about this harder, there have been some changes to the way we lower and typecheck async futures that may have reduced the pathologically large number of outlives obligations (see description of #103423) that we were encountering when normalizing opaques with bound vars the last time around:
* #104321 (lower `async { .. }` directly as a generator that implements `Future`, removing the `from_generator` shim)
* #104833 (removing an `identity_future` fn that was wrapping desugared future generators)
... so given that I can see:
* No significant regression on rust perf bot (https://github.com/rust-lang/rust/pull/107620#issuecomment-1600070317)
* No timeouts in crater run I did (https://github.com/rust-lang/rust/pull/107620#issuecomment-1605428952, rechecked failing crates in https://github.com/rust-lang/rust/pull/107620#issuecomment-1605973434)
... and given that this PR:
* Fixes#104601
* Fixes#107557
* Fixes#109464
* Allows us to remove a `DefiningAnchor::Bubble` from codegen (75a8f68183)
I'm inclined to give this another shot at landing this. Best case, it just works -- worst case, we get more examples to study how we need to improve the compiler to make this work.
r? types
Make the `Elaboratable` trait take clauses
We only ever elaborate clauses, so make this explicit in the trait's definition rather than having a bunch of `.expect_clause()` calls everywhere.
