Signature based API comparison


#9

Sure, that sounds fun. I haven’t worked with the compiler plugin api yet, bit perhaps we could bounce a few ideas around.


#10

I currently investigate how the availability of the public API of a package in a comparable format can result in tools and lint passes which help maintain a higher quality of rust software (generating drop-in replacements, aided translation between versions, linguistic consistency checking, …). Maybe this turns into a diploma thesis. If not, @hoodie and I want nevertheless to build API comparison :smile:


#11

@payload That sounds very applicable! What sort of comparable format do you have in mind?

Please keep me updated on your progress.


#12

Is there a way to make a signature more general while keeping it API compatible? I was thinking of something along the lines of fn foo(path: &Path) -> fn foo<P: AsRef<Path>>(path: P), but that particular case does change the API in a small way.

But I guess you can convert a concrete type into a trait, so long as that type already implemented the trait.


#13

Not if a caller was relying on type information provided by the argument type.

For example, you can’t do Into::into(From::from(v)), because the compiler cannot possibly know what intermediate type it’s supposed to use. So if you’d been passing an argument as From::from(v), and the type changes from some concrete T to U: Into<T>, calling code can stop working.


#14

I just don’t know the format yet. Inspirations come from hackage-diff and elm-package. Both use a mix of parser and documentation generator types and structures. None export the format. I hope it is a format which is almost rust code :slight_smile: human readable. But diffing is usually structural, not text line based.


#15

An idea would be to diff the public branches of the AST itself. When you go top down it could even save some time because you can neglect children of the parents already don’t match.


#16

I wonder if the recent refactor work on HIR/MIR could be of use. However, I don’t know what these formats will contain, or if it’s possible to access them for this at all.


#17

@hoodie, yes, but I would ask hoogle (hackage-diff) and elm-package maintainers why they chose to go the documentation path. Maybe it is just for printing parts of the documentation along the diff. Somewhere the haskell tools also use a parser, but they noted that cause of conditional compilation this parsing may fail. Interesting interesting.
But you are of course right. libsyntax changes are not that scary and one can just traverse the AST in a LintPass compiler plugin or something.
I hope exams are over soon. I want to build stuff!


#18

Thanks for pointing us to HIR/MIR :slight_smile:


#19

And of course I need to look into racer.


#20

And cargo doc :stuck_out_tongue_winking_eye:


#21

Ooh, sorry for letting this slip by. @payload @hoodie any progress in this direction? Is there anything I can do to unblock you?


#22

No problem, we are both currently looking into making this a research project, because we’re both currently looking for a thesis topic. So if we get that through, one of us is gonna make this solid. If not however, I think we are still going to hack it. So give us a week or to two, to do some more research.

If you however have any idea to ake this a bit more complex, so it would be easier to formulate a thesis topic that would keep somebody busy for about 3-4 months, that would be great :smiley:


#23

Just in case we need to answer such research questions like “How was software quality improved?”, we maybe need something in rust/cargo nightly early on. But we are still discussing research questions and the complexity of the work. I hope next week we meet the professor.


#24

For what it’s worth, the minimal thing I want in a tool is: take two pieces of source code and their semver versions, say ‘yes, this is a valid change’, ‘no, this is not a valid change’. A very simple version might just find all regular functions with identical paths and flag any changes the arguments as invalid.


#25

Elm’s package manager does automatic semver enforcement based on a package’s exposed types:

Versions are incremented based on how the API changes:

  • PATCH - the API is the same, no risk of breaking code
  • MINOR - values have been added, existing values are unchanged
  • MAJOR - existing values have been changed or removed

elm-package will bump versions for you, automatically enforcing these rules

Might be useful food for thought.

Edit: Ok, it seems to have already been mentioned in a quote in the opening post. Woopsie!


#26

Still useful for people who (like me) did not read that. :wink:


#27

Okay, there will be no thesis on that. So @hoodie and I are going to do it in our free time in the next two weeks.


#28

@hoodie @payload FYI we’re interested in having an intern work on a semver validation project next summer. If you haven’t, you might consider applying.