Jake Bailey
Jake Bailey
Hm, unfortunate; the test suite doesn't have a way to skip a diff yet, but could a la `fixupOld` plumbed downward.
No, unfortunately the test timeouts are global as golang/go#48157 isn't yet implemented.
Seems like there's still some raciness and non-determinism; the smoke tests have a race failure and the baselines appear to have some ordering differences when using concurrent program with info...
``` Write at 0x00c0154f5e90 by goroutine 747: runtime.mapassign_fast64ptr() /opt/hostedtoolcache/go/1.24.3/x64/src/internal/runtime/maps/runtime_fast64_swiss.go:367 +0x0 github.com/microsoft/typescript-go/internal/core.(*LinkStore[go.shape.*github.com/microsoft/typescript-go/internal/ast.Node,go.shape.struct { github.com/microsoft/typescript-go/internal/checker.isVisible github.com/microsoft/typescript-go/internal/core.Tristate }]).Get() /home/runner/work/typescript-go/typescript-go/internal/core/linkstore.go:19 +0x15b github.com/microsoft/typescript-go/internal/checker.(*emitResolver).isDeclarationVisible() /home/runner/work/typescript-go/typescript-go/internal/checker/emitresolver.go:91 +0x5e github.com/microsoft/typescript-go/internal/checker.(*emitResolver).IsDeclarationVisible() /home/runner/work/typescript-go/typescript-go/internal/checker/emitresolver.go:79 +0x9b github.com/microsoft/typescript-go/internal/transformers/declarations.(*DeclarationTransformer).transformImportDeclaration.func1() /home/runner/work/typescript-go/typescript-go/internal/transformers/declarations/transform.go:1672 +0x4d github.com/microsoft/typescript-go/internal/core.Filter[go.shape.*uint8]() /home/runner/work/typescript-go/typescript-go/internal/core/core.go:20 +0x9c ```...
Interestingly, this is not a problem during compiler test runs it seems, only in the CLI, which we should definitely have more tests for than just the one-off smoke tests.
Thanks, but I don't think we need these; all of this is extremely extensively tested through the thousands of compiler tests we have.
It's possible that it only matters for errors, but my impression from reading the code is that we may have places where order matters, e.g. for things like union reduction...
Though I will note that the slow thing in the trace is the map access in `compareNodes`, which can only be the source file ordering check. I think we're actually...
Interesting, given the original trace was about the same length of time, but `GetSourceFileOfNode` was not a big factor there. Definitely, better, though.