Search results

Mmh... We could change the error message to say "Record creation is not currently allowed here"? So that people don't get a "this isn't possible, and will never be" vibe from the error message? Other than that, it's more of a "trying to clarify what is going wrong here" than a "here, let me...

Putting the "records field(s) expected" check/error outside the loop? Yes. The rest? No. This is the exact point of those latest few changes; there will be more ways to exit the loops so we can't assume there's a specific token waiting for us. The "true" constant is actually a placeholder...

https://github.com/eclipse/lsp4j/issues/554#issuecomment-841824905

Looking at the jars in lib/jar and src/jar, none of them seem to have an RSA, so they were either already removed, or weren't included in the source to begin with (or I'm dumb).

WTF are those... Those are just used for the "construction" of their jars (they use XText) I have to admit that I've never really used javadocs. Mostly because I use VScode (with the java extension(s)), and I don't know if it even recognizes them, let alone is compatible with them. All I've...

generator is just a dependency of the other lsp4j jars lsp4j.jsonrpc is way less used than lsp4j. You can point to it if you want, but what we use from it is be simple enough that you can understand what it is from context. Where it could help would be for those trying to dig into how lsp4j...

Keep in mind, at that time, we were up 12 hours apart, so we were only exchanging one message per day, so a simple "could you expand on that?" would have been a waste of 24 hours. I was being efficient, by addressing everything as well as I could, until the next exchange, which I was patiently...

If I came across as dismissive, I would welcome help to not appear as such, but my intent wasn't to be dismissive, it was simply to progress the discussion. I wasn't trying to say "naaaaah, you're worrying for nothing, c'mon, commit!!", I was addressing his points as best as I understood them...

lib/jar: https://repo.maven.apache.org/maven2/com/google/code/gson/gson/2.8.6/ https://repo.maven.apache.org/maven2/com/google/guava/guava/30.1-jre/ https://repo.maven.apache.org/maven2/org/eclipse/lsp4j/org.eclipse.lsp4j.generator/0.12.0/ src/jar...

Because these libraries (or, at the very least, the lsp4j ones. The gson and guava ones could be discarded) are not some mere "methods that we want to use". These are interfaces that we will implement, and classes that we will use (most notably, the "Location" and the "Range"). The presence of...

It breaks *our* jar. If you try to build a jar using other jars as dependency/ies, and they have their own signatures, the signatures are just added, as is, to the resulting jar. Those signatures no longer being valid, the jar is unusable.

Now, finally. There's actually one more patch, but submitting it now would create a conflict with parseNewRecord_initializers, so I'll wait. Meanwhile, it's time to submit/present the libraries that we'll be using. First off, I'd like to bump...

A bit more complex than the last few; this patch modifies parseVariable so that the signal indicating that we're parsing parameters is a boolean, rather than scope being null, and waits until the end to throw the error. This, again, will allow us to still keep trying to parse a parameter...

This modifies the logic of parseFunction a bit so that the vararg error checks happen after the variable name was read. This will allow us to have the full variable + type's location, rather than only the type, once those are implemented. Additionally, this allows the "Only one vararg parameter...

Alters parseAggregateLiteral a little so that we try to read key-value pairs (components of a map literal) even once we identified that the user is supplying an array literal (which doesn't expect keys).

This changes the logic of parseType to attempt to parse records even when not allowed (again, with the continuous parsing, we need to try anyway). This is possible because the method parseRecord starts by looking for the token "record", immediately returning null if it doesn't find it. "record"...

@heeheehee while we're talking about undocumented and unintended behaviour. Updated the patch to be compatible with the current version. (I still, to this day, have no idea what gausie was upset about...)

My bad. When I turned this from a warning to an error, tunnel vision made me not consider just... changing the message. This one fixes this, and addresses that. Also, while I'm here, it also moves the closing bracket detection to the start of the loop. Previously, we were always expecting at...

Is this better? Not sure what you mean here. Just a reminder/to be sure we're on the same page, the "new without closing paren" test reads "record r {int a;}; new r(4" Notice the "4" at the end. There already is something that was read. And the error/warning was only checked for after we parsed...

This moves around a bit of logic in parseNewRecord. While this has no impact, currently, this is because we are currently aborting as we get an error. Later, we'll be continuing the parsing, and need this to avoid a NullPointerException and an IndexOutOfBoundsException. Additionally, this adds...