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
Add translation support by mdbook-i18n-helpers to bootstrap
This PR add translation support by [mdbook-i18n-helpers](https://github.com/google/mdbook-i18n-helpers) to bootstrap.
This is draft PR because there is the dependency to my forked mdbook-i18n-helpers.
If this PR is acceptable, I'll send a PR to the original mdbook-i18n-helpers and remove draft after changing the dependency to the original.
Closes#124641
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
Rollup of 10 pull requests
Successful merges:
- #124746 (`rustc --explain E0582` additional example)
- #125407 (Detect when user is trying to create a lending `Iterator` and give a custom explanation)
- #125505 (Add intra-doc-links to rustc_middle crate-level docs.)
- #125792 (Don't drop `Unsize` candidate in intercrate mode)
- #125819 (Various `HirTyLowerer` cleanups)
- #125861 (rustc_codegen_ssa: fix `get_rpath_relative_to_output` panic when lib only contains file name)
- #125911 (delete bootstrap build before switching to bumped rustc)
- #125921 (coverage: Carve out hole spans in a separate early pass)
- #125940 (std::unix::fs::get_path: using fcntl codepath for netbsd instead.)
- #126022 (set `has_unconstrained_ty_var` when generalizing aliases in bivariant contexts)
r? `@ghost`
`@rustbot` modify labels: rollup
Port `tests/run-make-fulldeps/issue-19371` to ui-fulldeps
This test can run as an ordinary `tests/ui-fulldeps` test, with the help of some additional header variable substitutions to supply a sysroot and linker.
---
Unlike #125973, this test appears to be testing something vaguely useful and breakable, which is why I didn't just delete it.
Handle all GVN binops in a single place.
<!--
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>
-->
Addresses https://github.com/rust-lang/rust/pull/125359/files#r1608185319
r? ``@oli-obk``
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``
Fix `mut` static task queue in SGX target
[PR 125046](https://github.com/rust-lang/rust/pull/125046) prevents mutable references to statics with `#[linkage]`. Such a construct was used with the tests for the `x86_64-fortanix-unknown-sgx` target. This PR fixes this and cleans up code a bit in 5 steps. Each step passes CI:
- The `mut` static is removed, and `Task` explicitly implements `Send`
- Renaming of the `task_queue::lock` function
- Pass function for `Thread` as `Send` to `Thread::imp` and update when `Packet<'scope, T>` implements `Sync`
- Storing `Task::p` as a type that implements `Send`
- Letting the compiler auto implement `Send` for `Task`
cc: ``@jethrogb``
set `has_unconstrained_ty_var` when generalizing aliases in bivariant contexts
this previously prevented the `regression-31157` benchmark from building
r? `@compiler-errors`
std::unix::fs::get_path: using fcntl codepath for netbsd instead.
on netbsd, procfs is not as central as on linux/solaris thus can be perfectly not mounted.
Thus using fcntl with F_GETPATH, the kernel deals with MAXPATHLEN internally too.
Remove unused(?) `~/rustsrc` folder from docker script
Every time I run a docker image, the script creates an empty `~/rustsrc` folder. It doesn't seem to be referenced anywhere else, so I'd like to remove it.
Incidentally, this also documents DIST_TRY_BUILD as I fail to find it from a simple search any time I look for it to eg enable tests on try builds.
coverage: Carve out hole spans in a separate early pass
When extracting spans from MIR for use in coverage instrumentation, we sometimes need to identify *hole spans* (currently just closures), and carve up the other spans so that they don't overlap with holes.
This PR simplifies the main coverage-span-refiner by extracting the hole-carving process into a separate early pass. That pass produces a series of independent buckets, and we run the span-refiner on each bucket separately.
There is almost no difference in the resulting mappings, other than in some edge cases involving macros.
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
delete bootstrap build before switching to bumped rustc
Technically, wiping bootstrap builds can increase the build time. But in practice, trying to manually resolve post-bump issues and even accidentally removing the entire build directory will result in a much greater loss of time. After all, the bootstrap build process is not a particularly lengthy operation.
Workaround for #125578
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``
rustc_codegen_ssa: fix `get_rpath_relative_to_output` panic when lib only contains file name
<!--
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>
-->
When compiles program with `-C rpath=yes` but with no output filename specified, or with filename ONLY, we will get an ICE for now. Fix it by treat empty `output` path in `get_rpath_relative_to_output` as current dir.
Before this patch:
```bash
rustc -C prefer_dynamic=yes -C rpath=yes -O h.rs # ICE, no output filename specified
rustc -o hello -C prefer_dynamic=yes -C rpath=yes -O h.rs # ICE, output filename has no path
rustc -o ./hello -C prefer_dynamic=yes -C rpath=yes -O h.rs # Works
```
All those examples work after the patch.
Close#119571.
Close#125785.
Various `HirTyLowerer` cleanups
Previously there was some ad-hoc specialization going on, because you could call `allows_infer`, which basically was deciding between whether the trait object was backed by `FnCtxt` or by `ItemCtxt`. I moved all the different logic into dedicated methods on `HirTyLowerer` and removed `allows_infer`
best reviewed commit-by-commit
Add intra-doc-links to rustc_middle crate-level docs.
Makes it slightly faster to find these modules, as you don't need to hunt for them in the big list.
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
`rustc --explain E0582` additional example
## Context
*From #124744*
Expands the example for E0582, an error ensuring that lifetime in a function's return type is sufficiently constrained (e.g. actually tied to some input type), to show an additional example where one sees the lifetime occurring syntactically among the relevant function input types, but is nonetheless rejected by rustc because a syntactic occurrence is not always sufficient.
Update cargo
9 commits in 7a6fad0984d28c8330974636972aa296b67c4513..34a6a87d8a2330d8c9d578f927489689328a652d
2024-05-31 22:26:03 +0000 to 2024-06-04 15:31:01 +0000
- Silence the warning about forgetting the vendoring (rust-lang/cargo#13886)
- fix(vendor): Ensure sort happens for vendor (rust-lang/cargo#14004)
- fix(add): Avoid escaping double-quotes by using string literals (rust-lang/cargo#14006)
- refactor(source): Split `RecursivePathSource` out of `PathSource` (rust-lang/cargo#13993)
- doc: Add README for resolver-tests (rust-lang/cargo#13977)
- Allows the default git/gitoxide configuration to be obtained from the ENV and config (rust-lang/cargo#13687)
- refactor: Transition direct assertions from cargo-test-support to snapbox (rust-lang/cargo#13980)
- Fix: Skip deserialization of unrelated fields with overlapping name (rust-lang/cargo#14000)
- chore(deps): update alpine docker tag to v3.20 (rust-lang/cargo#13996)
r? ghost
Rollup of 12 pull requests
Successful merges:
- #123168 (Add `size_of` and `size_of_val` and `align_of` and `align_of_val` to the prelude)
- #125273 (bootstrap: implement new feature `bootstrap-self-test`)
- #125683 (Rewrite `suspicious-library`, `resolve-rename` and `incr-prev-body-beyond-eof` `run-make` tests in `rmake.rs` format)
- #125815 (`rustc_parse` top-level cleanups)
- #125903 (rustc_span: Inline some hot functions)
- #125906 (Remove a bunch of redundant args from `report_method_error`)
- #125920 (Allow static mut definitions with #[linkage])
- #125982 (Make deleting on LinkedList aware of the allocator)
- #125995 (Use inline const blocks to create arrays of `MaybeUninit`.)
- #125996 (Closures are recursively reachable)
- #126003 (Add a co-maintainer for the two ARMv4T targets)
- #126004 (Add another test for hidden types capturing lifetimes that outlive but arent mentioned in substs)
r? `@ghost`
`@rustbot` modify labels: rollup
`ct_infer` and `lower_ty` will correctly result in an error constant or type respectively, as they go through a `HirTyLowerer` method (just like `HirTyLowerer::allow_infer` is a method implemented by both implementors
Add another test for hidden types capturing lifetimes that outlive but arent mentioned in substs
Another test to make sure future implementations of https://github.com/rust-lang/rust/pull/116040 don't have any subtle unsoundness 🤔
r? types
Add a co-maintainer for the two ARMv4T targets
This adds a second maintainer to the `armv4t-none-eabi` and `thumbv4t-none-eabi` targets, a necessary step on the path to Tier 2
Use inline const blocks to create arrays of `MaybeUninit`.
This PR contains 2 changes enabled by the fact that [`inline_const` is now stable](https://github.com/rust-lang/rust/pull/104087), and was split out of #125082.
1. Use inline const instead of `unsafe` to construct arrays in `MaybeUninit` examples.
Rationale: Demonstrate good practice of avoiding `unsafe` code where it is not strictly necessary.
4. Use inline const instead of `unsafe` to implement `MaybeUninit::uninit_array()`.
This is arguably giving the compiler more work to do, in exchange for eliminating just one single internal unsafe block, so it's less certain that this is good on net.
r? `@Nilstrieb`
`rustc_parse` top-level cleanups
A bunch of improvements in and around `compiler/rustc_parse/src/lib.rs`. Many of the changes streamline the API in that file from this (12 functions and one macro):
```
name args return type
---- ---- -----------
panictry_buffer! Result<T, Vec<Diag>> T
pub parse_crate_from_file path PResult<Crate>
pub parse_crate_attrs_from_file path PResult<AttrVec>
pub parse_crate_from_source_str name,src PResult<Crate>
pub parse_crate_attrs_from_source_str name,src PResult<AttrVec>
pub new_parser_from_source_str name,src Parser
pub maybe_new_parser_from_source_str name,src Result<Parser, Vec<Diag>>
pub new_parser_from_file path,error_sp Parser
maybe_source_file_to_parser srcfile Result<Parser, Vec<Diag>>
pub parse_stream_from_source_str name,src,override_sp TokenStream
pub source_file_to_stream srcfile,override_sp TokenStream
maybe_file_to_stream srcfile,override_sp Result<TokenStream, Vec<Diag>>
pub stream_to_parser stream,subparser_name Parser
```
to this:
```
name args return type
---- ---- -----------
unwrap_or_emit_fatal Result<T, Vec<Diag>> T
pub new_parser_from_source_str name,src Result<Parser, Vec<Diag>>
pub new_parser_from_file path,error_sp Result<Parser, Vec<Diag>>
new_parser_from_source_file srcfile Result<Parser, Vec<Diag>>
pub source_str_to_stream name,src,override_sp Result<TokenStream, Vec<Diag>>
source_file_to_stream srcfile,override_sp Result<TokenStream, Vec<Diag>>
```
I found the old API quite confusing, with lots of similar-sounding function names and no clear structure. I think the new API is much better.
r? `@spastorino`
Rewrite `suspicious-library`, `resolve-rename` and `incr-prev-body-beyond-eof` `run-make` tests in `rmake.rs` format
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
Some oddly specific ignore flags in `incr-prev-body-beyond-eof`:
```rs
// ignore-none
// ignore-nvptx64-nvidia-cuda
```
it could be interesting to run a try job, but it seems there is no nvidia-cuda in the CI settings (`jobs.yml`).
try-job: armhf-gnu
bootstrap: implement new feature `bootstrap-self-test`
Some of the bootstrap logics should be ignored during unit tests because they either make the tests take longer or cause them to fail. Therefore we need to be able to exclude them from the bootstrap when it's called by unit tests. This change introduces a new feature called `bootstrap-self-test`, which is enabled on bootstrap unit tests by default. This allows us to keep the logic separate between compiler builds and bootstrap tests without needing messy workarounds (like checking if target names match those in the unit tests).
Also, resolves https://github.com/rust-lang/rust/issues/122090 (without having to create separate modules)
Add `size_of` and `size_of_val` and `align_of` and `align_of_val` to the prelude
(Note: need to update the PR to add `align_of` and `align_of_val`, and remove the second commit with the myriad changes to appease the lint.)
Many, many projects use `size_of` to get the size of a type. However,
it's also often equally easy to hardcode a size (e.g. `8` instead of
`size_of::<u64>()`). Minimizing friction in the use of `size_of` helps
ensure that people use it and make code more self-documenting.
The name `size_of` is unambiguous: the name alone, without any prefix or
path, is self-explanatory and unmistakeable for any other functionality.
Adding it to the prelude cannot produce any name conflicts, as any local
definition will silently shadow the one from the prelude. Thus, we don't
need to wait for a new edition prelude to add it.
