0.9.0

Although the version number increased by quite a bit this release in itself is
fairly small. Seeing how the ruby-lint internals are slowly becoming more and
more stable I'd like the version numbers to correspond with that. I'm not
jumping to 1.0 right away since I do want to make various changes to the
internals before I release 1.0.

Having said that, this release contains the following:

• Caching of ASTs required for finding externally defined constants.
• An extra CLI command (plot) for plotting analysis timings.
• Method call tracking.
• Warnings for unused method/block arguments.
• Support for Rubinius 2.0.

The two most noteworthy changes are the caching system and support for method
call tracking, these are highlighted below.

Caching

In previous releases ruby-lint would re-parse extra files needed (those that
contain the definitions of referenced constants) every time you'd analyze a
file. This was rather problematic since [parser][parser] sadly isn't the
fastest kid on the block. By caching the resulting ASTs performance of the same
file (assuming it doesn't change between runs) can be increased drastically. If
the analyzed file or an external one is changed the cache is invalidated
automatically.

Caching is enabled by default so you don't need to add any extra command-line
flags or configuration options in your ruby-lint configuration file.

Method Call Tracking

This new features makes it possible for ruby-lint to keep track of what methods
are called from another method, both in the direction of caller to callee and
the other way around. Currently this isn't used yet for any analysis but I have
some ideas on adding useful analysis using this new feature. Another use case
for this feature is generating Graphviz call graphs without actually having to
run the corresponding Ruby source code.

0.0.5

Originally slated for August 1st I decided to push this release back one month
to buy myself some extra time to polish features, resolve more bugs and
procrastinate more. Besides numerous bug fixes and extra polish this release
contains two big new features that I'd like to highlight:

• support for parsing basic YARD tags
• loading of externally defined constants/files from the local file system

YARD Support

YARD provides a set of tags that can aid in documenting your code. For
example, @param is a tag used to document the type, name and description of a
method parameter. Since Ruby has no form of type hinting you're often left to
wonder what kind of objects a method can work with.

In version 0.0.5 support for two tags was added:

• @param
• @return

When ruby-lint finds methods documented using these tags it will use them to
pull in information about the parameter types and return values. This greatly
increases the accuracy of ruby-lint, given your code is documented. Consider
the following example:

def multiply(value, multiplier)
  return value * value
end

If ruby-lint were to process the above code it would have no idea what kind of
object value and multiplier are and thus wouldn't be able to much with the
above code. When documenting the above method with the mentioned YARD tags
ruby-lint is capable of doing this:

##
# @param [Fixnum] value
# @param [Fixnum] multiplier
# @return [Fixnum]
#
def multiply(value, multiplier)
  return value * value
end

By parsing the YARD tags ruby-lint can now know what the parameter types are
and what type of data the method returns. This in turn allows ruby-lint to
perform full analysis on the arguments instead of being forced to ignore them
completely.

Loading External Files

In previous versions ruby-lint had no way of loading external code that was not
pre-defined using the built-in definitions (found in
lib/ruby-lint/definitions). As a result a lot of false positives would be
triggered when analysing complex projects (e.g. the typical Rails project).

This has been addressed by introducing so called "file scanners" and "file
loaders". In short, these scan for a set of constants used in a file and try to
find the corresponding Ruby file that defines it (recursively). This greatly
enhances the accuracy of analysis.

Currently the algorithm for this is rather basic and can, especially in big
projects, slow analysis down by quite a bit. This will be resolved in upcoming
releases. Keep an eye on the following issues for more information:

• https://github.com/YorickPeterse/ruby-lint/issues/50
• https://github.com/YorickPeterse/ruby-lint/issues/49

Other Changes

Besides the two features mentioned above various other changes have also been
made, these are listed below.

• Lots of bug fixes and cleanups, as you'd expect.
• Constants (classes and modules) can now be referred by their name inside
  themselves (e.g. "Foo" inside the class "Foo" refers to that class).
• The text presenter now only shows filenames instead of the full file path,
  reducing clutter.
• Support for default global variables such as $LOADED_FEATURES
• Support for methods such as alias and alias_method
• Support for the attr_* family of methods
• The test suite has been migrated from Bacon to RSpec
• Support for keyword arguments.
• Updated built-in Rails definitions to include more methods.
• Debugging/benchmarking output for the analyze command.
• The analysis class ConfusingVariables has been removed due to not being very
  useful.
• Various issues with method lookups inside blocks have been resolved.
• Various internals have been cleaned up.
• Improved error messages for calls to undefined methods.

0.0.4

This release contains a massive set of changes related to parsing Ruby source
code, the way definitions are built, how the code is laid out and much more.

The custom built parser based on Ripper has been removed in favour of the
"parser" Gem. This alone solves me a tremendous amount of work since I can
focus on writing analysis (and related) code instead of having to maintain my
own parser. It's also maintained by @whitequark and he knows a hell of a lot
more about parsing Ruby code than I do.

Another big change is the new addition of the so called "ruby-lint virtual
machine". This VM/partial evaluator takes care of building definitions based on
a Ruby AST but in a much saner/nicer way than previous releases of ruby-lint.

Besides that the process of writing analysis classes has been made easier, bugs
have been squashed, code has been refactored and tests have been expanded.

Having said all that, ruby-lint is still a young project and there will be
bugs, false positives and otherwise weird behaviour.