[ACP 362] genericize `ptr::from_raw_parts`
This implements https://github.com/rust-lang/libs-team/issues/362
As such, it can partially undo https://github.com/rust-lang/rust/pull/124795 , letting `slice_from_raw_parts` just call `from_raw_parts` again without re-introducing the unnecessary cast to MIR.
By doing this it also removes a spurious cast from `str::from_raw_parts`. And I think it does a good job of showing the value of the ACP, since the only thing that needed new turbofishing because of this is inside `ptr::null(_mut)`, but only because `ptr::without_provenance(_mut)` doesn't support pointers to extern types, which it absolutely could (without even changing the implementation).
Rollup of 7 pull requests
Successful merges:
- #124655 (Add `-Zfixed-x18`)
- #125693 (Format all source files in `tests/coverage/`)
- #125700 (coverage: Avoid overflow when the MC/DC condition limit is exceeded)
- #125705 (Reintroduce name resolution check for trying to access locals from an inline const)
- #125708 (tier 3 target policy: clarify the point about producing assembly)
- #125715 (remove unneeded extern crate in rmake test)
- #125719 (Extract coverage-specific code out of `compiletest::runtest`)
r? `@ghost`
`@rustbot` modify labels: rollup
Reintroduce name resolution check for trying to access locals from an inline const
fixes#125676
I removed this without replacement in https://github.com/rust-lang/rust/pull/124650 without considering the consequences
coverage: Avoid overflow when the MC/DC condition limit is exceeded
Fix for the test failure seen in https://github.com/rust-lang/rust/pull/124571#issuecomment-2099620869.
If we perform this subtraction first, it can sometimes overflow to -1 before the addition can bring its value back to 0.
That behaviour seems to be benign, but it nevertheless causes test failures in compiler configurations that check for overflow.
``@rustbot`` label +A-code-coverage
Format all source files in `tests/coverage/`
Currently we can't automatically enforce formatting on tests (see #125637), but we can at least keep things relatively tidy by occasionally running the formatter manually.
This was done by temporarily commenting out the `"/tests/"` exclusion in `rustfmt.toml`, and then running:
- `x fmt tests/coverage`
- `x test coverage --bless`
(This PR also includes a few cosmetic tweaks to some of the affected files, to convince rustfmt to format them in the way we want.)
``@rustbot`` label +A-code-coverage
Use `rmake` for `windows-` run-make tests
Convert some Makefile tests to recipes.
I renamed "issue-85441" to "windows-ws2_32" as I think it's slightly more descriptive. EDIT: `llvm-readobj` seems to work for reading DLL imports so I've used that instead of `objdump`.
cc #121876
Make lint: `lint_dropping_references` `lint_forgetting_copy_types` `lint_forgetting_references` give suggestion if possible.
This is a follow-up PR of #125433. When it's merged, I want change lint `dropping_copy_types` to use the same `Subdiagnostic` struct `UseLetUnderscoreIgnoreSuggestion` which is added in this PR.
Hi, Thank you(`@Urgau` ) again for your help in the previous PR. If your time permits, please also take a look at this one.
r? compiler
<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.
This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using
r? <reviewer name>
-->
don't inhibit random field reordering on repr(packed(1))
`inhibit_struct_field_reordering_opt` being false means we exclude this type from random field shuffling. However, `packed(1)` types can still be shuffled! The logic was added in https://github.com/rust-lang/rust/pull/48528 since it's pointless to reorder fields in packed(1) types (there's no padding that could be saved) -- but that shouldn't inhibit `-Zrandomize-layout` (which did not exist at the time).
We could add an optimization elsewhere to not bother sorting the fields for `repr(packed)` types, but I don't think that's worth the effort.
This *does* change the behavior in that we may now reorder fields of `packed(1)` structs (e.g. if there are niches, we'll try to move them to the start/end, according to `NicheBias`). We were always allowed to do that but so far we didn't. Quoting the [reference](https://doc.rust-lang.org/reference/type-layout.html):
> On their own, align and packed do not provide guarantees about the order of fields in the layout of a struct or the layout of an enum variant, although they may be combined with representations (such as C) which do provide such guarantees.
A small diagnostic improvement for dropping_copy_types
For a value `m` which implements `Copy` trait, `drop(m);` does nothing.
We now suggest user to ignore it by a abstract and general note: `let _ = ...`.
I think we can give a clearer note here: `let _ = m;`
fixes#125189
<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.
This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using
r? <reviewer name>
-->
Currently we can't automatically enforce formatting on tests (see #125637), but
we can at least keep things relatively tidy by occasionally running the
formatter manually.
This was done by temporarily commenting out the `"/tests/"` exclusion in
`rustfmt.toml`, and then running `x fmt tests/coverage` and
`x test coverage --bless`.
For coverage tests, splitting code across multiple lines often makes the
resulting coverage report easier to interpret, so we force rustfmt to retain
line breaks by adding dummy line comments with `//`.
Silence some resolve errors when there have been glob import errors
When encountering `use foo::*;` where `foo` fails to be found, and we later encounter resolution errors, we silence those later errors.
A single case of the above, for an *existing* import on a big codebase would otherwise have a huge number of knock-down spurious errors.
Ideally, instead of a global flag to silence all subsequent resolve errors, we'd want to introduce an unnameable binding in the appropriate rib as a sentinel when there's a failed glob import, so when we encounter a resolve error we can search for that sentinel and if found, and only then, silence that error. The current approach is just a quick proof of concept to iterate over.
Partially address #96799.
Make more of the test suite run on Mac Catalyst
Combined with https://github.com/rust-lang/rust/pull/125225, the only failing parts of the test suite are in `tests/rustdoc-js`, `tests/rustdoc-js-std` and `tests/debuginfo`. Tested with:
```console
./x test --target=aarch64-apple-ios-macabi library/std
./x test --target=aarch64-apple-ios-macabi --skip=tests/rustdoc-js --skip=tests/rustdoc-js-std --skip=tests/debuginfo tests
```
Will probably put up a PR later to enable _running_ on (not just compiling for) Mac Catalyst in CI, though not sure where exactly I should do so? `src/ci/github-actions/jobs.yml`?
Note that I've deliberately _not_ enabled stack overflow handlers on iOS/tvOS/watchOS/visionOS (see https://github.com/rust-lang/rust/issues/25872), but rather just skipped those tests, as it uses quite a few APIs that I'd be weary about getting rejected by the App Store (note that Swift doesn't do it on those platforms either).
r? ``@workingjubilee``
CC ``@thomcc``
``@rustbot`` label O-ios O-apple
Add `--print=check-cfg` to get the expected configs
This PR adds a new `--print` variant `check-cfg` to get the expected configs.
Details and rational can be found on the MCP: https://github.com/rust-lang/compiler-team/issues/743
``@rustbot`` label +F-check-cfg +S-waiting-on-MCP
r? ``@petrochenkov``
