RuboCop::RakeTask formatter option parsing regression from 0.28 to 0.30

[uxp]

This appears to be a case of relying on an undocumented side effect, but I'm not entirely sure what the intent of the change that broke this behavior was supposed to fix or make better.

On v0.28.x, I was able to use the following rake task to run both 'progress' and 'json' formatters, with the json outputting to a file on my build server:

RuboCop::RakeTask.new do |t|
  t.patterns = %w(lib test)
  t.formatters = ['progress', ['json', '-o', 'rubocop.json']]
  t.verbose = true
end

When updating to a newer version, this is the output:

% bundle exec rake rubocop
Running RuboCop...
no implicit conversion of Array into String
/usr/lib/ruby/2.1.0/optparse.rb:341:in `match'
/usr/lib/ruby/2.1.0/optparse.rb:341:in `parse_arg'
/usr/lib/ruby/2.1.0/optparse.rb:494:in `parse'
/usr/lib/ruby/2.1.0/optparse.rb:1358:in `block in parse_in_order'
/usr/lib/ruby/2.1.0/optparse.rb:1346:in `catch'
/usr/lib/ruby/2.1.0/optparse.rb:1346:in `parse_in_order'
/usr/lib/ruby/2.1.0/optparse.rb:1340:in `order!'
/usr/lib/ruby/2.1.0/optparse.rb:1432:in `permute!'
/usr/lib/ruby/2.1.0/optparse.rb:1454:in `parse!'
/usr/lib/ruby/gems/2.1.0/gems/rubocop-0.30.1/lib/rubocop/options.rb:68:in `parse'
/usr/lib/ruby/gems/2.1.0/gems/rubocop-0.30.1/lib/rubocop/cli.rb:19:in `run'
/usr/lib/ruby/gems/2.1.0/gems/rubocop-0.30.1/lib/rubocop/rake_task.rb:50:in `run_cli'
/usr/lib/ruby/gems/2.1.0/gems/rubocop-0.30.1/lib/rubocop/rake_task.rb:38:in `run_main_task'
/usr/lib/ruby/gems/2.1.0/gems/rubocop-0.30.1/lib/rubocop/rake_task.rb:30:in `block (2 levels) in initialize'
/usr/lib/ruby/gems/2.1.0/gems/rake-10.4.2/lib/rake/file_utils_ext.rb:58:in `verbose'
/usr/lib/ruby/gems/2.1.0/gems/rubocop-0.30.1/lib/rubocop/rake_task.rb:26:in `block in initialize'
/usr/lib/ruby/gems/2.1.0/gems/rake-10.4.2/lib/rake/task.rb:240:in `call'
/usr/lib/ruby/gems/2.1.0/gems/rake-10.4.2/lib/rake/task.rb:240:in `block in execute'
/usr/lib/ruby/gems/2.1.0/gems/rake-10.4.2/lib/rake/task.rb:235:in `each'
/usr/lib/ruby/gems/2.1.0/gems/rake-10.4.2/lib/rake/task.rb:235:in `execute'
/usr/lib/ruby/gems/2.1.0/gems/rake-10.4.2/lib/rake/task.rb:179:in `block in invoke_with_call_chain'
/usr/lib/ruby/2.1.0/monitor.rb:211:in `mon_synchronize'
/usr/lib/ruby/gems/2.1.0/gems/rake-10.4.2/lib/rake/task.rb:172:in `invoke_with_call_chain'
/usr/lib/ruby/gems/2.1.0/gems/rake-10.4.2/lib/rake/task.rb:165:in `invoke'
/usr/lib/ruby/gems/2.1.0/gems/rake-10.4.2/lib/rake/application.rb:150:in `invoke_task'
/usr/lib/ruby/gems/2.1.0/gems/rake-10.4.2/lib/rake/application.rb:106:in `block (2 levels) in top_level'
/usr/lib/ruby/gems/2.1.0/gems/rake-10.4.2/lib/rake/application.rb:106:in `each'
/usr/lib/ruby/gems/2.1.0/gems/rake-10.4.2/lib/rake/application.rb:106:in `block in top_level'
/usr/lib/ruby/gems/2.1.0/gems/rake-10.4.2/lib/rake/application.rb:115:in `run_with_threads'
/usr/lib/ruby/gems/2.1.0/gems/rake-10.4.2/lib/rake/application.rb:100:in `top_level'
/usr/lib/ruby/gems/2.1.0/gems/rake-10.4.2/lib/rake/application.rb:78:in `block in run'
/usr/lib/ruby/gems/2.1.0/gems/rake-10.4.2/lib/rake/application.rb:176:in `standard_exception_handling'
/usr/lib/ruby/gems/2.1.0/gems/rake-10.4.2/lib/rake/application.rb:75:in `run'
/usr/lib/ruby/gems/2.1.0/gems/rake-10.4.2/bin/rake:33:in `<top (required)>'
/usr/bin/rake:23:in `load'
/usr/bin/rake:23:in `<main>'
RuboCop failed!

It appears that the change introduced with 496621d as part of #1738 is the culprit. A simple irb test of the array from my Rakefile shows different behavior:

% irb
irb(main):001:0> ['progress', ['json', '-o', 'rubocop.json']].flat_map {|f| ['--format', f] }
=> ["--format", "progress", "--format", ["json", "-o", "rubocop.json"]]
irb(main):002:0> ['progress', ['json', '-o', 'rubocop.json']].map {|f| ['--format', f] }.flatten
=> ["--format", "progress", "--format", "json", "-o", "rubocop.json"]

Thanks for looking.

(edited to reduce noise in rake output)

[rrosenblum]

Sorry about that. When I made the change to use flat_map instead of map.flatten, I was thinking that there should be no reason to be flattening multiple levels. I guess that I was wrong.