Fix incorrect Box::pin suggestion
The suggestion checked if `Pin<Box<T>>` could be coeerced to the expected
type, but did not check predicates created by the coercion. We now
look for predicates that definitely cannot be satisfied before giving
the suggestion.
The suggestion is still marked MaybeIncorrect because we allow predicates that
are still ambiguous and can't be proven.
Fixes#72117.
Add check that live_region is live in sanitize_promoted
This pull request fixes#88434 by adding a check in `sanitize_promoted` to ensure that only regions which are actually live are added to the `liveness_constraints` of the `BorrowCheckContext`.
To implement this change, I needed to add a method to `LivenessValues` which gets the elements contained by a region:
/// Returns an iterator of all the elements contained by the region `r`
crate fn get_elements(&self, row: N) -> impl Iterator<Item = Location> + '_
Then, inside `sanitize_promoted`, we check whether the iterator returned by this method is non-empty to ensure that the region is actually live at at least one location before adding that region to the `liveness_constraints` of the `BorrowCheckContext`.
This is my first pull request to the Rust repo, so any feedback on how I can improve this pull request or if there is a better way to fix this issue would be very appreciated.
Add `const_eval_select` intrinsic
Adds an intrinsic that calls a given function when evaluated at compiler time, but generates a call to another function when called at runtime.
See https://github.com/rust-lang/const-eval/issues/7 for previous discussion.
r? `@oli-obk.`
The suggestion checked if Pin<Box<T>> could be coeerced to the expected
type, but did not check predicates created by the coercion. We now
look for predicates that definitely cannot be satisfied before giving
the suggestion.
The suggestion is marked MaybeIncorrect because we allow predicates that
are still ambiguous and can't be proven.
suggestion for typoed crate or module
Previously, the compiler didn't suggest similarly named crates or modules. This pull request adds a suggestion for typoed crates or modules.
#76208
before:
```
error[E0433]: failed to resolve: use of undeclared type or module `chono`
--> src/main.rs:2:5
|
2 | use chono::prelude::*;
| ^^^^^ use of undeclared type or module `chono`
```
after:
```
error[E0433]: failed to resolve: use of undeclared type or module `chono`
--> src/main.rs:2:5
|
2 | use chono::prelude::*;
| ^^^^^
| |
| use of undeclared crate or module `chono`
| help: a similar crate or module exists: `chrono`
```
Remove textual span from diagnostic string
This is an unnecessary repetition, as the diagnostic prints the span anyway in the source path right below the message.
I further removed the identification of the node, as that does not give any new information in any of the cases that are changed in tests.
EDIT: also inserted a suggestion that other diagnostics were already emitting
Include rmeta candidates in "multiple matching crates" error
Only dylib and rlib candidates were included in the error. I think the
reason is that at the time this error was originally implemented, rmeta
crate sources were represented different from dylib and rlib sources.
I wrote up more detailed analysis in [this comment][1].
The new version of the code is also a bit easier to read and should be
more robust to future changes since it uses `CrateSources::paths()`.
I also changed the code to sort the candidates to make the output deterministic;
added full stderr tests for the error; and added a long error code explanation.
[1]: https://github.com/rust-lang/rust/pull/88675#issuecomment-935282436
cc `@Mark-Simulacrum` `@jyn514`
avoid suggesting the same name
sort candidates
fix a message
use `opt_def_id` instead of `def_id`
move `find_similarly_named_module_or_crate` to rustc_resolve/src/diagnostics.rs
Fix: non_exhaustive_omitted_patterns by filtering unstable and doc hidden variants
Fixes: #89042
Now that #86809 has been merged there are cases (std::io::ErrorKind) where unstable feature gated variants were included in warning/error messages when the feature was not turned on. This filters those variants out of the return of `SplitWildcard::new`.
Variants marked `doc(hidden)` are filtered out of the witnesses list in `Usefulness::apply_constructor`.
Probably worth a perf run 🤷 since this area can be sensitive.
The test is copied from `src/test/ui/crate-loading/crateresolve1.rs` and
its auxiliary tests. I added it to the `compile_fail` code example check
exemption list since it's hard if not impossible to reproduce this error
in a standalone code example.
Only dylib and rlib candidates were included in the error. I think the
reason is that at the time this error was originally implemented, rmeta
crate sources were represented different from dylib and rlib sources.
I wrote up more detailed analysis in [this comment][1].
The new version of the code is also a bit easier to read and should be
more robust to future changes since it uses `CrateSources::paths()`.
[1]: https://github.com/rust-lang/rust/pull/88675#issuecomment-935282436
Remove built-in query cache_hit tracking
This was already only enabled in debug_assertions builds. Generally, it seems
like most use cases that would use this could also use the -Zself-profile flag
which also tracks cache hits (in all builds), and so the extra cfg's and such
are not really necessary.
This is largely just a small cleanup though, which primarily is intended to make
other changes easier by avoiding the need to deal with this field.
Add test cases for unstable variants
Add test cases for doc hidden variants
Move is_doc_hidden to method on TyCtxt
Add unstable variants test to reachable-patterns ui test
Rename reachable-patterns -> omitted-patterns
Fix ICE when compiling nightly std/rustc on beta compiler
Fix#89775#89479 renames a lot of diagnostic items, but it happens that the beta compiler assumes that there must be DefId with `rustc_diagnostic_item = "send_trait"`, causing an ICE when compiling stage 0 std or stage 1 compiler. So gate it with `cfg(bootstrap)`.
The unwrap is also removed, so that existence of the diagnostic item is not required. I ripgreped the code base and this seems the only place where `unwrap` is called on the return value of `get_diagnostic_item`.
Re-use TypeChecker instead of passing around some of its fields
In the future (for lazy TAIT) we will need more of its fields, but even ignoring that, this change seems reasonable on its own to me.
Fix inherent impl overlap check.
The current implementation of the overlap check was slightly buggy, and unified the wrong connected component in the `ids.len() <= 1` case. This became visible in another PR which changed the iteration order of items.
r? ``@matthewjasper`` since you reviewed the other PR.
Ignore type of projections for upvar capturing
Fix#89606
Ignore type of projections for upvar capturing. Originally HashMap is used, and the hash/eq implementation of Place takes the type of projections into account. These types may differ by lifetime which causes #89606 to ICE.
I originally considered erasing regions but `place.ty()` is used when creating upvar tuple type, more than just serving as a key type, so I switched to a linear comparison with custom eq (`compare_place_ignore_ty`) instead.
r? `@wesleywiser`
`@rustbot` label +T-compiler
This was already only enabled in debug_assertions builds. Generally, it seems
like most use cases that would use this could also use the -Zself-profile flag
which also tracks cache hits (in all builds), and so the extra cfg's and such
are not really necessary.
This is largely just a small cleanup though, which primarily is intended to make
other changes easier by avoiding the need to deal with this field.
Add enum_intrinsics_non_enums lint
There is a clippy lint to prevent calling [`mem::discriminant`](https://doc.rust-lang.org/std/mem/fn.discriminant.html) with a non-enum type. I think the lint is worthy of being included in rustc, given that `discriminant::<T>()` where `T` is a non-enum has an unspecified return value, and there are no valid use cases where you'd actually want this.
I've also made the lint check [variant_count](https://doc.rust-lang.org/core/mem/fn.variant_count.html) (#73662).
closes#83899
Fix RUSTC_LOG handling
Rustc was incorrectly reading the value of `RUSTC_LOG` as the environment vairable with the logging configuration, rather than the logging configuration itself.
