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?
linker flavors
- only the stable values for `-Clink-self-contained` can be used on stable until we
have more feedback on the interface
- `-Zunstable-options` is required to use unstable linker flavors
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.
