This fixes the issue wherein the lint didn't fire for promoteds
in the case of SHL/SHR operators in non-optimized builds
and all arithmetic operators in optimized builds
Make `io::BorrowedCursor::advance` safe
This also keeps the old `advance` method under `advance_unchecked` name.
This makes pattern like `std::io::default_read_buf` safe to write.
Now that Win 7 support is dropped, we can resurrect #90144.
GetCurrentProcessToken is defined in processthreadsapi.h as:
FORCEINLINE
HANDLE
GetCurrentProcessToken (
VOID
)
{
return (HANDLE)(LONG_PTR) -4;
}
Since it's very unlikely that this constant will ever change, let's just use it instead of making calls to get the same information.
Migrate ui tests from legacy compiletest-style directives `//` to `ui_test`-style directives `//@`
## Preface
There's an on-going effort to rewrite parts of or the entirety of compiletest
(<https://github.com/rust-lang/compiler-team/issues/536>). A step towards this involve migrating
ui tests to use the [`ui_test`](https://github.com/oli-obk/ui_test) framework, which involves
changing compiletest directives in `// <directive-name>` style to `ui_test` `//@ <directive-name>`
style (https://github.com/rust-lang/compiler-team/issues/512).
This PR aims to implement the directive-style change from `//` to `//`@`` for ui tests only and
make compiletest only accept `//`@`` directives in the "ui" test suite (only).
## Key Changes
1. All ui test `//` directives are replaced by `//`@`` directives.
2. Only accept `//`@`` directives for "ui" test suite.
3. Errors if a comment could be interpreted as a legacy-style `//` directive.
## Diff Generation
The diff is generated by:
- Collecting directives from ui tests via hacking on compiletest.
- Using a migration tool to replace `//` directives in ui tests with `//`@`.`
### Reproduction Steps
0. Delete the temporary directory `$RUSTC_REPO_PATH/build/x86_64-apple-darwin/test/ui/__directive_lines` and the temporary file `$RUSTC_REPO_PATH/build/x86_64-apple-darwin/test/ui/__directive_lines.txt` (if you ran the collection script before).
1. Use the <https://github.com/jieyouxu/rust/tree/collect-test-directives> collect-test-directives
script, which outputs temporary files recording headers occuring in each ui test.
- You need to checkout this branch: `git checkout collect-test-directives`.
- You might need to rebase on lastest master and ensure there are no conflicts.
- You likely need to run `./x test tests/ui --stage 1 --force-rerun` to generate the temporary
files consistently.
2. Checkout the `migrate-ui-test-directives` branch.
4. Run the migration tool <https://github.com/jieyouxu/compiletest-ui_test-header-migration>.
- You will need to first generate a `migration_config.toml` via `cargo run -- generate-config` under `$CWD`.
- Then, update `manual_directives = ["// should-fail"]` in `migration_config.toml`. This is required because the collection script doesn't deal with some special meta ui tests and there are no other `// should-fail` occurrences.
5. Check that the migration at least does not cause UI test failures if you change compiletest to
accept `//`@`` directives for ui tests only.
- `RUSTC_TEST_FAIL_FAST=1 ./x test tests/ui --stage 1 --bless`
6. Confirm that there is no difference after running the migration tool when you are on the
`migrate-ui-test-directives` branch.
## Next Steps
- [x] ~~Need to implement some kind of warning or tidy script to help contributors catch old-style
`// <directive-name>` directives, while only accepting `ui_test`-style `//@ <directive-name>`
directives.~~ An error is emitted if a comment that could be interpreted as legacy-style test directive is encountered.
- [ ] Need to properly document this change in e.g. rustc-dev-guide (https://github.com/rust-lang/rustc-dev-guide/pull/1885).
- [x] Add a `README.md` to `tests/ui` describing the directive style change.
Support configuring the set of codegen backends to build per host triple
This allows building the compiler itself with one backend while using another backend at runtime. For example this allows compiling rustc to wasm using LLVM, while using Cranelift at runtime to produce actual code. Cranelift can't compile to wasm, but is perfectly capable of running on wasm. LLVM can compile to wasm, but can't run on wasm. [^1]
[^1]: The prototype of this still requires a couple of other patches.
Rollup of 6 pull requests
Successful merges:
- #119928 (suggest `into_iter()` when `Iterator` method called on `impl IntoIterator`)
- #121020 (Avoid an ICE in diagnostics)
- #121111 (For E0038, suggest associated type if available)
- #121137 (Add clippy into the known `cfg` list)
- #121179 (allow mutable references in const values when they point to no memory)
- #121181 (Fix an ICE in the recursion lint)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix an ICE in the recursion lint
fixes#121170
I looked into it, and there is no good path towards tainting mir_build (where the ICE happens), but using `try_normalize` in a lint seems generally better anyway
allow mutable references in const values when they point to no memory
Fixes https://github.com/rust-lang/rust/issues/120450
The second commit is just some drive-by test suite cleanup.
r? `@oli-obk`
Add clippy into the known `cfg` list
In clippy, we are removing the `feature = "cargo-clippy"` cfg to replace it with `clippy` in https://github.com/rust-lang/rust-clippy/pull/12292. But for it to work, we need to declare `clippy` as cfg. It makes it more coherent with other existing tools like rustdoc.
cc `@flip1995`
Avoid an ICE in diagnostics
fixes#121004
just a slice usage in diagnostics code. Sadly we can't yet bubble the `ErrorGuaranteed` from wf check to borrowck for these cases, as that causes cycle errors iirc
Rename MaybeUninit::write_slice
A step to push #79995 forward.
https://github.com/rust-lang/libs-team/issues/122 also suggested to make them inherent methods, but they can't be — they'd conflict with slice's regular methods.
Implement intrinsics with fallback bodies
fixes#93145 (though we can port many more intrinsics)
cc #63585
The way this works is that the backend logic for generating custom code for intrinsics has been made fallible. The only failure path is "this intrinsic is unknown". The `Instance` (that was `InstanceDef::Intrinsic`) then gets converted to `InstanceDef::Item`, which represents the fallback body. A regular function call to that body is then codegenned. This is currently implemented for
* codegen_ssa (so llvm and gcc)
* codegen_cranelift
other backends will need to adjust, but they can just keep doing what they were doing if they prefer (though adding new intrinsics to the compiler will then require them to implement them, instead of getting the fallback body).
cc `@scottmcm` `@WaffleLapkin`
### todo
* [ ] miri support
* [x] default intrinsic name to name of function instead of requiring it to be specified in attribute
* [x] make sure that the bodies are always available (must be collected for metadata)
