Fix all 'assigned but unused variable' warnings

[skipkayhil]

• The variables in content_location_parser appear to have been copied from content_disposition_parser but are unused
• Ragel seems to always generate a useless testEof variable. The if false trick is also used in whitequark/parser@21581a2 to suppress the warning. As mentioned in the parser commit, if false will not actually generate instructions and so it has no runtime cost.

The first commit is simply running rake ragel again to regenerate the parsers

Fixes #1400 (I've added @GQuirino as a Co-Author)

[skipkayhil]

I tried to wrap my head around the statement not reached warnings but haven't cracked it.

An example is this:

# lib/mail/parsers/content_location_parser.rb
when 17
  # line 24 "lib/mail/parsers/rfc5322_lexical_tokens.rl"
  begin
    begin
      stack[top] = cs
      top += 1
      cs = 20
      _goto_level = _again
      next
    end
  end
  # line 20 "lib/mail/parsers/content_location_parser.rl"
  begin
    content_location.location = chars(data, token_string_s, p - 1)
  end

The comments indicate that the first block is generated by comment_begin, and the second block by token_string_e.

Mostly just dumping some thoughts, I think this PR should be merged whether or not the other warnings are addressed.

[sebbASF]

I wondered about that too at first.

I think the warning is caused by the use of an unconditional 'next' which presumably terminates the 'when' block, so line 20 is not reached.

[sebbASF]

I wonder if it is worth fixing the warnings, given that the files are automatically generated.

It might be better to set things up so warnings are not generated for these files.

[skipkayhil]

It might be better to set things up so warnings are not generated for these files.

Since the parser gem uses the same trick to fix the testEof warning, I would be surprised if there was a better way. The rest of the warnings are actually unused variables, so removing them fixes the warnings.

I opened #1557 as another potential method to silence warnings, but someone pointed out to me that changing a global variable in that way is not thread safe.

Whether or not we find a solution to unreachable statement warnings, I think this change is worth merging as it is an improvement on the current situation.

[sebbASF]

Looks OK to me

[eval]

Thanks!