[#3479] Missing .document files for ext/ libraries — Brian Candler <B.Candler@...>

The ri documentation for zlib, strscan and iconv doesn't get built by 'make

12 messages 2004/10/06

[#3492] Re: ANN: Free-form-operators patch — Markus <markus@...>

> In message "Re: ANN: Free-form-operators patch"

15 messages 2004/10/11
[#3493] Re: ANN: Free-form-operators patch — Yukihiro Matsumoto <matz@...> 2004/10/11

Hi,

[#3495] Re: ANN: Free-form-operators patch — Markus <markus@...> 2004/10/12

On Mon, 2004-10-11 at 16:16, Yukihiro Matsumoto wrote:

[#3561] 1.8.2 - what can we do to help? — Dave Thomas <dave@...>

Folks:

23 messages 2004/10/26
[#3562] Re: 1.8.2 - what can we do to help? — Yukihiro Matsumoto <matz@...> 2004/10/27

Hi,

Location of missing end

From: Markus <markus@...>
Date: 2004-10-11 06:43:14 UTC
List: ruby-core #3486
Over the past week or so there has been a thread on ruby-talk ("Quality
of error messages") about the fact that a missing end is generally not
detected until the whole file has been parsed.  This makes it difficult
to find the location of the error.

I had suggested that it might be possible to make a good guess based on
a very liberal interpretation of common indentation styles.  I have a
patch which implements this at

http://www.reality.com/roberts/markus/software/ruby/location_of_missing_end/missing_end_patch.0.1.diff

The basic strategy is very simple:

      * Note the indentation of lines as they are read in
      * Note the indentation of block opening tokens
        (begin/case/class/def/if...) on a small stack
      * If a new block is opened at the same indentation as or any
        reserved word appears at a lesser indentation than the line
        containing the starting token of the nearest enclosing block,
        note the line number in a small (4 items) list.
      * If (and only if) a parsing error occurs, print (in addition to
        the normal "parse error" message) the locations of the first
        four indentation anomalies of each type.

This should not in any way change the behavior of programs that compile
correctly; it does not impose or assume any particular indentation style
or generate any messages until and unless parsing fails, at which point
it produces something like:

mqr_mesh.rb:172: warning: Possible missing 'end' or '}' near line 125
mqr_mesh.rb:172: warning: Possible missing 'end' or '}' near line 143
mqr_mesh.rb:172: parse error

(in this particular case the missing end belonged on line 124).  In
rather ad hoc testing (randomly deleting 'end's and '}' from sample
programs), at least one of the listed lines (up to a maximum of eight
are listed) was within two lines of the deleted token.  In almost all
cases, it was the first of the listed lines.

It seems to me that this could be useful (at least, there seemed to
considerable interest on ruby-talk, and it would have saved me some head
scratching on more than one occasion) and I think this is the least
intrusive way of addressing the issue.  

Testing with some debugging messages added showed that, in all of the
ruby code included with the ruby distribution, only seven lines of code
failed to follow the liberal interpretation of "normal indentation" used
in the patch.  The worst case is that (rarely, it appears) the patch
might suggest "Possible missing ends" where there were none.

Thought?  Comments?  Aberrant test cases?

-- Markus



In This Thread

Prev Next