It's small and has a single call site.
Also change the second `parse_meta` call to use a simple `match`, like
the first `parse_meta` call, instead of a confusing `map_err`+`ok`
combination.
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
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``
set `has_unconstrained_ty_var` when generalizing aliases in bivariant contexts
this previously prevented the `regression-31157` benchmark from building
r? `@compiler-errors`
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
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.
The `use_polonius` flag is both redundant and confusing since every
function it's propagated to also checks if `all_facts` is `Some`,
the true test of whether to generate Polonius facts for Polonius
or for external consumers. This PR makes that path clearer by
simply doing away with the argument and handling the logic in
precisely two places: where facts are populated (check for `Some`),
and where `all_facts` are initialised. It also delays some statements
until after that check to avoid the miniscule performance penalty
of executing them when Polonius is disabled.
This also addresses @lqd's concern in #125652 by reducing
the size of what is cloned out of Polonius facts to just the
facts being added, as opposed to the entire vector of potential
inputs, and added descriptive comments.
*Reviewer note*: the comments in [add_extra_drop_facts](85f90a4612/compiler/rustc_borrowck/src/type_check/liveness/trace.rs (L219)) should be inspected by a reviewer,
in particular the one on L#259 in this PR, which should be trivial
for someone with the right background knowledge.
I also included some minor lints I found on the way there that I
couldn't help myself from addressing.
`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
`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`
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.
Instead of using AST pretty printing.
This is a step towards removing `token::Interpolated`, which will
eventually (in #124141) be replaced with a token stream within invisible
delimiters.
This changes (improves) the output of the `stringify!` macro in some
cases. This is allowed. As the `stringify!` docs say: "Note that the
expanded results of the input tokens may change in the future. You
should be careful if you rely on the output."
Test changes:
- tests/ui/macros/stringify.rs: this used to test both token stream
pretty printing and AST pretty printing via different ways of invoking
of `stringify!` (i.e. `$expr` vs `$tt`). But those two different
invocations now give the same result, which is a nice consistency
improvement. This removes the need for all the `c2*` macros. The AST
pretty printer now has more thorough testing thanks to #125236.
- tests/ui/proc-macro/*: minor improvements where small differences
between `INPUT (DISPLAY)` output and `DEEP-RE-COLLECTED (DISPLAY)`
output disappear.
Currently we have an awkward mix of fallible and infallible functions:
```
new_parser_from_source_str
maybe_new_parser_from_source_str
new_parser_from_file
(maybe_new_parser_from_file) // missing
(new_parser_from_source_file) // missing
maybe_new_parser_from_source_file
source_str_to_stream
maybe_source_file_to_stream
```
We could add the two missing functions, but instead this commit removes
of all the infallible ones and renames the fallible ones leaving us with
these which are all fallible:
```
new_parser_from_source_str
new_parser_from_file
new_parser_from_source_file
source_str_to_stream
source_file_to_stream
```
This requires making `unwrap_or_emit_fatal` public so callers of
formerly infallible functions can still work.
This does make some of the call sites slightly more verbose, but I think
it's worth it for the simpler API. Also, there are two `catch_unwind`
calls and one `catch_fatal_errors` call in this diff that become
removable thanks this change. (I will do that in a follow-up PR.)
