Search results

There were some minor bumps, but I recon that it was... simpler than anticipated.

This is literally what the next patch will address. Removing the useless ones, replacing some by a check that actually helps, and adding other useful null checks, fixing some NPEs that I found myself.

The current implementation doesn't look at an "optimal path". The path searched is hard-coded. // 1<--2<--3<--4<--5 // v // 6 7-->8 9->10 // v ^ v ^ v // 11 12 13 14 15 // v v ^ v // 16 17 18->19 20 // v ^ \ // 21->22...

This is understandable, and easy enough. Done. That's smart! It may be "less obvious", but a simple comment should be enough to clarify why we don't check for the whole "trimmed" string. Easily done. The point was meant to be that, just like String.substring, you're meant to already have done...

Is the Tokens patch still under review, or was it just waiting for these tests for confirmation?

Here's the rest. That should be it (again, some of them are commented out because of error message conflict between the current version and the patch's) btw... [junit] Clover estimates having saved around 6 hours on this optimized test run. The full test run takes approx. 6 hours wtf?

This is skipped, because my patch introduces a change in the error message. Currently, if you type, for example, "$a[]", Parser will turn the "a" into "um", and will re-parse the type. Then, when it fails, it will generate the error message by using the new/edited word ("um"). My patch makes it...

Oh, this *will* need to be modified. One feature that I added with my language server feature is to *no longer have Parser.java throw errors*. Instead, it accumulates warnings and error messages in a list, which is checked at the end, so I'll have to make sure to also update ParserTest to be...

Damn, that thing is THOROUGH... Here are some more tests in those lines. Some notes: Bad octal characters (the exception that reads "Octal character escape requires 3 digits") isn't tested. This is intentional. Currently, octal characters detection and parsing is improper, as the method...

Here's a few more tests. These tests touch the various parts that received a somewhat important change in my "Tokens" patch: strings, typed constants and plural constants. (It's worth noting that I didn't touch directives, even though they did receive an important change. This is because they...

Here's the test (Of course, I made sure that the test gets passed)

@heeheehee I made a test for string templates. While doing it, I noticed that I, yet again, did a mistake (this sure isn't helping my credibility...) in the previous patch - I wasn't supposed to touch how the *opening* curly brace was read (using readToken() rather than manually incrementing...

I am, actually, completely new to this side of programming (writing "tests"), have no (well, "very little") idea how to do it, and would very much appreciate if you could help me understand how to make those. I wouldn't mind adding/making them then. :) (partly because I already care about making...

@heeheehee I found and fixed a bug in the previous patch. I was making a standalone token out of the braces of string templates (`something{ 1 + 1 }something else`). Turns out, if spaces were following the closing brace, they would get erased. (I was doing this because I was giving them both...

Line.content CAN be null. It is in fact what is use to determine if we are at the end of the file.

As I said, I only left those here to make the reviewing easier. These will either be removed, or be replaced with a check that actually helps in a later patch.

Now, here is the conversion towards the Token. I came back and removed the formatting changes, as well as putting the null checks back (even though they are still pointless), so that they can be changed in a later patch. This patch is really the bare minimum. (minus *ONE* typo fix. Really...

This isn't actually a bug. this.currentToken() also sets the value of this.currentToken, so since no reading happens between the two, it is indeed the same (since this.currentToken() will simply return the value of this.currentToken ) It's just a better idea to keep relying on the method...

Here...

While I did say that the internal logic of Parser.nextToken() changed, it's return value did not (and it can, in both versions, still very well return null), so it shouldn't be included here. While it is true that it is very easy to review, it is also very easy to reject or ignore... This goes...