v0.112.0

Reviewed By: jbrown215

Differential Revision: D18437904

fbshipit-source-id: f44beca2f9c03a4fda33a1b5ad6bca09392cd0c2

v0.111.3

Reviewed By: mroch

Differential Revision: D18332374

fbshipit-source-id: 42004f77a7d69755da2370759584118885a120be

[spreads][rfc] Unify OpenTs in widen_type

Summary:
Creating all of these new OpenTs can pose a performance problem. The added test case takes ~20 seconds without unification here, but is almost instant when there is unification. The final type-at-pos result is still just quadratic in both cases.

I've observed the slowdown to occur during the OpenT ~> OpenT flow. I think so many OpenTs are created that even just forwarding the flows takes a long time without unification.

If it's not safe to unify here in general, I made a special reason desc for OpenTs created during widening and only Flow/Unify to the OpenTs in widening if that tvar was created by the widening process. Otherwise, we create a new OpenT with the special reason desc and use that type.

Note that the overall perf impact here is neutral, even though it speeds up this specific case.

Reviewed By: avikchaudhuri

Differential Revision: D17798281

fbshipit-source-id: 4223ce891ceab44dbab72da10cce0caf27c2c4e1

v0.111.1

Summary: (Note: this ignores all push blocking failures!)

Reviewed By: nmote, dsainati1

Differential Revision: D18272844

fbshipit-source-id: b8832140ac1821a1a42d995f0535eb1f7a216863

Add `module.system.node.allow_root_relative=true` to the changelog

Summary: (Note: this ignores all push blocking failures!)

Reviewed By: jbrown215

Differential Revision: D18230708

fbshipit-source-id: 07ae4080ca44288539c32a0b4d3802824f863b64

v0.110.1

Reviewed By: dsainati1

Differential Revision: D18095021

fbshipit-source-id: 2a6d3445eefb3e68466ecd77a54042b5e13ebe4c

[hack] fix File_url slashes on Windows

Summary:
Pull Request resolved: facebook#8142

previously, `File_url.parse "file:///c%3A/foo/bar"` returned `"c:/foo/bar"` instead of `"c:\foo\bar"`, because `/` and `\` are (generally) interchangeable on Windows.

however, `Sys_utils.realpath` does convert them to `\` (only if the file exists, otherwise it leaves it alone!), which makes it more difficult to compare two paths.

so, we now match `realpath`'s behavior, converting `/` to `\` on Windows.

also, `File_url.create "c:\foo\bar"` returns `"file:///c%3A/foo/bar"` on Windows, but on Linux, `\` is a valid path character and should be escaped, like `"file:///c%3A%5Cfoo%5Cbar"`.

Reviewed By: gabelevi, samwgoldman

Differential Revision: D18024985

fbshipit-source-id: 2f09b7f3587a0b01a3ee9ab935ed67cc0d308164

Fix source of flakiness for lsp/completion test

Summary:
I noticed that {D17584973} failed this test. I think it was a source of flakiness. Most of the test cases look like

1. Add `jsx.js` (which has syntax errors)
2. Start the lsp server and server
3. Send a completion request
4. Assert the response matches.

When the lsp starts up, it will see the syntax errors and send the `textDocument/publishDiagnostics` message to the client. Usually this happens between steps 2 and 3. But if it happens after 3 then the step 4 assertion would fail like this:

```

+ textDocument/publishDiagnostics,textDocument/completion{"isIncomplete":false,"items":[{"label":"a","kind":6,"detail":"number","inlineDetail":"number","insertTextFormat":1}]}
- textDocument/completion{"isIncomplete":false,"items":[{"label":"a","kind":6,"detail":"number","inlineDetail":"number","insertTextFormat":1}]}
```

(Full logs: P113545680)

Easy fix. Just ignore those messages

Reviewed By: nmote

Differential Revision: D17602294

fbshipit-source-id: 7c6f2a7ae84f5d3caffae90fdaacc0e57ea46775

v0.108.0

Reviewed By: gabelevi

Differential Revision: D17464010

fbshipit-source-id: e5d1c97433ac48debde4fe746cc339de4e434d08

v0.107.0

Reviewed By: mroch

Differential Revision: D17191133

fbshipit-source-id: 0cb3b789ac030c24144db8ec054a50abaa62fe72