IOOBE in project loading prevents any analysis

[kubukoz]

To reproduce:

1. Prepare a file

$version: "2"

namespace hello.world

@documentation("aa")
@mixin
structure Mix {
    @required
    a: String
    @required
    b: String
    c: String
}

structure Struct with [Mix] {}

2. Open a project that has this file in sources
3. See an IndexOutOfBoundsException in FileCachingCollector, resulting in any analysis/navigation afterwards throwing a NPE (project is null)

[kubukoz]

Similar to #110. Here's the stack trace:

java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 15
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:266)
	at java.base/java.util.Objects.checkIndex(Objects.java:361)
	at java.base/java.util.ArrayList.get(ArrayList.java:427)
	at software.amazon.smithy.lsp.ext.FileCachingCollector.collectMemberLocations(FileCachingCollector.java:186)
	at java.base/java.util.HashMap.forEach(HashMap.java:1421)
	at software.amazon.smithy.lsp.ext.FileCachingCollector.collectDefinitionLocations(FileCachingCollector.java:75)
	at software.amazon.smithy.lsp.ext.SmithyProject.collectLocations(SmithyProject.java:205)
	at software.amazon.smithy.lsp.ext.SmithyProject.lambda$new$0(SmithyProject.java:73)
	at java.base/java.util.Optional.ifPresent(Optional.java:178)
	at software.amazon.smithy.lsp.ext.SmithyProject.<init>(SmithyProject.java:73)
	at software.amazon.smithy.lsp.ext.SmithyProject.load(SmithyProject.java:184)
	at software.amazon.smithy.lsp.ext.SmithyProject.load(SmithyProject.java:149)
	at software.amazon.smithy.lsp.SmithyTextDocumentService.createProject(SmithyTextDocumentService.java:149)
	at software.amazon.smithy.lsp.SmithyTextDocumentService.createProject(SmithyTextDocumentService.java:210)
	at software.amazon.smithy.lsp.SmithyLanguageServer.lambda$loadSmithyBuild$0(SmithyLanguageServer.java:62)
	at java.base/java.util.Optional.ifPresent(Optional.java:178)
	at software.amazon.smithy.lsp.SmithyLanguageServer.loadSmithyBuild(SmithyLanguageServer.java:62)
	at software.amazon.smithy.lsp.SmithyLanguageServer.initialize(SmithyLanguageServer.java:108)

However, the IOOBE is just a symptom: if we print the already-collected locations, we'll see that they're already wrong:

diff --git a/src/main/java/software/amazon/smithy/lsp/ext/FileCachingCollector.java b/src/main/java/software/amazon/smithy/lsp/ext/FileCachingCollector.java
index 334bcd2..a4f91af 100644
--- a/src/main/java/software/amazon/smithy/lsp/ext/FileCachingCollector.java
+++ b/src/main/java/software/amazon/smithy/lsp/ext/FileCachingCollector.java
@@ -202,6 +202,7 @@ final class FileCachingCollector implements ShapeLocationCollector {
                     memberEndMarker = traits.get(0).getSourceLocation().getLine();
                 }
 
+                LspLog.println("Indexing " + memberShape.getId() + " as " + createLocation(modelFile.filename, startPosition, endPosition));
                 locations.put(memberShape.getId(), createLocation(modelFile.filename, startPosition, endPosition));
                 previousLine = currentLine;
             }

[00:52:23] Indexing hello.world#Mix$c as Location [
  uri = "file:/Users/kubukoz/projects/demos/src/main/smithy/hello.smithy"
  range = Range [
    start = Position [
      line = 11
      character = 4
    ]
    end = Position [
      line = 2
      character = 21
    ]
  ]
]
[00:52:23] Indexing hello.world#Mix$b as Location [
  uri = "file:/Users/kubukoz/projects/demos/src/main/smithy/hello.smithy"
  range = Range [
    start = Position [
      line = 10
      character = 4
    ]
    end = Position [
      line = 0
      character = 13
    ]
  ]
]

So we're crashing during the analysis of a, but b and c already have their positions broken, as end is before start.

BTW. this is fixed in #146, but it's still in progress and this is affecting my teams today.

[kubukoz]

Problems are starting even earlier: the container (the mixin)'s range seems like it's one line

so from the very first member we see (c, they're being traversed from the end), we're already looking outside the container's braces.

[milesziemer]

Closing as this is fixed by #146