fix(rosetta): incorrect transliteration of map keys in python #3449
Conversation
The Python transliterator failed to properly account for maps when transliterating keys, resulting in name-mangling being applied on these when it should not have been. This PR adds a new `inMap` context entry to track whether a property assignment must be interpreted as a map key-value entry, or an actual keyword/value mapping; and in that case circumvents the mangling. Added a new test to verify that such map literals render appropriately using a key similar to that which caused #3448. Fixes #3448
| @@ -608,19 +622,18 @@ export class PythonVisitor extends DefaultVisitor<PythonLanguageContext> { | |||
| node: ts.StringLiteral | ts.NoSubstitutionTemplateLiteral, | |||
| _context: PythonVisitorContext, | |||
| ): OTree { | |||
| const rawText = node.text; | |||
| if (rawText.includes('\n')) { | |||
| if (node.getText(node.getSourceFile()).includes('\n')) { | |||
There was a problem hiding this comment.
Whats this difference between this and node.text?
There was a problem hiding this comment.
node.text is the JavaScript value of the string (in particular, with escape sequences replaced with their literal value, e.g: \n will be a "real" newline), whereas node.getText() will return the corresponding source code (which will have the escape sequences untouched).
The change here improves the situation a bit (avoid multi-lining literals that were not actually multi-line in the source), but it's also not perfect (probably good enough?) as it'll still cause some escapes to be replaced within multi-line literals).
|
Thank you for contributing! ❤️ I will now look into making sure the PR is up-to-date, then proceed to try and merge it! |
|
Merging (with squash)... |
The Python transliterator failed to properly account for maps when
transliterating keys, resulting in name-mangling being applied on these
when it should not have been.
This PR adds a new
inMapcontext entry to track whether a propertyassignment must be interpreted as a map key-value entry, or an actual
keyword/value mapping; and in that case circumvents the mangling.
Added a new test to verify that such map literals render appropriately
using a key similar to that which caused #3448.
Fixes #3448
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.