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`).
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.
Remove the `ty` field from type system `Const`s
Fixes#125556Fixes#122908
Part of the work on `adt_const_params`/`generic_const_param_types`/`min_generic_const_exprs`/generally making the compiler nicer. cc rust-lang/project-const-generics#44
Please review commit-by-commit otherwise I wasted a lot of time not just squashing this into a giant mess (and also it'll be SO much nicer because theres a lot of fluff changes mixed in with other more careful changes if looking via File Changes
---
Why do this?
- The `ty` field keeps causing ICEs and weird behaviour due to it either being treated as "part of the const" or it being forgotten about leading to ICEs.
- As we move forward with `adt_const_params` and a potential `min_generic_const_exprs` it's going to become more complex to actually lower the correct `Ty<'tcx>`
- It muddles the idea behind how we check `Const` arguments have the correct type. By having the `ty` field it may seem like we ought to be relating it when we relate two types, or that its generally important information about the `Const`.
- Brings the compiler more in line with `a-mir-formality` as that also tracks the type of type system `Const`s via `ConstArgHasType` bounds in the env instead of on the `Const` itself.
- A lot of stuff is a lot nicer when you dont have to pass around the type of a const lol. Everywhere we construct `Const` is now significantly nicer 😅
See #125671's description for some more information about the `ty` field
---
General summary of changes in this PR:
- Add `Ty` to `ConstKind::Value` as otherwise there is no way to implement `ConstArgHasType` to ensure that const arguments are correctly typed for the parameter when we stop creating anon consts for all const args. It's also just incredibly difficult/annoying to thread the correct `Ty` around to a bunch of ctfe functions otherwise.
- Fully implement `ConstArgHasType` in both the old and new solver. Since it now has no reliance on the `ty` field it serves its originally intended purpose of being able to act as a double check that trait vs impls have correctly typed const parameters. It also will now be able to be responsible for checking types of const arguments to parameters under `min_generic_const_exprs`.
- Add `Ty` to `mir::Const::Ty`. I dont have a great understanding of why mir constants are setup like this to be honest. Regardless they need to be able to determine the type of the const and the easiest way to make this happen was to simply store the `Ty` along side the `ty::Const`. Maybe we can do better here in the future but I'd have to spend way more time looking at everywhere we use `mir::Const`.
- rustdoc has its own `Const` which also has a `ty` field. It was relatively easy to remove this.
---
r? `@lcnr` `@compiler-errors`
When `derive`ing, account for HRTB on `BareFn` fields
When given
```rust
trait SomeTrait {
type SomeType<'a>;
}
#[derive(Clone)]
struct Foo<T: SomeTrait> {
x: for<'a> fn(T::SomeType<'a>)
}
```
expand to
```rust
impl<T: ::core::clone::Clone + SomeTrait> ::core::clone::Clone for Foo<T>
where for<'a> T::SomeType<'a>: ::core::clone::Clone {
#[inline]
fn clone(&self) -> Foo<T> {
Foo { x: ::core::clone::Clone::clone(&self.x) }
}
}
```
instead of the previous invalid
```
impl<T: ::core::clone::Clone + SomeTrait> ::core::clone::Clone for Foo<T>
where T::SomeType<'a>: ::core::clone::Clone {
#[inline]
fn clone(&self) -> Foo<T> {
Foo { x: ::core::clone::Clone::clone(&self.x) }
}
}
```
Fix#122622.
<!--
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>
-->
Match ergonomics 2024: align implementation with RFC
- Remove eat-two-layers (`ref_pat_everywhere`)
- Consolidate `mut_preserve_binding_mode_2024` into `ref_pat_eat_one_layer_2024`
- `&mut` no longer peels off `&`
- Apply "no `ref mut` behind `&`" rule on all editions with `ref_pat_eat_one_layer_2024`
- Require `mut_ref` feature gate for all mutable by-reference bindings
r? ``@Nadrieril``
cc https://github.com/rust-lang/rust/issues/123076
``@rustbot`` label A-edition-2024 A-patterns
Rollup of 9 pull requests
Successful merges:
- #124840 (resolve: mark it undetermined if single import is not has any bindings)
- #125622 (Winnow private method candidates instead of assuming any candidate of the right name will apply)
- #125648 (Remove unused(?) `~/rustsrc` folder from docker script)
- #125672 (Add more ABI test cases to miri (RFC 3391))
- #125800 (Fix `mut` static task queue in SGX target)
- #125871 (Orphanck[old solver]: Consider opaque types to never cover type parameters)
- #125893 (Handle all GVN binops in a single place.)
- #126008 (Port `tests/run-make-fulldeps/issue-19371` to ui-fulldeps)
- #126032 (Update description of the `IsTerminal` example)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix tests/codegen/riscv-abi/call-llvm-intrinsics.rs
Fix tests/codegen/riscv-abi/riscv64-lp64d-abi.rs
Fix tests/codegen/riscv-abi/riscv64-lp64f-lp64d-abi.rs
On riscv64gc ignore tests/ui/debuginfo/debuginfo-emit-llvm-ir-and-split-debuginfo.rs
Make tests/codegen/riscv-abi/riscv64-lp64d-abi.rs no_core
Make tests/codegen/riscv-abi/riscv64-lp64f-lp64d-abi.rs no_core
Set -O for tests/codegen/riscv-abi/riscv64-lp64d-abi.rs
Set -O for tests/codegen/riscv-abi/riscv64-lp64f-lp64d-abi.rs
Orphanck[old solver]: Consider opaque types to never cover type parameters
This fixes an oversight of mine in #117164. The change itself has already been FCP'ed.
This only affects the old solver, the next solver already correctly rejects the added test since #117164.
r? ``@lcnr``
set `has_unconstrained_ty_var` when generalizing aliases in bivariant contexts
this previously prevented the `regression-31157` benchmark from building
r? `@compiler-errors`
Winnow private method candidates instead of assuming any candidate of the right name will apply
partially reverts https://github.com/rust-lang/rust/pull/60721
My original motivation was just to avoid the `delay_span_bug` (by attempting to thread the `ErrorGuaranteed` through to here). But then I realized that the error message is wrong. It refers to the `Foo<A>::foo` instead of `Foo<B>::foo`. This is almost invisible, because both functions are the same, but on different lines, so `-Zui-testing` makes it so the test is the same no matter which of these two functions is referenced.
But there's a much more obvious bug: If `Foo<B>` does not have a `foo` method at all, but `Foo<A>` has a private `foo` method, then we'll refer to that one. This has now been fixed, and we report a normal `method not found` error.
The way this is done is by creating a list of all possible private functions (just like we create a list of the public functions that can actually be called), and then winnowing it by analyzing where bounds and `Self` types to see if any of the found methods can actually apply (again, just like with the list of public functions).
I wonder if there is room for doing the same thing with unstable functions instead of running all of method resolution twice.
r? ``@compiler-errors`` for method resolution stuff
resolve: mark it undetermined if single import is not has any bindings
- Fixes#124490
- Fixes#125013
This issue arises from incorrect resolution updates, for example:
```rust
mod a {
pub mod b {
pub mod c {}
}
}
use a::*;
use b::c;
use c as b;
fn main() {}
```
1. In the first loop, binding `(root, b)` is refer to `root:🅰️:b` due to `use a::*`.
1. However, binding `(root, c)` isn't defined by `use b::c` during this stage because `use c as b` falls under the `single_imports` of `(root, b)`, where the `imported_module` hasn't been computed yet. This results in marking the `path_res` for `b` as `Indeterminate`.
2. Then, the `imported_module` for `use c as b` will be recorded.
2. In the second loop, `use b::c` will be processed again:
1. Firstly, it attempts to find the `path_res` for `(root, b)`.
2. It will iterate through the `single_imports` of `use b::c`, encounter `use c as b`, attempt to resolve `c` in `root`, and ultimately return `Err(Undetermined)`, thus passing the iterator.
3. Use the binding `(root, b)` -> `root:🅰️:b` introduced by `use a::*` and ultimately return `root:🅰️:b` as the `path_res` of `b`.
4. Then define the binding `(root, c)` -> `root:🅰️🅱️:c`.
3. Then process `use c as b`, update the resolution for `(root, b)` to refer to `root:🅰️🅱️:c`, ultimately causing inconsistency.
In my view, step `2.2` has an issue where it should exit early, similar to the behavior when there's no `imported_module`. Therefore, I've added an attribute called `indeterminate` to `ImportData`. This will help us handle only those single imports that have at least one determined binding.
r? ``@petrochenkov``
Detect when user is trying to create a lending `Iterator` and give a custom explanation
The scope for this diagnostic is to detect lending iterators specifically and it's main goal is to help beginners to understand that what they are trying to implement might not be possible for `Iterator` trait specifically.
I ended up to changing the wording from originally proposed in the ticket because it might be misleading otherwise: `Data` might have a lifetime parameter but it can be unrelated to items user is planning to return.
Fixes https://github.com/rust-lang/rust/issues/125337
