Ruby parsing issue related to Ruby 2.1.4

[bigtunacan]

I'm on Haml version 4.0.5 and was until recently using Ruby 2.1.1; everything was working ok until I updated to the new patch semver of Ruby 2.1.4.

Now I'm getting the following output error when the same page renders (no changes to my views or partials)

/Users/bigtuna/code/eiacuc/app/views/partials/_question.html.haml:15: syntax error, unexpected keyword_do, expecting keyword_end 
/Users/bigtuna/code/eiacuc/app/views/partials/_question.html.haml:53: syntax error, unexpected keyword_ensure, expecting end-of-input

This is what the line of code looks like where the issue is encountered.

= f.inputs (((q.pick == 'none' || (q.pick == 'one' && q.display_type != "default")) && q.display_type != 'label' ) ? nil : q_text(q, render_context)), :id => rg ? "q_#{q.id}_#{rg}" : "q_#{q.id}", 'data-id' => q.id,  :class => "q_#{renderer} #{css_class} #{state_prefix_class}" do

By splitting this out to the following lines, but no other changes the issue is worked around.

- qid = rg ? "q_#{q.id}_#{rg}" : "q_#{q.id}"
- q_render_context = (((q.pick == 'none' || (q.pick == 'one' && q.display_type != "default")) && q.display_type != 'label' ) ? nil : q_text(q, render_context))
= f.inputs q_render_context, :id => qid,'data-id' => q.id,  :class => "q_#{renderer} #{css_class} #{state_prefix_class}" do

I know both are ugly, but they should be semantically equivalent. I don't believe this is really an issue with Haml since the version has not changed and it was working previously, but rather there has been some breaking change in the Ruby semver update.

Is there a way, within the context of a Rails 4.1.7 project that I can see what the Ruby code looks like after it is processed by Haml?

[norman]

I'm sorry for the ridiculously long time this took to get a response.

Ideally Haml would allow any Ruby code in places where Haml allows Ruby to be inserted, but in practice it's possible to break its parser with complex code. This is a limitation of Haml but not a very high priority for us to fix, given that it's a best practice to keep the amount of Ruby code used in templates to a minimum, and place complex code like this in helpers.

In the interest of getting to "Issues Zero" I'm going to close this issue now since there haven't been any updates for a while, and there's no clear, immediate action to take.