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.

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

Cast suggestions #38099

Merged
merged 22 commits into from
Dec 21, 2016
Merged

Cast suggestions #38099

merged 22 commits into from
Dec 21, 2016

Conversation

GuillaumeGomez
Copy link
Member

self.fcx.associated_item(def_id, self.item_name)
match self.looking_for {
LookingFor::MethodName(item_name) => self.fcx.associated_item(def_id, item_name),
_ => None,
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nikomatsakis: This matching is invalid, but I don't know what to put here. We don't have a method name to refer to, just a return type. Won't it always return the same method if I match on it?

@eddyb: Maybe you have an idea here?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this method should go away. Callers can just use impl_or_trait_item instead. I've got a local branch doing that (might also try modifying impl_or_trait_item to return impl Iterator, since right now it only considers the first method that matches the return type...?)

Copy link
Contributor

@nikomatsakis nikomatsakis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking good. You're right about associated_item being wrong now though.

@@ -1364,9 +1364,9 @@ impl<'a, 'gcx, 'tcx> InferCtxt<'a, 'gcx, 'tcx> {
cause: &ObligationCause<'tcx>,
expected: Ty<'tcx>,
actual: Ty<'tcx>,
err: TypeError<'tcx>) {
err: TypeError<'tcx>) -> DiagnosticBuilder<'tcx> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: newline before -> here

fn format_method_suggestion(&self, method: &AssociatedItem) -> String {
format!(".{}({})",
method.name,
if self.has_not_input_arg(method) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not: has_no_input_arg or does_not_have_input_arg or !self.has_input_arg :)

self.fcx.associated_item(def_id, self.item_name)
match self.looking_for {
LookingFor::MethodName(item_name) => self.fcx.associated_item(def_id, item_name),
_ => None,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this method should go away. Callers can just use impl_or_trait_item instead. I've got a local branch doing that (might also try modifying impl_or_trait_item to return impl Iterator, since right now it only considers the first method that matches the return type...?)

|
= note: expected type `&mut std::string::String`
= note: found type `&std::string::String`
= help: try with `&mut y`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are these changes that suggest a & still in the PR?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I couldn't test since the current code was wrong. Once updated, this will follow.

@nikomatsakis
Copy link
Contributor

OK, so, I pushed a quick fix, but we still fail 3 compile-fail tests. I'm not 100% sure why, didn't dig into it yet:

    [compile-fail] compile-fail/issue-5500.rs
    [compile-fail] compile-fail/occurs-check-2.rs
    [compile-fail] compile-fail/occurs-check.rs

each of them fails with a rather useless "error: the type of this value must be known in this context".

@GuillaumeGomez
Copy link
Member Author

@nikomatsakis: We have an issue. With the current code, it only returns one proposition. For example for the following code:

fn foo(_x: String) {}

fn main() {
    foo("a");
}

It proposes only replace method while other methods are also available. This is a huge step back, at least the first versions were able to propose multiple propositions. :-/

@nikomatsakis
Copy link
Contributor

We have an issue. With the current code, it only returns one proposition. For example for the following code:

I think that is because the impl_or_trait_item method returns Option and not Vec (or impl Iterator). Should be easily fixed, but I didn't do it yesterday because I was more concerned about the type inference regressions, which seemed worth fixing.

@GuillaumeGomez
Copy link
Member Author

Indeed. I'll give it a try then.

@GuillaumeGomez
Copy link
Member Author

GuillaumeGomez commented Dec 3, 2016

Ok, so I fixed this issue. Code is a bit ugly unfortunately. We still have the same failure for the 3 tests.

EDIT: Oh also, suggestions are completely stupid haha.

@bors
Copy link
Contributor

bors commented Dec 3, 2016

☔ The latest upstream changes (presumably #38079) made this pull request unmergeable. Please resolve the merge conflicts.

@nikomatsakis
Copy link
Contributor

@GuillaumeGomez I pushed a commit that cleans up the code a bit, but I still see various failures around inference that I think we need to track down:

failures:
    [compile-fail] compile-fail/issue-5500.rs
    [compile-fail] compile-fail/occurs-check-2.rs
    [compile-fail] compile-fail/occurs-check.rs

@nikomatsakis
Copy link
Contributor

OK, I see those errors were the cause of your changes to not call unambiguous_final_ty. I've pushed a commit with an alternative approach there that I think will fix those test cases.

BTW, did you have some suggestion tests that were failing because of the fact that we were returning an Option from impl_or_trait_item() instead of a Vec?

@GuillaumeGomez
Copy link
Member Author

I ran make check-stage3 and didn't have other failures. So I guess we're good?

@GuillaumeGomez
Copy link
Member Author

I fixed the linter as well.

@nikomatsakis
Copy link
Contributor

@GuillaumeGomez still some kind of issue...

@GuillaumeGomez
Copy link
Member Author

@nikomatsakis: If you're referring to travis' failure, it seems normal. If not, then what are you referring to?

@nikomatsakis
Copy link
Contributor

@GuillaumeGomez

I see this, is that normal?

error: attempted to take value of method `inputs` on type `&rustc::ty::FnSig<'_>`

   --> /checkout/src/librustc_typeck/check/demand.rs:118:47

    |

118 |                         fty.sig.skip_binder().inputs.len() == 1

    |                                               ^^^^^^

    |

    = help: maybe a `()` to call it is missing? If not, try an anonymous function

@nikomatsakis
Copy link
Contributor

I guess that particular configuration does seem to typically have a travis failure of some kind.

@Mark-Simulacrum
Copy link
Member

I think that error might be from #38097, where inputs became a function on FnSig. I assume this was either somehow missed in that, or added in this PR and as such not covered.

@GuillaumeGomez
Copy link
Member Author

Uh?! I guess I failed my update and my rebuild... Taking another look then.

@GuillaumeGomez
Copy link
Member Author

GuillaumeGomez commented Dec 13, 2016

So as I thought, I needed to rebase once again. Now it's fixed and tests are passing again.

@nikomatsakis
Copy link
Contributor

@GuillaumeGomez sadly it seems like travis is still unhappy! The coerce-suggestions test still seems to be failing :(

Some of the output:

diff of stderr:

 20 - |   = help: try with `&String::new()`|
    + |   = help: here are some functions which might fulfill your needs:|
 21 - ||
    + | - .as_str()|
...

@GuillaumeGomez
Copy link
Member Author

@nikomatsakis: Indeed, didn't see this one. Should be fixed now.

@GuillaumeGomez
Copy link
Member Author

And travis tests passed! \o/

@GuillaumeGomez
Copy link
Member Author

@nikomatsakis: no r+?

@nikomatsakis
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented Dec 20, 2016

📌 Commit 28e2c6a has been approved by nikomatsakis

@bors
Copy link
Contributor

bors commented Dec 21, 2016

⌛ Testing commit 28e2c6a with merge 439c312...

bors added a commit that referenced this pull request Dec 21, 2016
@bors bors merged commit 28e2c6a into rust-lang:master Dec 21, 2016
est31 added a commit to est31/rust that referenced this pull request Jan 15, 2017
This removes the safe_suggestion feature from feature_gate.rs.
It was added in commit 164f010
and then removed again in commit c11fe55 .

As the removal was in the same PR rust-lang#38099 as the addition, we don't move it to
the "removed" section.

Removes an element from the whitelist of non gate tested unstable lang features (issue rust-lang#39059).
bors added a commit that referenced this pull request Jan 15, 2017
Mark safe_suggestion and pushpop_unsafe as removed in feature_gate.rs

This removes two features from feature_gate.rs: `safe_suggestion` and `pushpop_unsafe`. Both had been removed in other places already, but were forgotten to be removed from feature_gate.rs.

* `safe_suggestion` was added in commit 164f010 and then removed again in commit c11fe55 both in the same PR #38099.

* `pushpop_unsafe` was added in commit 1829fa5 and removed again in commit d399098

Removes two elements from the whitelist of non gate tested unstable lang features (issue #39059).
bors added a commit that referenced this pull request Jan 16, 2017
Mark safe_suggestion and pushpop_unsafe as removed in feature_gate.rs

This removes two features from feature_gate.rs: `safe_suggestion` and `pushpop_unsafe`. Both had been removed in other places already, but were forgotten to be removed from feature_gate.rs.

* `safe_suggestion` was added in commit 164f010 and then removed again in commit c11fe55 both in the same PR #38099.

* `pushpop_unsafe` was added in commit 1829fa5 and removed again in commit d399098

Removes two elements from the whitelist of non gate tested unstable lang features (issue #39059).
@GuillaumeGomez GuillaumeGomez deleted the cast_suggestions branch November 24, 2017 20:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants