Search results

Ok, this fixes the NPEs in the parsePluralConstant patch

yeah, first, I should make a method out of the this.currentLine = this.currentLine.nextLine; this.currentIndex = this.currentLine.offset; 's, and have THAT not do anything if we are at the end of file

oh, wait, nvm, I see what I forgot; it has nothing to do with parseEscapeSequence

I don't-- Doesn't this prevent it? Using your first example: '\ ' is character 0 \ is character 1 the line has a length of 2 we enter parseEscapeSequence with i == 1 since char ch = line.charAt( i ); // Handle escape sequences if ( ch == '\\' )...

Well then, I guess we can continue. https://kolmafia.us/threads/ash-language-server-features.26098/post-163315 is waiting for approval https://kolmafia.us/threads/ash-language-server-features.26098/post-163321 is waiting for approval For the next method refactor, I would first like to present...

It seems like the test's arguments were modified between them being fetched from ParserTest.data() and ParserTest.testScriptValidity() being called...

No, the error message you showed really looked at the Line itself. It was truly supplied a line starting with a question mark.

(oh, you guys had already figured that out...)

Do you mean something like this: With the first line reading something like v currentLine: Parser$Line@<whatever> "null" (with quotes around the null) If so, it's maybe not an error. The IDE is probably the one not doing the null check; it maybe tries to do String stringValueOfField = "\"" +...

@fronobulax could you try with this? I significantly changed the error message, again, to print a variety of information about Byte Order Marks and the Line's first character.

The "end of file" Line (or what we marked as such) contains a single Token, with a value of ";" You can see it being assigned on line 4571

Is this platform-dependant or something? Because I'm not getting this (also how would it have passed the test for us if that was the case?)

More accurately, it seems like the Byte Order Mark was not *recognized*... Which leads to it not being trimmed, which leads to none of the parsing methods finding anything. parseScope then assumed that "finding nothing means we're at the end of the file".

So, what I think I'm seeing here, is that the Byte Order Mark was somehow not skipped...

While this gets sorted out, here are a variety of small patches: Parser's public static fields "probably" ought to be final Removal of redundant method parsePostCall. Said method was called at the very end of parseCall and parseInvoke. Both parseCall and parseInvoke are (*only*) called by...

Hard to test, Clover doesn't even let me run them... Buildfile: C:\Users\Frederic\Desktop\KoLmafia-workspace\kolmafia\build.xml init: svn-version: gitsvn-version: version: [echo] Current revision: 20838M compile-deps: compile: svn-version: gitsvn-version: version: [echo]...

And here is the parseString refactor. - that method is now exclusively for string parsing, allowing a lot of typed constant handling to be removed from it. - Since the method is now just for strings, it now has a string character check at the start (', " or `). - The typed constant handling is...

I was so tempted to name them "blue_pill.patch" and "red_pill.patch" X3

@heeheehee quick bugfix for a bug I found. Remember how you noticed that "you could put line breaks *anywhere*, in plural typed constants"? Well, it seems to also apply to the parsing of the two successive slashes needed to make a comment, i.e. "//"... This means that $booleans[tr/...