-
Notifications
You must be signed in to change notification settings - Fork 778
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multiline string implementation #1542
Conversation
588991a
to
9e3984b
Compare
Codecov Report
@@ Coverage Diff @@
## main #1542 +/- ##
==========================================
- Coverage 94.92% 94.92% -0.01%
==========================================
Files 356 356
Lines 19258 19332 +74
Branches 14 14
==========================================
+ Hits 18281 18351 +70
- Misses 977 981 +4
Flags with carried forward coverage won't be shown. Click here to find out more.
|
9e3984b
to
9ba896f
Compare
9ba896f
to
32499e7
Compare
One thing that is awkward: If I type To get VSCode to give me 3 quotes I have to enter the following:
If I try I assume this is related to the config in |
Noticed this as well - maybe it's easiest to switch to a different character like backtick? Would be a good question for Anders |
What happens if you just add the new type of string tokens to |
Turns out I should have just tried this out :) I've pushed the changes for this. Now if I type |
We might have control over what is inserted on a completion like that. I think you can add a new line and potentially move the second |
@anthony-c-martin - this might be a rare case, but is it possible to have a multiline string end with |
No - this would be blocked by this approach since the lexer is looking for exactly 3 If we were to relax this, you would always need to pick an opening sequence of var myString = '''
abc''''''''def
''' and would instead have to be written as: var myString = '''''''''
abc''''''''def
''''''''' I went with this approach to give more freedom to pick the opening sequence, and we hypothesized that the majority of use-cases would not be sensitive to whether or not the string is terminated with a newline. |
Gotcha. This makes sense. Thanks for the explanation. |
It's unfortunately not a completion but a different VS code feature enabled via config. So the snippet solution might now work unless we specifically included that completion everywhere. |
Question on the issue @shenglol noticed above. Why can't we have the lexer scan closing quotes and subtract the expected number of closing quotes from the number actually specified? Those that remain could then be included in the string value, no? |
Take a look at my response. That's definitely a valid option, it just puts more of a constraint on the choice of opening quotes. |
9d6798d
to
4fe963d
Compare
stringLeftPiece -> "'" STRINGCHAR* "${" | ||
stringMiddlePiece -> "}" STRINGCHAR* "${" | ||
stringRightPiece -> "}" STRINGCHAR* "'" | ||
stringComplete -> "'" STRINGCHAR* "'" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
STRINGCHAR [](start = 22, length = 10)
Not a new issue and definitely non-blocking for this PR, but I just realized we haven't defined what STRINGCHAR is or even IDENTIFIER.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes :) I decided to leave it along with this PR
var startOffset = terminatingQuoteCount; | ||
|
||
// we strip a leading \r\n or \n | ||
if (tokenText[startOffset] == '\r') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tokenText [](start = 16, length = 9)
This matches \r\n | \n, but I believe in the lexer elsewhere we match [\r|\n]+ elsewhere. It's subtly inconsistent, but not an issue for CRLF or LF files. I think it's fine for now, but I think we need to centralize our newline handling in the future. To finish unicode support post-0.3, we will also need to support line break and paragraph break chars.
src/Bicep.Core/Parsing/Lexer.cs
Outdated
@@ -409,6 +450,45 @@ private void ScanNewLine() | |||
} | |||
} | |||
|
|||
private TokenType ScanMultilineString() | |||
{ | |||
const int terminatingQuoteCount = 3; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
terminatingQuoteCount [](start = 22, length = 21)
This constant should be at the class level and shared between the two functions.
public ErrorDiagnostic UnterminatedMultilineString() => new( | ||
TextSpan, | ||
"BCP140", | ||
$"The multi-line string at this location is not terminated. Terminate it with \"'''\"."); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The multi-line string at this location is not terminated. [](start = 18, length = 57)
I don't see a test that produces this error. Can you add a unit or integration test to cover it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Although could you add an integration test so it's more obvious where the error span lands?
In reply to: 579478358 [](ancestors = 579478358,579478035)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Signed off with a couple of comments.
Contributing a Pull Request
If you haven't already, read the full contribution guide. The guide may have changed since the last time you read it, so please double-check. Once you are done and ready to submit your PR, run through the relevant checklist below.
Contributing a feature
Fixes #416