StringLiteral consumers may not be CR-aware #2163
Milestone
Comments
|
There are a number of places where StringLiterals are created, as well, and CR information isn't passed into them, so both consumers and creators should probably be audited. |
headius
added a commit
that referenced
this issue
Nov 9, 2014
|
CR is a weird beast but I think if we CODERANGE_UNKNOWN all internal String code should be able to cope with recalculating it. |
|
I did a review of all StringLiteral.byteList/getByteList consumers and fixed a few places (d2ea85f) where we weren't using the cr from StringLiteral. Calling this done. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The old StrNode propagated CR from the parser into the eventual String. Our new IR was not doing so until @cheald added it in 1899c26 to fix test_slice in mri/ruby/test_string.rb. However, there may be (are likely) other consumers of StringLiteral that are just going straight for the ByteList.
We need to audit all consumers of StringLiteral and make sure they are made CR-aware.
The changes made in 1899c26 broke the JIT logic because that logic was not re-checking the CR of the string as it is being built...it only checked it based on the operands. So for the moment I'm disabling the optimized ByteList logic in the JIT. That will need to be fixed and restored for this bug.
The text was updated successfully, but these errors were encountered: