Skip to content

Check that the bounds of impl are implied by trait in a more general way #20020

New issue

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

#

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

Already on GitHub? # to your account

Jump to bottom
Closed
nikomatsakis opened this issue Dec 19, 2014 · 4 comments
Closed

Check that the bounds of impl are implied by trait in a more general way #20020

nikomatsakis opened this issue Dec 19, 2014 · 4 comments
Labels
A-trait-system Area: Trait system A-type-system Area: Type system
Milestone
1.0 beta

Comments

@nikomatsakis
Copy link
Contributor

Currently we check that the where clauses on an impl are consistent with a trait by examining the TypeParameterDefs, and also with some specialized code around regions. This is not consistent with generalized where clauses. Probably the right approach is to:

  1. Create a ParameterEnvironment that contains the bounds from the trait method, substituted appropriately so that they are in the namespace of the impl.
  2. Create a fresh inference and fulfillment context.
  3. Register each bound in the impl method in that fulfillment context and then run select_all_or_error(). If any errors result, that indicates a bound in the impl that does not appear in the trait.
  4. We have to remember to also run resolve_regions_and_report_errors() as well to check for region obligations that are not satisfiable.

We may want to take some care here with respect to error messages; we probably want to print something more helpful about how there is a mismatch between the trait and impl.
@nikomatsakis nikomatsakis changed the title Checking that the bounds on an impl are consistent with the trait should be done with where clauses Check that the bounds of impl are implied by trait in a more general way Dec 19, 2014
@nikomatsakis nikomatsakis mentioned this issue Dec 19, 2014
Open
@brson brson mentioned this issue Dec 19, 2014
Closed
7 tasks
@nikomatsakis nikomatsakis mentioned this issue Dec 21, 2014
Closed
@nikomatsakis
Copy link
Contributor Author

When fixing this, be sure that #20107 is fixed too.

@jroesch jroesch mentioned this issue Dec 29, 2014
Merged
@nikomatsakis nikomatsakis added this to the 1.0 alpha milestone Jan 6, 2015
@nikomatsakis
Copy link
Contributor Author

Putting this on 1.0 alpha as a (very) nice to have. @jroesch is working on it.

@nikomatsakis
Copy link
Contributor Author

Motivation is that it will help guide people to not write illegal programs :)

@jroesch jroesch mentioned this issue Jan 8, 2015
Closed
@nikomatsakis nikomatsakis modified the milestones: 1.0 beta, 1.0 alpha Jan 9, 2015
bors added a commit that referenced this issue Jan 15, 2015
@bors
auto merge of #20290 : jroesch/rust/generalize-impl-bounds, r=nikomat…
451e134 
…sakis

This should fix both #20020 and #20107. This moves out the code into its own file.

I have a couple concerns that can either be addressed in this PR or in a future one.

- The error reporting for the fulfillment context should be span aware because currently it is attached to the top
  of the file which is less then desirable.
- There is a failure in the test file: run-pass/issue-2611-3.rs, this seems like it should be a failure to me, but I am not sure.

As a nit I'm not enthused about the file name, and am open to better suggestions. 

r? @nikomatsakis
@kmcallister kmcallister added A-type-system Area: Type system A-trait-system Area: Trait system labels Jan 16, 2015
@flaper87
Copy link
Contributor

I believe this has been fixed by #20290

closing

# for free to join this conversation on GitHub. Already have an account? # to comment
Assignees
No one assigned
Labels
A-trait-system Area: Trait system A-type-system Area: Type system
Projects
None yet
Milestone
1.0 beta
Development

No branches or pull requests
3 participants
@flaper87 @nikomatsakis @kmcallister