* Point at RHS of associated type in obligation span
* Point at `impl` assoc type on projection error
* Reduce verbosity of recursive obligations
* Point at source of binding lifetime obligation
* Tweak "required bound" note
* Tweak "expected... found opaque (return) type" labels
* Point at set type in impl assoc type WF errors
Skip reborrows in AbstractConstBuilder
Fixes https://github.com/rust-lang/rust/issues/90455
Temporary fix to prevent confusing diagnostics that refer to implicit borrows and derefs until we allow borrows and derefs on constant expressions.
r? `@oli-obk`
Keep spans for generics in `#[derive(_)]` desugaring
Keep the spans for generics coming from a `derive`d Item, so that errors
and suggestions have better detail.
Fix#84003.
* Annotate `derive`d spans from the user's code with the appropciate context
* Add `Span::can_be_used_for_suggestion` to query if the underlying span
at the users' code
Rollup of 12 pull requests
Successful merges:
- #89954 (Fix legacy_const_generic doc arguments display)
- #91321 (Handle placeholder regions in NLL type outlive constraints)
- #91329 (Fix incorrect usage of `EvaluatedToOk` when evaluating `TypeOutlives`)
- #91364 (Improve error message for incorrect field accesses through raw pointers)
- #91387 (Clarify and tidy up explanation of E0038)
- #91410 (Move `#![feature(const_precise_live_drops)]` checks earlier in the pipeline)
- #91435 (Improve diagnostic for missing half of binary operator in `if` condition)
- #91444 (disable tests in Miri that take too long)
- #91457 (Add additional test from rust issue number 91068)
- #91460 (Document how `last_os_error` should be used)
- #91464 (Document file path case sensitivity)
- #91466 (Improve the comments in `Symbol::interner`.)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Fix incorrect usage of `EvaluatedToOk` when evaluating `TypeOutlives`
A global predicate is not guarnatenteed to outlive all regions.
If the predicate involves late-bound regions, then it may fail
to outlive other regions (e.g. `for<'b> &'b bool: 'static` does not
hold)
We now only produce `EvaluatedToOk` when a global predicate has no
late-bound regions - in that case, the ony region that can be present
in the type is 'static
Cleanup: Eliminate ConstnessAnd
This is almost a behaviour-free change and purely a refactoring. "almost" because we appear to be using the wrong ParamEnv somewhere already, and this is now exposed by failing a test using the unstable `~const` feature.
We most definitely need to review all `without_const` and at some point should probably get rid of many of them by using `TraitPredicate` instead of `TraitRef`.
This is a continuation of https://github.com/rust-lang/rust/pull/90274.
r? `@oli-obk`
cc `@spastorino` `@ecstatic-morse`
A global predicate is not guarnatenteed to outlive all regions.
If the predicate involves late-bound regions, then it may fail
to outlive other regions (e.g. `for<'b> &'b bool: 'static` does not
hold)
We now only produce `EvaluatedToOk` when a global predicate has no
late-bound regions - in that case, the ony region that can be present
in the type is 'static
Make `TypeFolder::fold_*` return `Result`
Implements rust-lang/compiler-team#432.
Initially this is just a rebase of `@LeSeulArtichaut's` work in #85469 (abandoned; see https://github.com/rust-lang/rust/pull/85485#issuecomment-908781112). At that time, it caused a regression in performance that required some further exploration... with this rebased PR bors can hopefully report some perf analysis from which we can investigate further (if the regression is indeed still present).
r? `@jackh726` cc `@nikomatsakis`
Prior to PR #91205, checking for errors in the overall obligation
would check checking the `ParamEnv`, due to an incorrect
`super_visit_with` impl. With this bug fixed, we will now
bail out of impl candidate assembly if the `ParamEnv` contains
any error types.
In practice, this appears to be overly conservative - when an error
occurs early in compilation, we end up giving up early for some
predicates that we could have successfully evaluated without overflow.
By only checking for errors in the predicate itself, we avoid causing
additional spurious 'type annotations needed' errors after a 'real'
error has already occurred.
With this PR, the diagnostic changes caused by PR #91205 are reverted.
Be more thorough in using `ItemObligation` and `BindingObligation` when
evaluating obligations so that we can point at trait bounds that
introduced unfulfilled obligations. We no longer incorrectly point at
unrelated trait bounds (`substs-ppaux.verbose.stderr`).
In particular, we now point at trait bounds on method calls.
We no longer point at "obvious" obligation sources (we no longer have a
note pointing at `Trait` saying "required by a bound in `Trait`", like
in `associated-types-no-suitable-supertrait*`).
Address part of #89418.
This function parameter attribute was introduced in https://github.com/rust-lang/rust/pull/44866 as an intermediate step in implementing `impl Trait`, it's not necessary or used anywhere by itself.
Fix span for non-satisfied trivial trait bounds
The spans for "trait bound not satisfied" errors in trivial trait bounds referenced the entire item (fn, impl, struct) before.
Now they only reference the obligation itself (`String: Copy`)
Address #90869
Fixes incorrect handling of TraitRefs when emitting suggestions.
Closes#90804 , although there were more issues here that were hidden by the thing that caused this ICE.
Underlying problem was that substitutions were being thrown out, which not only leads to an ICE but also incorrect diagnostics. On top of that, in some cases the self types from the root obligations were being mixed in with those from derived obligations.
This makes a couple diagnostics arguable worse ("`B<C>` does not implement `Copy`" instead of "`C` does not implement `Copy`") but the worse diagnostics are at least still correct and that downside is in my opinion clearly outweighed by the benefits of fixing the ICE and unambiguously wrong diagnostics.
The spans for "trait bound not satisfied" errors in trivial trait bounds referenced the entire item (fn, impl, struct) before.
Now they only reference the obligation itself (`String: Copy`)
Address #90869
When suggesting references, substitutions were being forgotten and some types were misused. This led to at
least one ICE and other incorrectly emitted diagnostics. This has been fixed; in some cases this leads to
diagnostics changing, and tests have been adjusted.
Rollup of 7 pull requests
Successful merges:
- #89561 (Type inference for inline consts)
- #90035 (implement rfc-2528 type_changing-struct-update)
- #90613 (Allow to run a specific rustdoc-js* test)
- #90683 (Make `compiler-docs` only control the default instead of being a hard off-switch)
- #90685 (x.py: remove fixme by deleting code)
- #90701 (Record more artifact sizes during self-profiling.)
- #90723 (Better document `Box` and `alloc::alloc::box_free` connection)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Type inference for inline consts
Fixes#78132Fixes#78174Fixes#81857Fixes#89964
Perform type checking/inference of inline consts in the same context as the outer def, similar to what is currently done to closure.
Doing so would require `closure_base_def_id` of the inline const to return the outer def, and since `closure_base_def_id` can be called on non-local crate (and thus have no HIR available), a new `DefKind` is created for inline consts.
The type of the generated anon const can capture lifetime of outer def, so we couldn't just use the typeck result as the type of the inline const's def. Closure has a similar issue, and it uses extra type params `CK, CS, U` to capture closure kind, input/output signature and upvars. I use a similar approach for inline consts, letting it have an extra type param `R`, and then `typeof(InlineConst<[paremt generics], R>)` would just be `R`. In borrowck region requirements are also propagated to the outer MIR body just like it's currently done for closure.
With this PR, inline consts in expression position are quitely usable now; however the usage in pattern position is still incomplete -- since those does not remain in the MIR borrowck couldn't verify the lifetime there. I have left an ignored test as a FIXME.
Some disucssions can be found on [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/inline.20consts.20typeck).
cc `````@spastorino````` `````@lcnr`````
r? `````@nikomatsakis`````
`````@rustbot````` label A-inference F-inline_const T-compiler
Use `is_global` in `candidate_should_be_dropped_in_favor_of`
This manifistated in #90195 with compiler being unable to keep
one candidate for a trait impl, if where is a global impl and more
than one trait bound in the where clause.
Before #87280 `candidate_should_be_dropped_in_favor_of` was using
`TypeFoldable::is_global()` that was enough to discard the two
`ParamCandidate`s. But #87280 changed it to use
`TypeFoldable::is_known_global()` instead, which is pessimistic, so
now the compiler drops the global impl instead (because
`is_known_global` is not sure) and then can't decide between the
two `ParamCandidate`s.
Switching it to use `is_global` again solves the issue.
Fixes#90195.
Revert "Add rustc lint, warning when iterating over hashmaps"
Fixes perf regressions introduced in https://github.com/rust-lang/rust/pull/90235 by temporarily reverting the relevant PR.
This manifistated in #90195 with compiler being unable to keep
one candidate for a trait impl, if where is a global impl and more
than one trait bound in the where clause.
Before #87280 `candidate_should_be_dropped_in_favor_of` was using
`TypeFoldable::is_global()` that was enough to discard the two
`ParamCandidate`s. But #87280 changed it to use
`TypeFoldable::is_known_global()` instead, which is pessimistic, so
now the compiler drops the global impl instead (because
`is_known_global` is not sure) and then can't decide between the
two `ParamCandidate`s.
Switching it to use `is_global` again solves the issue.
Fixes#90195.
Use the "nice E0277 errors"[1] for `!Send` `impl Future` from foreign crate
Partly address #78543 by making the error quieter.
We don't have access to the `typeck` tables from foreign crates, so we
used to completely skip the new code when checking foreign crates. Now,
we carry on and don't provide as nice output (we don't clarify *what* is
making the `Future: !Send`), but at least we no longer emit a sea of
derived obligations in the output.
[1]: https://blog.rust-lang.org/inside-rust/2019/10/11/AsyncAwait-Not-Send-Error-Improvements.html
r? `@tmandry`
Partly address #78543 by making the error quieter.
We don't have access to the `typeck` tables from foreign crates, so we
used to completely skip the new code when checking foreign crates. Now,
we carry on and don't provide as nice output (we don't clarify *what* is
making the `Future: !Send`), but at least we no longer emit a sea of
derived obligations in the output.
[1]: https://blog.rust-lang.org/inside-rust/2019/10/11/AsyncAwait-Not-Send-Error-Improvements.html
