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
add some more testcases
resolves#52893resolves#68295resolves#87750resolves#88071
All these issues have been fixed according to glacier. Just adding a test so it can be closed.
Can anybody tell me why the github keywords do not work? 🤔
Please edit this post if you can fix it.
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
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
Add #[must_use] to From::from and Into::into
Risk of churn: **High**
Magic 8-Ball says: **Outlook not so good**
I figured I'd put this out there. If we don't do it now maybe we save it for a rainy day.
Parent issue: #89692
r? `@joshtriplett`
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
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
Add #[must_use] to alloc constructors
Added `#[must_use]`. to the various forms of `new`, `pin`, and `with_capacity` in the `alloc` crate. No extra explanations given as I couldn't think of anything useful to add.
I figure this deserves extra scrutiny compared to the other PRs I've done so far. In particular:
* The 4 `pin`/`pin_in` methods I touched. Are there legitimate use cases for pinning and not using the result? Pinning's a difficult concept I'm not very comfortable with.
* `Box`'s constructors. Do people ever create boxes just for the side effects... allocating or zeroing out memory?
Parent issue: #89692
r? ``@joshtriplett``
Cleanup src/test/ui/{simd,simd-intrinsic}
Initial motivation was to simplify a huge macro expansion using a tuple, since we can just use an array in `#[repr(simd)]` now for the same result. But also, several tests were going unnoticed during development of SIMD intrinsics because people kept looking in the wrong directory, and many are basically run-pass vs. build-fail versions of the same tests, so let's keep them close together and simplify their names, so they're easier to sift through.
