Use a hardcoded constant instead of calling OpenProcessToken.
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.
Make `ConstPropLint` lint run on promoteds
Fixes#117949 wherein the lint didn't fire for the following promoteds:
- SHL or SHR operators in a non-optimized build
- any arithmetic operator in an optimized build
What I have done here is simply enabled `ConstPropLint` to run on promoted bodies by removing the relevant `if` check.
After this change _all_ promoted arithmetic operators will lint _in both non-optimized and optimized builds_. On the flip side programs containing the above mentioned overflowing promoteds that were accepted earlier will now be rejected. Hope that is okay from a backward compatibility standpoint.
I have added tests covering all overflowing promoted & non-promoted ops for both compile-time and runtime operations and for optimized as well as non-optimized builds.
I had to amend some existing tests to make them pass and had to delete a couple that were set to pass despite overflows.
This PR increases the number of duplicate diagnostics emitted (because the same operator might get linted in both the promoted MIR and the main MIR). I hope that is an acceptable trade-off given that we now lint overflows much more comprehensively than earlier.
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)
doc: add note about panicking examples for strict_overflow_ops
The first commit adds a note before the panicking examples for strict_overflow_ops to make it clearer that the following examples should panic and why, without needing the reader to hover the mouse over the information icon.
The second commit adds panicking examples for division by zero operations for strict division operations on unsigned numbers. The signed numbers already have two panicking examples each: one for division by zero and one for overflowing division (`MIN/-1`); this commit includes the division by zero examples for the unsigned numbers.
Only point out non-diverging arms for match suggestions
Fixes#121144
There is no reason to point at diverging arms, which will always coerce to whatever is the match block's evaluated type.
This also removes the suggestion from #106601, since as I pointed out in https://github.com/rust-lang/rust/issues/72634#issuecomment-1946210898 the added suggestion is not firing in the right cases, but instead only when one of the match arms already *actually* evaluates to `()`.
r? estebank
Make `async Fn` trait kind errors better
1. Make it so that async closures with the wrong closurekind actually report a useful error
2. Explain why async closures can sometimes not implement `Fn`/`FnMut` (because they capture things)
r? oli-obk
Add an ErrorGuaranteed to ast::TyKind::Err (attempt 2)
This makes it more like `hir::TyKind::Err`, and avoids a `has_errors` assertion in `LoweringContext::lower_ty_direct`.
r? ```@oli-obk```
Add extra indent spaces for rust-playground link
Fixes#120998
Seems add `rustfmt` for this is somehow too heavy,
only adding indent spaces at the starting of each line of code seems good enough.
Consider principal trait ref's auto-trait super-traits in dyn upcasting
Given traits like:
```rust
trait Subtrait: Supertrait + Send {}
trait Supertrait {}
```
We should be able to upcast `dyn Subtrait` to `dyn Supertrait + Send`. This is not currently possible, because when upcasting, we look at the list of auto traits in the object type (`dyn Subtrait`, which has no auto traits in its bounds) and compare them to the target's auto traits (`dyn Supertrait + Send`, which has `Send` in its bound).
Since the target has auto traits that are not present in the source, the upcasting fails. This is overly restrictive, since `dyn Subtrait` will always implement `Send` via its built-in object impl. I propose to loosen this restriction here.
r? types
---
### ~~Aside: Fix this in astconv instead?~~
### edit: This causes too many failures. See https://github.com/rust-lang/rust/pull/119825#issuecomment-1890847150
We may also fix this by by automatically elaborating all auto-trait supertraits during `AstConv::conv_object_ty_poly_trait_ref`. That is, we can make it so that `dyn Subtrait` is elaborated into the same type of `dyn Subtrait + Send`.
I'm open to considering this solution instead, but it would break coherence in the following example:
```rust
trait Foo: Send {}
trait Bar {}
impl Bar for dyn Foo {}
impl Bar for dyn Foo + Send {}
//~^ This would begin to be an overlapping impl.
```
