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

Refactor the way methods are stored in ast::ImplItem/TraitItem. #23265

Merged
merged 4 commits into from
Mar 12, 2015

Conversation

eddyb
Copy link
Member

@eddyb eddyb commented Mar 10, 2015

The end result is that common fields (id, name, attributes, etc.) are stored in now-structures ImplItem and TraitItem.
The signature of a method is no longer duplicated between methods with a body (default/impl) and those without, they now share MethodSig.

This is also a [breaking-change] because of minor bugfixes and changes to syntax extensions:

  • pub fn methods in a trait no longer parse - remove the pub, it has no meaning anymore
  • MacResult::make_methods is now make_impl_items and the return type has changed accordingly
  • quote_method is gone, because P<ast::Method> doesn't exist and it couldn't represent a full method anyways - could be replaced by quote_impl_item/quote_trait_item in the future, but I do hope we realize how silly that combinatorial macro expansion is and settle on a single quote macro + some type hints - or just no types at all (only token-trees)

r? @nikomatsakis This is necessary (hopefully also sufficient) for associated constants.

@@ -13,7 +13,7 @@ fn main() {
pub struct A; //~ ERROR: visibility has no effect
pub enum B {} //~ ERROR: visibility has no effect
pub trait C { //~ ERROR: visibility has no effect
pub fn foo(&self) {} //~ ERROR: visibility has no effect
fn foo(&self) {}
Copy link
Member

Choose a reason for hiding this comment

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

Why remove these privacy tests - are they no longer checked - that seems bad

Copy link
Member Author

Choose a reason for hiding this comment

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

They are parse errors now - I guess I should move them to parse-fail tests.

Copy link
Member

Choose a reason for hiding this comment

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

Ok, I think it's a good idea to move the tests rather than removing

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've added two parse-fail tests. I hope they're enough.

@eddyb eddyb force-pushed the meth-ast-refactor branch 2 times, most recently from f608bae to def8023 Compare March 11, 2015 05:45
@nrc nrc assigned nrc and nikomatsakis and unassigned nikomatsakis and nrc Mar 11, 2015
@nrc
Copy link
Member

nrc commented Mar 11, 2015

LGTM, r+, but I'll leave it for @nikomatsakis to make it official in case he has any thoughts about the AST design.

@nikomatsakis
Copy link
Contributor

@bors r+ 9da9185

@nikomatsakis
Copy link
Contributor

I've been wanting to do similar cleanup and consolidation forever. Nice.

@bors
Copy link
Contributor

bors commented Mar 12, 2015

⌛ Testing commit 9da9185 with merge c9b03c2...

bors added a commit that referenced this pull request Mar 12, 2015
The end result is that common fields (id, name, attributes, etc.) are stored in now-structures `ImplItem` and `TraitItem`.
The signature of a method is no longer duplicated between methods with a body (default/impl) and those without, they now share `MethodSig`.

This is also a [breaking-change] because of minor bugfixes and changes to syntax extensions:
* `pub fn` methods in a trait no longer parse - remove the `pub`, it has no meaning anymore
* `MacResult::make_methods` is now `make_impl_items` and the return type has changed accordingly
* `quote_method` is gone, because `P<ast::Method>` doesn't exist and it couldn't represent a full method anyways - could be replaced by `quote_impl_item`/`quote_trait_item` in the future, but I do hope we realize how silly that combinatorial macro expansion is and settle on a single `quote` macro + some type hints - or just no types at all (only token-trees)

r? @nikomatsakis This is necessary (hopefully also sufficient) for associated constants.
Manishearth pushed a commit to Manishearth/rust that referenced this pull request Mar 20, 2015
This fixes several use cases that were broken after rust-lang#23265 landed.
Manishearth added a commit to Manishearth/rust that referenced this pull request Mar 20, 2015
 This fixes several use cases that were broken after rust-lang#23265 landed.
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