Simplecov: Simplecov can't generate reports of files with names with non-ASCII characters

[guapolo]

I'm using Simplecov 0.11.1, ruby 2.2.3.

I have a file with a non-ASCII character (ñ). When running Simplecov, I get the following error:

(erb):18:in `concat': incompatible character encodings: UTF-8 and ASCII-8BIT (Encoding::CompatibilityError)
    from (erb):18:in `block in formatted_source_file'
    from (erb):14:in `each'
    from (erb):14:in `each_with_index'
    from (erb):14:in `formatted_source_file'
    from /Users/pruiz/.rvm/rubies/ruby-2.2.3/lib/ruby/2.2.0/erb.rb:863:in `eval'
    from /Users/pruiz/.rvm/rubies/ruby-2.2.3/lib/ruby/2.2.0/erb.rb:863:in `result'
    from /Users/pruiz/.rvm/gems/ruby-2.2.3@escolares/gems/simplecov-html-0.10.0/lib/simplecov-html.rb:56:in `formatted_source_file'
    from (erb):36:in `block (2 levels) in format'
    from (erb):35:in `each'
    from (erb):35:in `block in format'
    from /Users/pruiz/.rvm/rubies/ruby-2.2.3/lib/ruby/2.2.0/erb.rb:863:in `eval'
    from /Users/pruiz/.rvm/rubies/ruby-2.2.3/lib/ruby/2.2.0/erb.rb:863:in `result'
    from /Users/pruiz/.rvm/gems/ruby-2.2.3@escolares/gems/simplecov-html-0.10.0/lib/simplecov-html.rb:23:in `block in format'
    from /Users/pruiz/.rvm/gems/ruby-2.2.3@escolares/gems/simplecov-html-0.10.0/lib/simplecov-html.rb:22:in `open'
    from /Users/pruiz/.rvm/gems/ruby-2.2.3@escolares/gems/simplecov-html-0.10.0/lib/simplecov-html.rb:22:in `format'
    from /Users/pruiz/.rvm/gems/ruby-2.2.3@escolares/gems/simplecov-0.11.1/lib/simplecov/result.rb:47:in `format!'
    from /Users/pruiz/.rvm/gems/ruby-2.2.3@escolares/gems/simplecov-0.11.1/lib/simplecov/configuration.rb:168:in `block in at_exit'
    from /Users/pruiz/.rvm/gems/ruby-2.2.3@escolares/gems/simplecov-0.11.1/lib/simplecov/defaults.rb:64:in `call'
    from /Users/pruiz/.rvm/gems/ruby-2.2.3@escolares/gems/simplecov-0.11.1/lib/simplecov/defaults.rb:64:in `block in <top (required)>'
    from /Users/pruiz/.rvm/gems/ruby-2.2.3@escolares/gems/zeus-0.15.4/lib/zeus.rb:135:in `fork'
    from /Users/pruiz/.rvm/gems/ruby-2.2.3@escolares/gems/zeus-0.15.4/lib/zeus.rb:135:in `command'
    from /Users/pruiz/.rvm/gems/ruby-2.2.3@escolares/gems/zeus-0.15.4/lib/zeus.rb:50:in `go'
    from -e:1:in `<main>'

If I rename the file using ASCII characters only, the report is generated correctly. Probably related to #387.

The problem traces to this line of code in simplecov-html, but I'm guessing the real problem is when reading the file list in Result, and is related to ERB using US-ASCII as default encoding.

I tried changing simplecov-html's templates encoding using magic comments with no luck.

For now, I made this little patch in lib/simplecov-html.rb from _simplecov-html_ to display an error and continue generating the report.

begin
  template("source_file").result(binding)
rescue Encoding::CompatibilityError => e
  puts "Encoding problems with file #{source_file.filename}. Simplecov/ERB can't handle non ASCII characters in filenames. Error: #{e.message}."
end

I'm sorry I can't spend more time trying to solve this and propose a PR, hope you find it helpful to solve the issue.

[PragTob]

Hello there!

Thank you a lot for this very detailed report! That is indeed very helpful :heart:

Not sure when I'll get to it as time very scarce right now. PRs are welcome, but this should be good and seems like one should be able to reproduce it quickly and see if it is also present in current versions (it probably is).

Nala and Al thank you for your detailed report and all the time you put into it!

[ticky]

I’ve just dug into this a bit and it looks like the source of the issue is that Simplecov opens the source files as ASCII-8BIT internally (by way of the b mode flag), which causes it to get confused at the point of concatenation if it contains non-ASCII characters.

I have tested adding :UTF-8 to the flags, and that works, and likewise removing b (which suppresses automatic encoding detection works (though I do not know how that will behave on Windows).

In both cases, however, the output needs to become UTF-8, so I believe removing b and dealing explicitly with any issues caused by line endings on Windows to be the best approach.

It appears that this behaviour was introduced in 6abb79e6b3eeed02997cb356cf73647e97be0edc, so this is not _especially_ new.

[ticky]

This probably hasn’t come up yet because the UTF-8 fixture is using a character which is compatible with ASCII-8BIT.

[ticky]

Would a PR which changes this be welcomed? I guess given the prior commits around this it’s likely a breaking change for some…

[PragTob]

:wave:

Hi there and thanks for digging into this!

I'm a bit confused though, to the best of my understanding the initial issue was about non ascii characters in file names while from what you wrote it seemed more about files that contain non ASCII characters. Have I misunderstood something? Are we talking about 2 different issues? Are they related in a way I don't understand? :)

Also :'( that the commit introducing the binary behaviour didn't add any tests :/

[ticky]

I believe the issue may affect both, however I can confirm I’ve seen the same type of stack trace from a file _containing_ a unicode character (the 💵 emoji, in fact) and having put a puts right before it attempts to print the contents, I can see it fails on that line.

I believe there may be a similar bug for both of these cases, though, but I haven’t dug further into how they’re related.

[ticky]

Sorry, for context, the puts was within the same block as the CGI.escapeHTML call, which is called once per line of code, and then concatenated. I have not tested a unicode filename as it would be rather difficult for me to remove all the unicode characters from my source tree to test that alone.

Here’s my stack trace:

(erb):19:in `concat': incompatible character encodings: UTF-8 and ASCII-8BIT (Encoding::CompatibilityError)
    from (erb):19:in `block in formatted_source_file'
    from (erb):15:in `each'
    from (erb):15:in `formatted_source_file'
    from /Users/ticky/.rbenv/versions/2.4.2/lib/ruby/2.4.0/erb.rb:896:in `eval'
    from /Users/ticky/.rbenv/versions/2.4.2/lib/ruby/2.4.0/erb.rb:896:in `result'
    from /Users/ticky/.rbenv/versions/2.4.2/lib/ruby/gems/2.4.0/gems/simplecov-html-0.10.2/lib/simplecov-html.rb:57:in `formatted_source_file'
    from (erb):37:in `block (2 levels) in format'
    from (erb):36:in `each'
    from (erb):36:in `block in format'
    from /Users/ticky/.rbenv/versions/2.4.2/lib/ruby/2.4.0/erb.rb:896:in `eval'
    from /Users/ticky/.rbenv/versions/2.4.2/lib/ruby/2.4.0/erb.rb:896:in `result'
    from /Users/ticky/.rbenv/versions/2.4.2/lib/ruby/gems/2.4.0/gems/simplecov-html-0.10.2/lib/simplecov-html.rb:24:in `block in format'
    from /Users/ticky/.rbenv/versions/2.4.2/lib/ruby/gems/2.4.0/gems/simplecov-html-0.10.2/lib/simplecov-html.rb:23:in `open'
    from /Users/ticky/.rbenv/versions/2.4.2/lib/ruby/gems/2.4.0/gems/simplecov-html-0.10.2/lib/simplecov-html.rb:23:in `format'
    from /Users/ticky/.rbenv/versions/2.4.2/lib/ruby/gems/2.4.0/gems/simplecov-0.15.1/lib/simplecov/result.rb:46:in `format!'
    from /Users/ticky/.rbenv/versions/2.4.2/lib/ruby/gems/2.4.0/gems/simplecov-0.15.1/lib/simplecov/configuration.rb:180:in `block in at_exit'
    from /Users/ticky/.rbenv/versions/2.4.2/lib/ruby/gems/2.4.0/gems/simplecov-0.15.1/lib/simplecov/defaults.rb:68:in `block in <top (required)>'

As you can see, this is Ruby 2.4.2, with simplecov 0.15.1 and simplecov-html 0.10.2.

Based on the line numbers and methods called, I believe the (erb) context in the top instance to be source_file.erb, and the lower one to be layout.erb. I do believe that this is the same bug we were both encountering.

[guapolo]

I stumbled upon the original error again, so here's a small PR for it. 🍻

[PragTob]

I believe/hope #60 fixed this to an ok extent. #655 Is also there to try and make this better even more in the future.

[ticky]

@PragTob I'm not clear on what #60 has to do with this, but this issue is clearly several years more recently applicable?

[PragTob]

@ticky sorry I seem to have linked the wrong PR but can't find it for the life of me. It's a PR that introduced a capture of the encoding error and the printing out a message that ERB can't deal with it.

Sorry, I went through all the issues today and seem to have mislinked some :grin: