| Age | Commit message (Collapse) | Author | Lines |
|---|
|
trait obligations for binops.
|
|
This reverts commit 08135254dcf22be0d5661ea8f75e703b29a83514.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Better error message for generic_const_exprs inference failure
Fixes #90531
This code:
```rs
#![feature(generic_const_exprs)]
fn foo<const N: usize>(_arr: [u64; N + 1]) where [u64; N + 1]: {}
fn main() {
let arr = [5; 5];
foo(arr);
}
```
Will now emit the following error:
```rs
warning: the feature `generic_const_exprs` is incomplete and may not be safe to use and/or cause compiler crashes
--> test.rs:1:12
|
1 | #![feature(generic_const_exprs)]
| ^^^^^^^^^^^^^^^^^^^
|
= note: `#[warn(incomplete_features)]` on by default
= note: see issue #76560 <https://github.com/rust-lang/rust/issues/76560> for more information
error[E0284]: type annotations needed
--> test.rs:8:7
|
8 | foo(arr);
| ^^^ cannot infer the value of the const parameter `N` declared on the function `foo`
|
note: required by a bound in `foo`
--> test.rs:3:56
|
3 | fn foo<const N: usize>(_arr: [u64; N + 1]) where [u64; N + 1]: {}
| ^^^^^ required by this bound in `foo`
help: consider specifying the generic argument
|
8 | foo::<N>(arr);
| +++++
error: aborting due to previous error; 1 warning emitted
```
cc: `@lcnr` thanks a lot again for the help on this
|
|
Move abstract const to middle
Moves AbstractConst (and all associated methods) to rustc middle for use in `rustc_infer`.
This allows for const resolution in infer to use abstract consts to walk consts and check if
they are resolvable.
This attempts to resolve the issue where `Foo<{ concrete const }, generic T>` is incorrectly marked as conflicting, and is independent from the other issue where nested abstract consts must be resolved.
r? `@lcnr`
|
|
Rollup of 5 pull requests
Successful merges:
- #97720 (Always create elided lifetime parameters for functions)
- #98315 (Stabilize `core::ffi:c_*` and rexport in `std::ffi`)
- #98705 (Implement `for<>` lifetime binder for closures)
- #99126 (remove allow(rustc::potential_query_instability) in rustc_span)
- #99139 (Give a better error when `x dist` fails for an optional tool)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
`ty::Const` doesn't have precomputed type flags, so
computing `has_vars_bound_at_or_above` for constants
requires us to visit the const and its contained types
and constants. A noop fold should be pretty much equally as
fast so removing it prevents us from walking the constant twice
in case it contains bound vars.
|
|
|
|
Implement `for<>` lifetime binder for closures
This PR implements RFC 3216 ([TI](https://github.com/rust-lang/rust/issues/97362)) and allows code like the following:
```rust
let _f = for<'a, 'b> |a: &'a A, b: &'b B| -> &'b C { b.c(a) };
// ^^^^^^^^^^^--- new!
```
cc ``@Aaron1011`` ``@cjgillot``
|
|
|
|
|
|
|
|
This is no longer used only for debugging options (e.g. `-Zoutput-width`, `-Zallow-features`).
Rename it to be more clear.
|
|
Lower let-else in MIR
This MR will switch to lower let-else statements in MIR building instead.
To lower let-else in MIR, we build a mini-switch two branches. One branch leads to the matching case, and the other leads to the `else` block. This arrangement will allow temporary lifetime analysis running as-is so that the temporaries are properly extended according to the same rule applied to regular `let` statements.
cc https://github.com/rust-lang/rust/issues/87335
Fix #98672
|
|
This helps bring `hir::Expr` size down, `Closure` was the biggest
variant, especially after `for<>` additions.
|
|
|
|
|
|
Some more `EarlyBinder` cleanups
First commit has a couple unrelated cleanups, but otherwise each commit is self-explanatory
r? rust-lang/types
|
|
|
|
|
|
|
|
Fix duplicated type annotation suggestion
Before, there was more or less duplicated suggestions to add type hints.
Fix by clearing more generic suggestions when a more specific suggestion
is possible.
This fixes #93506 .
|
|
|
|
r=lcnr
Do not mention private types from other crates as impl candidates
Fixes #99080
|
|
Deny float const params even when `adt_const_params` is enabled
Supersedes #98825
Fixes #98813
r? ``@oli-obk``
|
|
|
|
|
|
|
|
Remove duplicate notes from error on inter-crate ambiguous impl of traits
Fixes #99092
|
|
|
|
|
|
Avoid some `&str` to `String` conversions
This patch removes some `&str` to `String` conversions.
|
|
(fix #99092)
|
|
|
|
There are several indications that we should not ZST as a ScalarInt:
- We had two ways to have ZST valtrees, either an empty `Branch` or a `Leaf` with a ZST in it.
`ValTree::zst()` used the former, but the latter could possibly arise as well.
- Likewise, the interpreter had `Immediate::Uninit` and `Immediate::Scalar(Scalar::ZST)`.
- LLVM codegen already had to special-case ZST ScalarInt.
So instead add new ZST variants to those types that did not have other variants
which could be used for this purpose.
|
|
Before, there was more or less duplicated suggestions to add type hints.
Fix by clearing more generic suggestions when a more specific suggestion
is possible.
This fixes #93506 .
|
|
Track implicit `Sized` obligations in type params
When we evaluate `ty::GenericPredicates` we introduce the implicit
`Sized` predicate of type params, but we do so with only the `Predicate`
its `Span` as context, we don't have an `Obligation` or
`ObligationCauseCode` we could influence. To try and carry this
information through, we add a new field to `ty::GenericPredicates` that
tracks both which predicates come from a type param and whether that
param has any bounds already (to use in suggestions).
We also suggest adding a `?Sized` bound if appropriate on E0599.
Address part of #98539.
|
|
don't succeed `evaluate_obligation` query if new opaque types were registered
fixes #98608
fixes #98604
The root cause of all this is that in type flag computation we entirely ignore nongeneric things like struct fields and the signature of function items. So if a flag had to be set for a struct if it is set for a field, that will only happen if the field is generic, as only the generic parameters are checked.
I now believe we cannot use type flags to handle opaque types. They seem like the wrong tool for this.
Instead, this PR replaces the previous logic by adding a new variant of `EvaluatedToOk`: `EvaluatedToOkModuloOpaqueTypes`, which says that there were some opaque types that got hidden types bound, but that binding may not have been legal (because we don't know if the opaque type was in its defining scope or not).
|
|
r=michaelwoerister
Highlight conflicting param-env candidates
This could probably be further improved by noting _why_ equivalent param-env candidates (modulo regions) leads to ambiguity.
Fixes #98786
|
|
An optimization for `pest-2.1.3`
An easy win I found while looking at a profile of `pest-2.1.3`. It's also a small code cleanup.
r? `@pnkfelix`
|
|
|
|
|
|
|
