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

Make some of the ast_util functions into methods #30058

Closed
Manishearth opened this issue Nov 25, 2015 · 9 comments
Closed

Make some of the ast_util functions into methods #30058

Manishearth opened this issue Nov 25, 2015 · 9 comments
Assignees
Labels
E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-help-wanted Call for participation: Help is requested to fix this issue.

Comments

@Manishearth
Copy link
Member

https://github.com/rust-lang/rust/blob/master/src/libsyntax/ast_util.rs

Things like

pub fn stmt_id(s: &Stmt) -> Option<NodeId>

should instead be

impl Stmt {
    pub fn id(s: &Stmt) -> Option<NodeId> {..}
}

The same goes for many other functions that take their first argument as an AST type (BinOp, Stmt, IntTy, Path, Ident, etc. Similarly, functions like these could be Generics::empty() instead.

(Feel free to keep it in the same file or move it to ast.rs)

@Manishearth Manishearth added E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. A-refactor E-help-wanted Call for participation: Help is requested to fix this issue. labels Nov 25, 2015
@faineance
Copy link
Contributor

Is this up for grabs? I'd like to start contributing to Rust.

@faineance
Copy link
Contributor

I presume I'd need to update all usage across the codebase.

@faineance
Copy link
Contributor

I've just noticed a bunch of the extremely similar functions declared in here what's up with that?

@jonas-schievink
Copy link
Contributor

@faineance These are part of the HIR, they should probably be made into methods as well

@faineance
Copy link
Contributor

What do you think about refactoring them into traits?

@jonas-schievink
Copy link
Contributor

I'd prefer plain methods, since that allows to change the HIR without changing the trait or AST - which is basically the point of the HIR. It would also have exactly 2 implementors - AST and HIR - and probably never gain more than that, which makes it a bit useless.

@faineance
Copy link
Contributor

Good point, thanks.

@Manishearth
Copy link
Member Author

Yes, this is up for grabs. Feel free to work on it!

The HIR and AST should stay separate as they will slowly diverge over time.

@Manishearth Manishearth self-assigned this Nov 25, 2015
bors added a commit that referenced this issue Dec 15, 2015
Issue: #30058
Updated for:
 - Stmt
 - BinOp_
 - UnOp
 - UintTy, IntTy and FloatTy
 - Lit
 - Generics

A possible inconsistancy?
The `Stmt` methods are on the spanned varient:
```rust
pub type Stmt = Spanned<Stmt_>;

impl Stmt {
    pub fn id(s: &Stmt) -> Option<NodeId> {
        match s.node {
          StmtDecl(_, id) => Some(id),
          StmtExpr(_, id) => Some(id),
          StmtSemi(_, id) => Some(id),
          StmtMac(..) => None,
      }
  }
}
```
Whilst the methods for BinOp are on the non spanned version.
````rust
impl BinOp_ {
    pub fn to_string(op: BinOp_) -> &'static str { ... }
    pub fn lazy(b: BinOp_) -> bool { ... }

    pub fn is_shift(b: BinOp_) -> bool { ... }
    pub fn is_comparison(b: BinOp_) -> bool { ... }
    /// Returns `true` if the binary operator takes its arguments by value
    pub fn is_by_value(b: BinOp_) -> bool { ... }

}
pub type BinOp = Spanned<BinOp_>;
````
r? @Manishearth
@Manishearth
Copy link
Member Author

#30105

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-help-wanted Call for participation: Help is requested to fix this issue.
Projects
None yet
Development

No branches or pull requests

3 participants