Non-atom `catch` element reported as atom about elvis_core HOT 6 CLOSED

Wow! Amazing catch!

I bet it has something to do with how ktn_dodger parses that expression, but if it's treating that thing as an atom that's super-weird.

from elvis_core.

Nope. ktn_dodger correctly interprets that thing as a variable… there is something else going on 🤔

from elvis_core.

It's ktn_code:parse_tree/1's fault… it turns Throw into this weird thing…

 [#{attrs =>
        #{location => {9,5},text => "Throw",value => throw},
    type => atom},
  #{attrs =>
        #{location => {9,5},name => 'Throw',text => "Throw"},
    type => var},
  #{attrs => #{location => {9,5},name => '_',text => "Throw"},
    type => var}]

It's normalizing the rest of the pattern as throw:Throw:_, but incorrectly using the text of the first element as the atom text.
Again… nice catch, @paulo-ferraz-oliveira!

from elvis_core.

This is where the bug appears:

We should use value instead of text. But the change has to be done carefully because value is an atom, not a string… and because we want to differentiate between enclosed and non-enclosed macros.

from elvis_core.

I'll try to look at it one of these days, if time allows.

from elvis_core.

Attempted fixing this with #216
Not sure if it's the best solution but it just handles these cases by using the value attribute when it equals to throw otherwise use text attribute.
Found that just switching to use the text attribute had issues as the values were dropping off the backslashes used to escape characters in the atom.

from elvis_core.