interpret: ensure we check bool/char for validity when they are used in a cast
In general, `Scalar::to_bits` is a bit dangerous as it bypasses all type information. We should usually prefer matching on the type and acting according to that. So I also refactored `unary_op` handling of integers to do that. The remaining `to_bits` uses are operations that just fundamentally don't care about the sign (and only work on integers).
invalid_char_cast.rs is the key new test, the others already passed before this PR.
r? `@oli-obk`
Remove ignore-cross-compile directive from ui/macros/proc_macro
All the other proc-macro tests don't have this, presumably this was forgotten when the restriction got lifted as it does test just fine
r? `@pietroalbini`
Rollup of 5 pull requests
Successful merges:
- #125913 (Spruce up the diagnostics of some early lints)
- #126234 (Delegation: fix ICE on late diagnostics)
- #126253 (Simplify assert matchers in `run-make-support`)
- #126257 (Rename `needs-matching-clang` to `needs-force-clang-based-tests`)
- #126259 (reachable computation: clarify comments around consts)
r? `@ghost`
`@rustbot` modify labels: rollup
Spruce up the diagnostics of some early lints
Implement the various "*(note to myself) in a follow-up PR we should turn parts of this message into a subdiagnostic (help msg or even struct sugg)*" drive-by comments I left in #124417 during my review.
For context, before #124417, only a few early lints touched/decorated/customized their diagnostic because the former API made it a bit awkward. Likely because of that, things that should've been subdiagnostics were just crammed into the primary message. This PR rectifies this.
Only compute `specializes` query if (min)specialization is enabled in the crate of the specializing impl
Fixes (after backport) https://github.com/rust-lang/rust/issues/125197
### What
https://github.com/rust-lang/rust/pull/122791 makes it so that inductive cycles are no longer hard errors. That means that when we are testing, for example, whether these impls overlap:
```rust
impl PartialEq<Self> for AnyId {
fn eq(&self, _: &Self) -> bool {
todo!()
}
}
impl<T: Identifier> PartialEq<T> for AnyId {
fn eq(&self, _: &T) -> bool {
todo!()
}
}
```
...given...
```rust
pub trait Identifier: Display + 'static {}
impl<T> Identifier for T where T: PartialEq + Display + 'static {}
```
Then we try to see if the second impl holds given `T = AnyId`. That requires `AnyId: Identifier`, which requires that `AnyId: PartialEq`, which is satisfied by these two impl candidates... The `PartialEq<T>` impl is a cycle, and we used to winnow it when we used to treat inductive cycles as errors.
However, now that we don't winnow it, this means that we *now* try calling `candidate_should_be_dropped_in_favor_of`, which tries to check whether one of the impls specializes the other: the `specializes` query. In that query, we currently bail early if the impl is local.
However, in a foreign crate, we try to compute if the two impls specialize each other by doing trait solving. This may itself lead to the same situation where we call `specializes`, which will lead to a query cycle.
### How does this fix the problem
We now record whether specialization is enabled in foreign crates, and extend this early-return behavior to foreign impls too. This means that we can only encounter these cycles if we truly have a specializing impl from a crate with specialization enabled.
-----
r? `@oli-obk` or `@lcnr`
Add explanatory note to async block type mismatch error
The async block type mismatch error might leave the user wondering as to why it occurred. The new note should give them the needed context.
Changes this diagnostic:
```
error[E0308]: mismatched types
--> src/main.rs:5:23
|
2 | let a = async { 1 };
| ----------- the expected `async` block
3 | let b = async { 2 };
| ----------- the found `async` block
4 |
5 | let bad = vec![a, b];
| ^ expected `async` block, found a different `async` block
|
= note: expected `async` block `{async block@src/main.rs:2:13: 2:24}`
found `async` block `{async block@src/main.rs:3:13: 3:24}`
```
to this:
```
error[E0308]: mismatched types
--> src/main.rs:5:23
|
2 | let a = async { 1 };
| ----------- the expected `async` block
3 | let b = async { 2 };
| ----------- the found `async` block
4 |
5 | let bad = vec![a, b];
| ^ expected `async` block, found a different `async` block
|
= note: expected `async` block `{async block@src/main.rs:2:13: 2:24}`
found `async` block `{async block@src/main.rs:3:13: 3:24}`
= note: no two async blocks, even if identical, have the same type
= help: consider pinning your async block and and casting it to a trait object
```
Fixes#125737
Fix ICE due to `unwrap` in `probe_for_name_many`
Fixes#125876
Now `probe_for_name_many` bubbles up the error returned by `probe_op` instead of calling `unwrap` on it.
Remove empty test suite `tests/run-make-fulldeps`
After #109770, there were only a handful of tests left in the run-make-fulldeps suite.
As of #126111, there are no longer *any* run-make-fulldeps tests, so now we can:
- Remove the directory
- Remove related bootstrap/compiletest code
- Remove various other references in CI scripts and documentation.
By removing this suite, we also no longer need to worry about discrepancies between it and ui-fulldeps, and we don't have to worry about porting tests from Makefile to [rmake](https://github.com/rust-lang/rust/issues/121876) (or whether rmake even works with fulldeps).
tests: Add ui/higher-ranked/trait-bounds/normalize-generic-arg.rs
This adds a regression test for an ICE "accidentally" fixed by https://github.com/rust-lang/rust/pull/101947 that does not add a test for this particular case.
Closes#107564.
I have confirmed the added test code fails with `nightly-2023-01-09` (and passes with `nightly-2023-01-10` and of course recent `nightly`).
This test never actually checked anything useful, so presumably it only existed
to silence the tidy check for feature gate tests, with the real checks being
performed elsewhere (in tests that have since been deleted).
offset_of: allow (unstably) taking the offset of slice tail fields
Fields of type `[T]` have a statically known offset, so there is no reason to forbid them in `offset_of!`. This PR adds the `offset_of_slice` feature to allow them.
I created a tracking issue: https://github.com/rust-lang/rust/issues/126151.
Port `tests/run-make-fulldeps/hotplug_codegen_backend` to ui-fulldeps
This is the last remaining run-make-fulldeps test, which means I actually had to leave behind a dummy README file to prevent compiletest from complaining about a missing directory.
(Removing the run-make-fulldeps suite entirely is non-trivial, so I intend to do so in a separate PR after this one.)
---
I wasn't sure about adding a new kind of aux build just for this one test, so I also tried to just port this test from Makefile to [rmake](https://github.com/rust-lang/rust/issues/121876) instead.
But I found that I couldn't get rmake to fully work for a run-make-fulldeps test, which convinced me that getting rid of run-make-fulldeps is worthwhile.
r? `@jieyouxu`
mark binding undetermined if target name exist and not obtained
- Fixes#124490
- Fixes#125013
Following up on #124840, I think handling only `target_bindings` is sufficient.
r? `@petrochenkov`
Detect pub structs never constructed and unused associated constants
<!--
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>
-->
Lints never constructed public structs.
If we don't provide public methods to construct public structs with private fields, and don't construct them in the local crate. They would be never constructed. So that we can detect such public structs.
---
Update:
Also lints unused associated constants in traits.
Parse unsafe attributes
Initial parse implementation for #123757
This is the initial work to parse unsafe attributes, which is represented as an extra `unsafety` field in `MetaItem` and `AttrItem`. There's two areas in the code where it appears that parsing is done manually and not using the parser stuff, and I'm not sure how I'm supposed to thread the change there.
Revert: create const block bodies in typeck via query feeding
as per the discussion in https://github.com/rust-lang/rust/pull/125806#discussion_r1622563948
It was a mistake to try to shoehorn const blocks and some specific anon consts into the same box and feed them during typeck. It turned out not simplifying anything (my hope was that we could feed `type_of` to start avoiding the huge HIR matcher, but that didn't work out), but instead making a few things more fragile.
reverts the const-block-specific parts of https://github.com/rust-lang/rust/pull/124650
`@bors` rollup=never had a small perf impact previously
fixes https://github.com/rust-lang/rust/issues/125846
r? `@compiler-errors`
Revert "Disallow ambiguous attributes on expressions" on nightly
As discussed in [today's t-compiler meeting](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bweekly.5D.202024-06-06/near/443079505), this reverts PR #124099 to fix P-critical beta regressions #125199.
r? ``@wesleywiser``
Opening as draft so that ``@wesleywiser`` and ``@apiraino,`` you can tell me whether you wanted:
1. a `beta-accepted` revert of #124099 on nightly (this PR)? That will need to be backported to beta (even though #126093 may be the last of those)
2. a revert of #124099 on beta?
3. all of the above?
I also opened #126102, another draft PR to revert #124099 on beta, should you choose options 2 or 3.
Don't warn on fields in the `unreachable_pub` lint
This PR restrict the `unreachable_pub` lint by not linting on `pub` fields of `pub(restricted)` structs and unions. This is done because that can quickly clutter the code for an uncertain value, in particular since the "real" visibility is defined by the parent (the struct it-self).
This is meant to address one of the last concern of the `unreachable_pub` lint.
r? ``@petrochenkov``
Rollup of 12 pull requests
Successful merges:
- #125220 (Repair several `riscv64gc-unknown-linux-gnu` codegen tests)
- #126033 (CI: fix publishing of toolstate history)
- #126034 (Clarify our tier 1 Windows Server support)
- #126035 (Some minor query system cleanups)
- #126051 (Clarify an `x fmt` error.)
- #126059 (Raise `DEFAULT_MIN_STACK_SIZE` to at least 64KiB)
- #126064 (Migrate `run-make/manual-crate-name` to `rmake.rs`)
- #126072 (compiletest: Allow multiple `//@ run-flags:` headers)
- #126073 (Port `tests/run-make-fulldeps/obtain-borrowck` to ui-fulldeps)
- #126081 (Do not use relative paths to Rust source root in run-make tests)
- #126086 (use windows compatible executable name for libcxx-version)
- #126096 ([RFC-2011] Allow `core_intrinsics` when activated)
r? `@ghost`
`@rustbot` modify labels: rollup
Directly add extension instead of using `Path::with_extension`
`Path::with_extension` has a nice footgun when the original path doesn't contain an extension: Anything after the last dot gets removed.
许杰友 Jieyou Xu (Joe)