Use more precise span for E0282 in cast expressions
This pull request fixes#85586. The example code given there:
```rust
fn main() {
let a = [1, 2, 3].iter().sum();
let b = (a + 1) as usize;
}
```
currently produces
```
error[E0282]: type annotations needed
--> issue-85586.rs:3:13
|
3 | let b = (a + 1) as usize;
| ^^^^^^^^^^^^^^^^ cannot infer type
|
= note: type must be known at this point
error: aborting due to previous error
```
even though the type of the entire cast expression quite clearly should be `usize`. The error is in the cast's left-hand side, which is made explicit by the changes in this PR:
```
error[E0282]: type annotations needed
--> issue-85586.rs:3:13
|
3 | let b = (a + 1) as usize;
| ^^^^^^^ cannot infer type
|
= note: type must be known at this point
error: aborting due to previous error
```
Add feature gates for `for` and `?` in consts
These operations seems *relatively* straightforward to support, and only seem to be blocked on `impl const Trait`.
I have included a working test for `const_try`, but `const_for` is currently unusable without reimplementing *every single* defaulted `Iterator` method, so I didn't do that.
(both features still need tracking issues before this is merged)
Rollup of 10 pull requests
Successful merges:
- #87052 (Optimize fmt::PadAdapter::wrap)
- #87522 (Fix assert in diy_float)
- #87553 (Fix typo in rustc_driver::version)
- #87554 (2229: Discr should be read when PatKind is Range)
- #87564 (min_type_alias_impl_trait is going to be removed in 1.56)
- #87574 (Update the examples in `String` and `VecDeque::retain`)
- #87583 (Refactor compression cache in v0 symbol mangler)
- #87585 (Add missing links for core::char types)
- #87594 (fs File get_path procfs usage for netbsd same as linux.)
- #87602 ([backtraces]: look for the `begin` symbol only after seeing `end`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Refactor compression cache in v0 symbol mangler
* Remove redundant option around compression caches (they are always present).
* Flatten compression caches into symbol mangler to avoid dynamic memory allocation.
* Implement printer for `&mut SymbolMangler` instead of `SymbolMangler` to avoid passing now slightly larger symbol mangler by value.
min_type_alias_impl_trait is going to be removed in 1.56
#87501 removed `min_type_alias_impl_trait` but meanwhile that PR was approved in homu queue, a new beta was cut so we need to bump the version because it won't be removed in 1.55.
r? ```@oli-obk```
```@bors``` rollup=always
2229: Discr should be read when PatKind is Range
This PR fixes an issue related to pattern matching in closures when Edition 2021 is enabled.
- If any of the patterns the discr is being matched on is `PatKind::Range` then the discr should be read
r? ```@nikomatsakis```
Closes https://github.com/rust-lang/rust/issues/87426
Mir borrowck does not generate lifetime variables for 'static lifetimes during opaque type resolution
Fixes#87455
This situation was unreachable before #87287 as we used to just grab the resolved opaque type from typeck and replaced all regions with new inference vars. After #87287 we let the `InferCx` in mir borrowck figure out the opaque type all by itself (which it already did before, but it only used the result to sanity check with the typeck result).
The compression caches currently don't have any dedicated functionality
that would benefit from being separated. Incorporating caches directly
into the symbol manger also avoids dynamic memory allocation.
The symbol mangler, which is often passed by value, is now slightly
larger. This aspect will be addressed by a follow-up commit.
Make const panic!("..") work in Rust 2021.
During const eval, this replaces calls to core::panicking::panic_fmt and std::panicking::being_panic_fmt with a call to a new const fn: core::panicking::const_panic_fmt. That function uses fmt::Arguments::as_str() to get the str and calls panic_str with that instead.
panic!() invocations with formatting arguments are still not accepted, as the creation of such a fmt::Arguments cannot be done in constant functions right now.
r? `@RalfJung`
Create `QuerySideEffects` and use it for diagnostics
The code for saving and loading diagnostics during execution is generalized to handle a new `QuerySideEffects` struct. Currently, this struct just holds diagnostics - in a follow-up PR, I plan to add support for storing attriutes marked as used during query execution.
This is a pure refactor, with no intended behavior changes.
During const eval, this replaces calls to core::panicking::panic_fmt and
std::panicking::being_panic_fmt with a call to a new const fn:
core::panicking::const_panic_fmt. That function uses
fmt::Arguments::as_str() to get the str and calls panic_str with that
instead.
panic!() invocations with formatting arguments are still not accepted,
as the creation of such a fmt::Arguments cannot be done in constant
functions right now.
Support -Z unpretty=thir-tree again
Currently `-Z unpretty=thir-tree` is broken after some THIR refactorings. This re-implements it, making it easier to debug THIR-related issues.
We have to do analyzes before getting the THIR, since trying to create THIR from invalid HIR can ICE. But doing those analyzes requires the THIR to be built and stolen. We work around this by creating a separate query to construct the THIR tree string representation.
Closes https://github.com/rust-lang/project-thir-unsafeck/issues/8, fixes#85552.
Implement RFC 3107: `#[derive(Default)]` on enums with a `#[default]` attribute
This PR implements RFC 3107, which permits `#[derive(Default)]` on enums where a unit variant has a `#[default]` attribute. See comments for current status.
Stabilize `const_fn_transmute`, `const_fn_union`
This PR stabilizes the `const_fn_transmute` and `const_fn_union` features. It _does not_ stabilize any methods (obviously aside from `transmute`) that are blocked on only these features.
Closes#53605. Closes#51909.
Combine two loops in `check_match`
Suggested by Nadrieril in
https://github.com/rust-lang/rust/pull/79051#discussion_r548778186.
Opening to get a perf run. Hopefully this code doesn't require everything in the
first loop to be done before running the second! (It shouldn't though.)
cc `@Nadrieril`
