Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

regression: type annotations needed #125196

Closed
BoxyUwU opened this issue May 17, 2024 · 5 comments
Closed

regression: type annotations needed #125196

BoxyUwU opened this issue May 17, 2024 · 5 comments
Assignees
@compiler-errors
Labels
P-critical Critical priority regression-from-stable-to-beta Performance or correctness regression from stable to beta. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Milestone
1.79.0

Comments

@BoxyUwU
Copy link
Member

BoxyUwU commented May 17, 2024 

[INFO] [stdout] error[E0284]: type annotations needed
[INFO] [stdout]   --> src/apply.rs:81:7
[INFO] [stdout]    |
[INFO] [stdout] 81 |     b.apply(a.fmap(|x: A| f(move |_| x.clone())))
[INFO] [stdout]    |       ^^^^^ cannot infer type for struct `ApplyFn<'a, B, _>`
[INFO] [stdout]    |
[INFO] [stdout]    = note: cannot satisfy `<MB as Apply<'a, B>>::Target<ApplyFn<'a, B, _>> == _`
@BoxyUwU BoxyUwU added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. regression-from-stable-to-beta Performance or correctness regression from stable to beta. labels May 17, 2024
@rustbot rustbot added I-prioritize Issue: Indicates that prioritization has been requested for this issue. needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels May 17, 2024
@BoxyUwU BoxyUwU mentioned this issue May 17, 2024
Closed
@BoxyUwU BoxyUwU added this to the 1.79.0 milestone May 17, 2024
@compiler-errors
Copy link
Member

Probably due to #119849 weakening inference

@compiler-errors compiler-errors added the E-needs-bisection Call for participation: This issue needs bisection: https://github.com/rust-lang/cargo-bisect-rustc label May 17, 2024
@lqd
Copy link
Member

lqd commented May 17, 2024

Seemingly to #123537.

@rustbot label -E-needs-bisection

@rustbot rustbot removed the E-needs-bisection Call for participation: This issue needs bisection: https://github.com/rust-lang/cargo-bisect-rustc label May 17, 2024
@compiler-errors
Copy link
Member

🤦 I think I know the bug in #123537.

@compiler-errors compiler-errors mentioned this issue May 17, 2024
Merged
@compiler-errors compiler-errors self-assigned this May 17, 2024
@saethlin saethlin removed the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label May 18, 2024
jieyouxu added a commit to jieyouxu/rust that referenced this issue May 18, 2024
@jieyouxu
Rollup merge of rust-lang#125214 - compiler-errors:gat-guide, r=lcnr
f08746a 
Only make GAT ambiguous in `match_projection_projections` considering shallow resolvability

In rust-lang#123537, I tweaked the hack from rust-lang#93892 to use `resolve_vars_if_possible` instead of `shallow_resolve`. This considers more inference guidance ambiguous. This resulted in crater regressions in rust-lang#125196.

I've effectively reverted the change to the old behavior. That being said, I don't *like* this behavior, but I'd rather keep it for now since rust-lang#123537 was not meant to make any behavioral changes. See the attached example.

This also affects the new solver, for the record, which doesn't have any rules about not guiding inference from param-env candidates which may constrain GAT args as a side-effect.

r? `@lcnr` or `@jackh726`
rust-timer added a commit to rust-lang-ci/rust that referenced this issue May 18, 2024
@rust-timer
Unrolled build for rust-lang#125214
e0e1b81 
Rollup merge of rust-lang#125214 - compiler-errors:gat-guide, r=lcnr

Only make GAT ambiguous in `match_projection_projections` considering shallow resolvability

In rust-lang#123537, I tweaked the hack from rust-lang#93892 to use `resolve_vars_if_possible` instead of `shallow_resolve`. This considers more inference guidance ambiguous. This resulted in crater regressions in rust-lang#125196.

I've effectively reverted the change to the old behavior. That being said, I don't *like* this behavior, but I'd rather keep it for now since rust-lang#123537 was not meant to make any behavioral changes. See the attached example.

This also affects the new solver, for the record, which doesn't have any rules about not guiding inference from param-env candidates which may constrain GAT args as a side-effect.

r? `@lcnr` or `@jackh726`
@apiraino
Copy link
Contributor

WG-prioritization assigning priority (Zulip discussion).

Revert in #125214, thanks @compiler-errors !

@rustbot label -I-prioritize +P-critical

@rustbot rustbot added P-critical Critical priority and removed I-prioritize Issue: Indicates that prioritization has been requested for this issue. labels May 21, 2024
@wesleywiser
Copy link
Member

Closing since #12514 was backported to beta.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@compiler-errors compiler-errors

Labels
P-critical Critical priority regression-from-stable-to-beta Performance or correctness regression from stable to beta. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
1.79.0
Development

No branches or pull requests
7 participants
@lqd @wesleywiser @compiler-errors @apiraino @saethlin @BoxyUwU @rustbot