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_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.
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.)
The first one is out-of-date -- there are no longer functions expr,
item, stmt. And I don't know what a "HOF" is.
The second one doesn't really tell you anything.
- Convert it from a macro to a function, which is nicer.
- Rename it as `unwrap_or_emit_fatal`, which is clearer.
- Fix the comment. In particular, `panictry!` no longer exists.
- Remove the unnecessary `use` declaration.
It has a single call site.
This also means `CFG_ATTR_{GRAMMAR_HELP,NOTE_REF}` can be moved into
`parse_cfg_attr`, now that it's the only function that uses them.
And the commit removes the line break in the URL.
Lexing converts source text into a token stream. Parsing converts a
token stream into AST fragments. This commit renames several lexing
operations that have "parse" in the name. I think these names have been
subtly confusing me for years.
This is just a `s/parse/lex/` on function names, with one exception:
`parse_stream_from_source_str` becomes `source_str_to_stream`, to make
it consistent with the existing `source_file_to_stream`. The commit also
moves that function's location in the file to be just above
`source_file_to_stream`.
The commit also cleans up a few comments along the way.
Convert `proc_macro_back_compat` lint to an unconditional error.
We still check for the `rental`/`allsorts-rental` crates. But now if they are detected we just emit a fatal error, instead of emitting a warning and providing alternative behaviour.
The original "hack" implementing alternative behaviour was added in #73345.
The lint was added in #83127.
The tracking issue is #83125.
The direct motivation for the change is that providing the alternative behaviour is interfering with #125174 and follow-on work.
r? ``@estebank``
Store the types of `ty::Expr` arguments in the `ty::Expr`
Part of #125958
In attempting to remove the `ty` field on `Const` it will become necessary to store the `Ty<'tcx>` inside of `Expr<'tcx>`. In order to do this without blowing up the size of `ConstKind`, we start storing the type/const args as `GenericArgs`
r? `@oli-obk`
Split smir `Const` into `TyConst` and `MirConst`
Part of #125958
Building a `smir::Const` currently requires accessing the `Ty<'tcx>` of a `ty::Const`. This will stop being possible in the future. Replicate the split in rustc of having a representation of type level constants and mir constants with the latter being able to store the former. Ideally we wouldnt have `MirConst::Ty` but 🤷♀️
r? `@oli-obk`
Streamline `nested` calls.
`TyCtxt` impls `PpAnn` in `compiler/rustc_middle/src/hir/map/mod.rs`. We can call that impl, which then calls the one on `intravisit::Map`, instead of calling the one on `intravisit::Map` directly, avoiding a cast and extra references.
r? `@lqd`
Improve renaming suggestion for names with leading underscores
Fixes#125650
Before:
```
error[E0425]: cannot find value `p` in this scope
--> test.rs:2:13
|
2 | let _ = p;
| ^
|
help: a local variable with a similar name exists, consider renaming `_p` into `p`
|
1 | fn a(p: i32) {
| ~
```
After:
```
error[E0425]: cannot find value `p` in this scope
--> test.rs:2:13
|
1 | fn a(_p: i32) {
| -- `_p` defined here
2 | let _ = p;
| ^
|
help: the leading underscore in `_p` marks it as unused, consider renaming it to `p`
|
1 | fn a(p: i32) {
| ~
```
This change doesn't exactly conform to what was proposed in the issue:
1. I've kept the suggested code instead of solely replacing it with the label
2. I've removed the "...similar name exists..." message instead of relocating to the usage span
3. You could argue that it still isn't completely clear that the change is referring to the definition (not the usage), but I'm not sure how to do this without playing down the fact that the error was caused by the usage of an undefined name.
Refactor `#[diagnostic::do_not_recommend]` support
This commit refactors the `#[do_not_recommend]` support in the old parser to also apply to projection errors and not only to selection errors. This allows the attribute to be used more widely.
Part of #51992
r? `@compiler-errors`
<!--
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>
-->
Silence follow-up errors directly based on error types and regions
During type_of, we used to just return an error type if there were any errors encountered. This is problematic, because it means a struct declared as `struct Foo<'static>` will end up not finding any inherent or trait impls because those impl blocks' `Self` type will be `{type error}` instead of `Foo<'re_error>`. Now it's the latter, silencing nonsensical follow-up errors about `Foo` not having any methods.
Unfortunately that now allows for new follow-up errors, because borrowck treats `'re_error` as `'static`, causing nonsensical errors about non-error lifetimes not outliving `'static`. So what I also did was to just strip all outlives bounds that borrowck found, thus never letting it check them. There are probably more nuanced ways to do this, but I worried there would be other nonsensical errors if some outlives bounds were missing. Also from the test changes, it looked like an improvement everywhere.
Handle no values cfgs with `--print=check-cfg`
This PR fix a bug with `--print=check-cfg`, where no values cfgs where not printed since we only printed cfgs that had at least one values.
The representation I choose is `CFG=`, since it doesn't correspond to any valid config, it also IMO nicely complements the `values()` (to indicate no values). Representing the absence of value by the absence of the value.
So for `cfg(feature, values())` we would print `feature=`.
I also added the missing tracking issue number in the doc.
r? ```@petrochenkov```
Align `Term` methods with `GenericArg` methods, add `Term::expect_*`
* `Term::ty` -> `Term::as_type`.
* `Term::ct` -> `Term::as_const`.
* Adds `Term::expect_type` and `Term::expect_const`, and uses them in favor of `.ty().unwrap()`, etc.
I could also shorten these to `as_ty` and then do `GenericArg::as_ty` as well, but I do think the `as_` is important to signal that this is a conversion method, and not a getter, like `Const::ty` is.
r? types
Add tracking issue and unstable book page for `"vectorcall"` ABI
Originally added in 2015 by #30567, the Windows `"vectorcall"` ABI didn't have a tracking issue until now.
Tracking issue: #124485
`TyCtxt` impls `PpAnn` in `compiler/rustc_middle/src/hir/map/mod.rs`. We
can call that impl, which then calls the one on `intravisit::Map`,
instead of calling the one on `intravisit::Map` directly, avoiding a
cast and extra references.
Make `WHERE_CLAUSES_OBJECT_SAFETY` a regular object safety violation
#### The issue
In #50781, we have known about unsound `where` clauses in function arguments:
```rust
trait Impossible {}
trait Foo {
fn impossible(&self)
where
Self: Impossible;
}
impl Foo for &() {
fn impossible(&self)
where
Self: Impossible,
{}
}
// `where` clause satisfied for the object, meaning that the function now *looks* callable.
impl Impossible for dyn Foo {}
fn main() {
let x: &dyn Foo = &&();
x.impossible();
}
```
... which currently segfaults at runtime because we try to call a method in the vtable that doesn't exist. :(
#### What did u change
This PR removes the `WHERE_CLAUSES_OBJECT_SAFETY` lint and instead makes it a regular object safety violation. I choose to make this into a hard error immediately rather than a `deny` because of the time that has passed since this lint was authored, and the single (1) regression (see below).
That means that it's OK to mention `where Self: Trait` where clauses in your trait, but making such a trait into a `dyn Trait` object will report an object safety violation just like `where Self: Sized`, etc.
```rust
trait Impossible {}
trait Foo {
fn impossible(&self)
where
Self: Impossible; // <~ This definition is valid, just not object-safe.
}
impl Foo for &() {
fn impossible(&self)
where
Self: Impossible,
{}
}
fn main() {
let x: &dyn Foo = &&(); // <~ THIS is where we emit an error.
}
```
#### Regressions
From a recent crater run, there's only one crate that relies on this behavior: https://github.com/rust-lang/rust/pull/124305#issuecomment-2122381740. The crate looks unmaintained and there seems to be no dependents.
#### Further
We may later choose to relax this (e.g. when the where clause is implied by the supertraits of the trait or something), but this is not something I propose to do in this FCP.
For example, given:
```
trait Tr {
fn f(&self) where Self: Blanket;
}
impl<T: ?Sized> Blanket for T {}
```
Proving that some placeholder `S` implements `S: Blanket` would be sufficient to prove that the same (blanket) impl applies for both `Concerete: Blanket` and `dyn Trait: Blanket`.
Repeating here that I don't think we need to implement this behavior right now.
----
r? lcnr
Show files produced by `--emit foo` in json artifact notifications
Right now it is possible to ask `rustc` to save some intermediate representation into one or more files with `--emit=foo`, but figuring out what exactly was produced is difficult. This pull request adds information about `llvm_ir` and `asm` intermediate files into notifications produced by `--json=artifacts`.
Related discussion: https://internals.rust-lang.org/t/easier-access-to-files-generated-by-emit-foo/20477
Motivation - `cargo-show-asm` parses those intermediate files and presents them in a user friendly way, but right now I have to apply some dirty hacks. Hacks make behavior confusing: https://github.com/hintron/computer-enhance/issues/35
This pull request introduces a new behavior: now `rustc` will emit a new artifact notification for every artifact type user asked to `--emit`, for example for `--emit asm` those will include all the `.s` files.
Most users won't notice this behavior, to be affected by it all of the following must hold:
- user must use `rustc` binary directly (when `cargo` invokes `rustc` - it consumes artifact notifications and doesn't emit anything)
- user must specify both `--emit xxx` and `--json artifacts`
- user must refuse to handle unknown artifact types
- user must disable incremental compilation (or deal with it better than cargo does, or use a workaround like `save-temps`) in order not to hit #88829 / #89149
