profile
viewpoint

mroch/ical_builder 8

An iCalendar generator in Ruby, modelled after Jim Weirich's Builder

mroch/bigmoney 6

Represents an amount of money in a particular currency. Backed by BigDecimal, so is safe from float rounding errors.

mroch/baby-connect 5

A library for interacting with Baby Connect

mroch/attachment_fu 2

Treat an ActiveRecord model as a file attachment, storing its patch, size, content type, etc.

mroch/authpipe 2

Ruby library to respond to Courier authpipe authentication requests

mroch/campusbooks 2

A Ruby library for accessing the CampusBooks.com API

mroch/crestron-alexa-server 2

Simpl# Alexa server

mroch/GzipSimplSharp 2

A Crestron Simpl# library to enable gzip decoding in SIMPL+

mroch/interlock 2

Evan Weaver's Rails plugin for maintainable and high-efficiency caching.

mroch/amazonian 1

Building out ASIN with the full Amazon Product Advertising API

create barnchmroch/linguist

branch : flow

created branch time in 5 days

fork mroch/linguist

Language Savant. If your repository's language is being reported incorrectly, send us a pull request!

fork in 5 days

push eventmroch/flow

Marshall Roch

commit sha 292314b39d8bde8651dc8eca75627330ca36108f

use file URIs in command names Summary: D20249614 added the root path to LSP command names. the tests failed on Windows because of normalization issues. even though this is essentially an opaque token, using a `file://` URI instead of a path makes it consistent, and all other parts of the LSP use file URIs. Reviewed By: vrama628 Differential Revision: D20260352 fbshipit-source-id: 3a2cabea5954a765ab54cad6cd7c1fb6cb5ed282

view details

Marshall Roch

commit sha 9e5ab2c68ee344a7bbc47ceece5ab88ab6564f0d

fix <PLACEHOLDER_PROJECT_URL> in tests on Macs Summary: on macs, the temp dir is in `/var/folders` which is a symlink to `/private/var/folders`. in our expected test output, we want to replace the project root URL with `<PLACEHOLDER_PROJECT_URL>`, but that doesn't work when it's sometimes `file:///var/folders/...` and other times `file:///private/var/folders/...`. so, we `realpath` the temp dir before using it to run the tests. Reviewed By: dsainati1 Differential Revision: D20283512 fbshipit-source-id: 604c1c82877b052919dcb13ab1935e7a4c966d14

view details

Daniel Sainati

commit sha 2c17f52c1cca1bf1fbe427b3ef101c659422ba03

v0.120.0 Reviewed By: mroch Differential Revision: D20283528 fbshipit-source-id: 4539ffdc19ece52e3838fb8003fc8436752e0e84

view details

Nat Mote

commit sha bd62395e7234d165bf08b14326028fef61959899

Rename Saved_state_fetcher.result Summary: It always throws me for a loop when I see a `result` type which shadows `Pervasives.result`. This diff renames `Saved_state_fetcher.result` to avoid that confusion. Reviewed By: gkz Differential Revision: D20231452 fbshipit-source-id: b2546dda4091f1d41a8a40fc4314c6213d8dc08f

view details

Pieter Vanderwerff

commit sha 3254a8479eb2b6a6cdcac10b987c5838693bf5cd

Merge pattern interation logic Reviewed By: panagosg7 Differential Revision: D20264298 fbshipit-source-id: f507352b3ca8dbb972bc9b2558143d2ecf7543c5

view details

Daniel Sainati

commit sha e9773c8355c7f9534fe594a75eea720399e5ac9a

v0.120.1 Reviewed By: dsainati1 Differential Revision: D20290152 fbshipit-source-id: 09806e5e77653a04ee14f79d10cbcded2518c9bd

view details

Hans Halverson

commit sha d04ead2c6d7ef7ea6b1a83cdf31828ed42a3d4ad

Intern comments in blocks Summary: Interns leading and trailing comments around blocks with the following form: ``` /* leading */ { const x = 1; } /* trailing */ ``` This change does not attach any inner comments, e.g. comments that trail all statements in the block: ``` { const x = 1; /* Trailing all statements */ } ``` This can be changed in the future when we settle how to handle these comments, but this diff sets up the basic structure for interning comments in blocks. Note that there are still issues with trailing comments leading for the next statement, but this is a general problem across all comment interning at the moment. Reviewed By: pieterv Differential Revision: D20201572 fbshipit-source-id: 4f2d7b0d6dcc0e14231625bf150bf228d833608a

view details

Hans Halverson

commit sha 8f931b8cc0c082435b5630362bd5be56b51f7452

Intern comments in variable declaration nodes Summary: Interns leading and trailing comments around variable declarations. Variable declarations can always have leading comments before the initial `var`/`let`/`const`, and also may have trailing comments after the closing semicolon. For example: ``` /* L decl */ var /* L id */ x /* T id */ = /* L num */ 1 /* T num */ ; /* T decl */ ``` However variable declarations as the init of a for loop cannot have trailing comments after the semicolon, as those comments should be interpreted as leading comments of the test. Variable declarations on the left hand side of for in or for of statements also cannot have trailing comments as comments directly before the `of`/`in` will be trailing for the var decl's pattern, and comments directly after the `of`/`in` will be leading for the right hand side. To correctly grab trailing comments when parsing I had to lift the creation of the `VariableDeclaration` out of utilities in the declaration parser, and instead move it to every call site, fetching trailing comments after the semicolon is consumed if appropriate. Note that there are still issues with trailing comments leading for the next statement, but this is a general problem across all comment interning at the moment. Reviewed By: pieterv Differential Revision: D20229729 fbshipit-source-id: 6bbe97b7642c96ea3adcb020cd5505ea199a55ad

view details

Daniel Sainati

commit sha e5262d703a20dc640d2a9ce718c4a689429db69f

[Errors] Don't replace a speculation error's location with its singular branch's location Summary: Previously, when formatting a speculation error for printing, if we only had a single branch to the error, we'd replace the overall error's location with that of the branch. This is a bad idea. Not only does it claim that the primary location's error is positioned elsewhere than it actually is, but when checking the new `positioning.js` test file, we'd generate the following error: ``` Error ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ tests/error_printing/positioning.js:8:18 number literal 3 [1] is incompatible with empty [2] in type argument T of the first argument. 8│ $fragmentRefs: $PropertyType<T, '$refType'>, 9│ }; 10│ 11│ type X = $NonMaybeType<{| [1] 12│ +$refType: 3, : [2] 18│ (<T: {+$refType: empty, ...}>(?T) => ?T) & 19│ (<TRef: 3, T: {+$refType: TRef, ...}>(T) => $FragmentRef<T>), 20│ >; 21│ 22│ type Props = { 23│ selectedValue: X, 24│ }; 25│ 26│ declare var x: $RelayProps<React$ElementConfig<(Props) => React.Node>, {}>; ``` One might expect, quite reasonably, that position `[1]` might be the primary location, or the `$PropertyType<T, '$refType'>` which is highlighted red on the CLI. In fact however, the primary location is on line 22, which only appears in the error by proximity to an included location. If the primary location were in a different file, it wouldn't appear in the error message at all. This is obviously terrible, so instead we don't replace the error's location with it's branch's, and thus correctly display the primary location. Reviewed By: panagosg7 Differential Revision: D20108047 fbshipit-source-id: 1044008fbf28746b8af424e3c85d73cedc71228c

view details

Daniel Sainati

commit sha ac1b7c45bf6a70e3a92eb7bab64476d7131bfb13

[Errors] when printing errors, the primary location should always be printed first Summary: Previously, the error printing logic distinguished between a primary location and a "root location", which was decided based on some arcane logic that has little to do with the actual location of the error. We need to ensure that the first location printed in an error is always the primary so users know where to add suppressions, so this changes error printing to always print the primary location first, and ignore the "root loc". Reviewed By: panagosg7 Differential Revision: D19827425 fbshipit-source-id: 45b2263f893c522fa96defd9c0028b539d7ea8f3

view details

Marshall Roch

commit sha 35f40523205c1a40e836119e938faca4c25b9788

don't mark unparsed .js.flow files as checked Summary: parsed `.js.flow` files are not automatically considered "checked", so don't consider unparsed `.js.flow` files as such either. as far as I can tell, this doesn't really make a difference since we only check parsed files, but I want to kill `Docblock.isDeclarationFile`. Reviewed By: samwgoldman Differential Revision: D20069817 fbshipit-source-id: ae9d654c0f6bd47fbc18eef5ee3deb1cb132328c

view details

Marshall Roch

commit sha cde20899624d8ac01722ccbb7a4398a089b3c43f

unit test for parse errors in .js.flow without @flow Summary: adds a test for our current behavior: | | parse | check | | .js w/ flow | √ | √ | | .js w/o flow | x | x | | .js.flow w/ flow | √ | √ | | .js.flow w/o flow | √ | x | Reviewed By: samwgoldman Differential Revision: D20069748 fbshipit-source-id: 0833661fd11c25ddc303b49eba0db7ae1a30888a

view details

Marshall Roch

commit sha 964750ad9baa0e93ef52a4df04cb36d01f39dfbe

stop parsing .flow files without @flow Summary: right now, we parse but don't check `.js.flow` files without `flow`. this is inconsistent, because we treat it as a "non flow" file, but still report parse errors. it can cause problems if you have an invalid non-@flow `.js` file and follow our recommended "build" strategy of `cp *.js *.js.flow`. | | parse | check | | .js w/ flow | √ | √ | | .js w/o flow | x | x | | .js.flow w/ flow | √ | √ | | .js.flow w/o flow | √ -> x | x | Reviewed By: samwgoldman Differential Revision: D18768614 fbshipit-source-id: 9c0ba773f3c667312e790d3f03ee9422bb27b996

view details

Marshall Roch

commit sha e2ce0976291f57d765850e0277e713103edce9c7

remove Docblock.isDeclarationFile Summary: it's unused now. it was also strange because it wasn't actually part of the docblock, it was determined by the filename. Reviewed By: gkz Differential Revision: D20070778 fbshipit-source-id: 58498bc200fd05dd6bbc2940c4bfa1562bfe176a

view details

Hans Halverson

commit sha 1ec8c0f01249a32b3fe2972d67d35da61ab5786c

Fix attachment of trailing comments on return statements Summary: Fixes attachment of trailing comments for `return`. - `return; /* comment */` is a comment trailing the return statement - `return /* comment1 */ exp /* comment2 */;` are leading/trailing the expression, not the return statement - `return /* comment */;` is a comment internal to the statement, which is ignored for now as internal attachment has not yet been implemented Reviewed By: mroch Differential Revision: D20231075 fbshipit-source-id: 06996f25fbd35cef3b00b2e3624c161b9ecb7279

view details

Nat Mote

commit sha 79cfa21f343ef79700060d8e1bc7bc2e4f22c46e

Add an error variant to `Saved_state_fetcher.fetch_result` Summary: Previously, this variant type did not distinguish between the case where we tried to find saved state and failed (e.g. local fetcher) and the case where we simply did not bother to look for saved state (e.g. the dummy fetcher). This leads to an inconsistency where a failure to find the saved state and a failure to read the saved state are handled in completely different ways. This is illustrated by the test added in D20252511. This diff adds the additional variant needed to distinguish between failing to find saved state and choosing not to look for saved state. For now, they are handled identically, but future diffs will change that. Reviewed By: mroch Differential Revision: D20236637 fbshipit-source-id: 5da544d66c3982af95ea568a09754d615a640ff0

view details

Nat Mote

commit sha e3b6b41edffc8f0fb53ef03682bf6ab132e47976

Add test for --saved-state-no-fallback flag Summary: This test illustrates the issue described in D20236637. We fail to distinguish between "could not find saved state" and "did not look for saved state," so even if the `--saved-state-no-fallback` flag is provided, Flow ignores it and initializes normally if saved state cannot be found. Reviewed By: mroch Differential Revision: D20252511 fbshipit-source-id: e6521e877be83bacc8b4e5078fc998a7fa59ebb2

view details

Nat Mote

commit sha dddbaeee3e40ec4275d10d59ba93deb2e7101e74

Return `Saved_state_error` if we encounter an error while finding the saved state Summary: Natural next step after D20236637 Reviewed By: mroch Differential Revision: D20254587 fbshipit-source-id: 15a7e284c4960a384d9d5c950984e52802611c4c

view details

Nat Mote

commit sha 9ae62d10dbab28ddc219e95e274a242d7364f9a5

Split out `saved_state` directory into multiple subdirectories Reviewed By: mroch Differential Revision: D20265351 fbshipit-source-id: 5faba0e55b4d021fed05d0f6dcaa2833967d107b

view details

Nat Mote

commit sha 08d58c98c02ac97f126fb0e1160c71bf83d8a7ea

Replace `include struct` pattern with `mli` files Summary: It looks like the intent of this pattern was to constrain the module to a particular interface. Fortunately we can accomplish the same thing by simply `include`ing the interface that we want in an `mli` file. Reviewed By: mroch Differential Revision: D20268104 fbshipit-source-id: 46ad40721b2738b4fee025c9b979f08dd7fec1d9

view details

push time in 13 days

push eventflowtype/flow-bin

Marshall Roch

commit sha 9207073822d7e129fe424af5c58a24f57bd72966

`make push` should not fail if the tag already exists

view details

push time in 16 days

Pull request review commentfacebook/flow

Add HeadersInit and signal to Fetch

 declare class WaveShaperNode extends AudioNode {  // this part of spec is not finished yet, apparently // https://stackoverflow.com/questions/35296664/can-fetch-get-object-as-headers-type HeadersInit = Headers | { [key: string]: string, ... };+type HeadersInit = Headers | string[][] | { [key: string]: string, ... };

changing this to Array<[string, string]> per

Screen Shot 2020-05-14 at 9 44 04 AM

goodmind

comment created time in 17 days

pull request commentfacebook/flow

Fix for recent version of OCaml, js_of_ocaml, lwt, core_kernel

thanks for this! we have a lot of different environments to get this to build in so it might take a bit of time to merge this, or I might have to land it in a couple pieces.

hhugo

comment created time in 20 days

pull request commentfacebook/flow

Support .cjs extension

last time we added an extension it caused us some perf issues because of node's search algorithm. it adds a lot of stat() syscalls to see if node_modules/foo.cjs, node_modules/foo/index.cjs, etc, exists as it walks up the directory tree. ideally we would cache the directory tree in memory and not need to do that...

since our internal codebases are huge, i'll run some tests to see. for small projects it won't matter, so I think we probably should merge this and then disable it on huge repos that don't use it like Facebook's.

it'd also be great if we enforced that .mjs used import and .cjs used require, but obviously that can be future work.

TrySound

comment created time in a month

issue commentfacebook/flow

Wrong range of `AssignmentExpression`

found one for sequences: https://github.com/facebook/flow/issues/8364

fisker

comment created time in a month

issue openedfacebook/flow

Wrong range of `SequenceExpression`

The range of a sequence expression does not include the leading paren of the first item or the trailing paren of the last item, if those parens are for grouping.

for example:

   foo, (bar)
// ^^^^^^^^^

created time in a month

issue commentfacebook/flow

Wrong range of `AssignmentExpression`

@fisker do you have an example for other expressions?

fisker

comment created time in a month

issue closedfacebook/flow

NullishCoalescing mixing with LogicalExpressions without parenthesis should throw an error

<!-- Please fill out this entire template so that we can address your bug report as quickly as possible.

Any bug reports that don't contain instructions to reproduce the issue will be closed. -->

Flow version: Latest Version

Expected behavior

The nullish coalescing operator (??) currently allows mixing with the other logical operators (|| and &&) without parenthesis. This is invalid per the latest specs, parenthesis are required to mix them:

// Currently valid but should be a syntax error
a ?? b || c

// Currently valid but should be a syntax error
a || b ?? c

// Currently valid but should be a syntax error
a ?? b && c

// Currently valid but should be a syntax error
a && b ?? c

The test cases for these pass which should ideally be failing. https://github.com/facebook/flow/blob/master/src/parser/test/flow/nullish_coalescing/precedence_and.js

Actual behavior

These should each throw a syntax error when parsing. It requires parens to disambiguate the intended grouping.

// Valid according to spec
a ?? (b || c)

// Valid according to spec
(a ?? b) || c

// Valid according to spec
(a || b) ?? c

// Valid according to spec
a || (b ?? c)

// Valid according to spec
a ?? (b && c)

// Valid according to spec
(a ?? b) && c

// Valid according to spec
(a && b) ?? c

// Valid according to spec
a && (b ?? c)

<!-- Please reproduce your issue on flow.org/try so that we can debug it.

Not all issues are reproducible on try-flow because they may require multiple files or specific flowconfig settings. If your bug can only be reproduced under one of these constraints, please make a small github repo that contains a minimal way to reproduce your problem. -->

  • Link to Try-Flow or Github repo: https://flow.org/try/#0PQKgBAAgZgNg9gdzCYAoVBjOA7AzgFzAEMwBeMAVgBowAjMsANhozIHYBudYYMfACwCWuMLn5wArjAAmdAKbFRAT2z4iADzByATtrjbiIgA47RJjKhIB+K3TAAfe2AxA

closed time in a month

vivek12345

issue commentfacebook/flow

NullishCoalescing mixing with LogicalExpressions without parenthesis should throw an error

this was fixed back in https://github.com/facebook/flow/commit/1e4f232c3f946cb056b1673f5a6e019940cfe00a

vivek12345

comment created time in a month

issue commentfacebook/flow

Wrong range of `AssignmentExpression`

thanks! fixing this right away

fisker

comment created time in a month

IssuesEvent

issue commentfacebook/flow

`Cannot perform arithmetic operation because null [1] is not a number.` Appears on subtraction, but don't on addition.

filed https://github.com/facebook/flow/issues/8350 to fix the missing docs

carljohnesan

comment created time in a month

issue openedfacebook/flow

Document `unsafe-addition` lint

v0.118 added a new lint, unsafe-addition, which warns if either operand of an addition is null or void but it's not documented yet.

created time in a month

issue closedfacebook/flow

`Cannot perform arithmetic operation because null [1] is not a number.` Appears on subtraction, but don't on addition.

Flow version: 0.122.0

Expected behavior

// type Props = { ...

type State = {
  count: number,
  n: null | number,
  // ... ,
};

class Counter extends React.Component<Props, State> {
  // state = { ...

  subtract = (): void => {
    this.setState((state) => ({
      count: state.count - state.n, // Error - `Cannot perform arithmetic operation because null [1] is not a number.`
    }));
  };

  add = (): void => {
    this.setState((state) => ({
      count: state.count + state.n, // Error - `Cannot perform arithmetic operation because null [1] is not a number.`
    }));
  };

  // render() { ...
}

Actual behavior

// type Props = { ...

type State = {
  count: number,
  n: null | number,
  // ... ,
};

class Counter extends React.Component<Props, State> {
  // state = { ...

  subtract = (): void => {
    this.setState((state) => ({
      count: state.count - state.n, // Error - `Cannot perform arithmetic operation because null [1] is not a number.`
    }));
  };

  add = (): void => {
    this.setState((state) => ({
      count: state.count + state.n, // No error somewhy
    }));
  };

  // render() { ...
}

Try Flow

closed time in a month

carljohnesan

issue commentfacebook/flow

`Cannot perform arithmetic operation because null [1] is not a number.` Appears on subtraction, but don't on addition.

in v0.118, we added a new lint, unsafe-addition, which warns if either operand of an addition is null or void. hope this helps!

add this to .flowconfig:

[lints]
unsafe-addition=error
carljohnesan

comment created time in a month

issue commentfacebook/flow

[Linux] Cannot successfully start flow server without sudo (uncaught async exception: End_of_file, raised at file "map.ml", called from file "src/unix/lwt_unix.cppo.ml")

it also might help debug to take npx out of the mix by running /home/xunnamius/test/node_modules/flow-bin/flow-linux64-v0.122.0/flow directly

Xunnamius

comment created time in 2 months

issue commentfacebook/flow

[Linux] Cannot successfully start flow server without sudo (uncaught async exception: End_of_file, raised at file "map.ml", called from file "src/unix/lwt_unix.cppo.ml")

if you run OCAMLRUNPARAM=b npx ..., it might give you a longer stack trace, which would give us a clue to which area is causing the EOF.

Xunnamius

comment created time in 2 months

push eventflowtype/flow-bin

Marshall Roch

commit sha ace9480034716d82019888d259252b7720d82480

update readme

view details

push time in 2 months

push eventflowtype/flow-bin

Marshall Roch

commit sha 1eaaa930e8ddcd27a2c1e581fc23c88dfa59a732

bump during build bump is a no-op if the version hasn't changed so just run it during build

view details

push time in 2 months

push eventflowtype/flow-bin

Marshall Roch

commit sha 1bb33e875ae21f94c1c594f06e7442fe63a126d2

add 'make publish'

view details

push time in 2 months

delete tag flowtype/flow-bin

delete tag : LOW_VERSION

delete time in 2 months

created tagflowtype/flow-bin

tagLOW_VERSION

Binary wrapper for Flow - A static type checker for JavaScript

created time in 2 months

created tagflowtype/flow-bin

tagv0.122.0

Binary wrapper for Flow - A static type checker for JavaScript

created time in 2 months

push eventflowtype/flow-bin

Marshall Roch

commit sha 50e6a66baa320dc61ea7047a000816df7296c24c

add 'make push'

view details

Marshall Roch

commit sha b90241b628586e15cc6682ea4c7de009c105d08c

v0.122.0

view details

push time in 2 months

issue closedfacebook/flow

Dead parser code

Judging by object_parser#L428-L431 and test/flow/private_class_properties/constructor.js#L9-L15, I suspect that private constructor properties are supposed to be forbidden. Unfortunately the String.equal name "#constructor" predicate always fails. Should that "#constructor" be "constructor"? Or should that case be removed? Else?

closed time in 2 months

popham

issue commentfacebook/flow

Dead parser code

fixed in https://github.com/facebook/flow/commit/9f106b8733c1f0416866890f0ed9458d9dba9fe4

popham

comment created time in 2 months

issue closedfacebook/flow

OCaml 4.06.0 build failure

I follow the same instructions in OCaml 4.03.0 and Ocaml 4.06.0.

4.03.0 works while 4.06.0 report error when make

I work on macOS 10.13.3 .

ocaml -safe-string -I scripts -w -3 unix.cma scripts/gen_build_id.ml _build/hack/utils/get_build_id.gen.c
# Both lwt and lwt_ppx provide ppx stuff. Fixed in lwt 4.0.0
# https://github.com/ocsigen/lwt/issues/453
export OCAMLFIND_IGNORE_DUPS_IN="/Users/ex/.opam/4.06.0/lib/lwt"; \
	ocamlbuild \
		-use-ocamlfind\
		-no-links  -I src/commands -I src/commands/config -I src/common -I src/common/audit -I src/common/errors -I src/common/lints -I src/common/lwt -I src/common/monad -I src/common/profiling -I src/common/span -I src/common/tarjan -I src/common/ty -I src/common/utils -I src/common/xx -I src/flowlib -I src/monitor -I src/monitor/connections -I src/monitor/logger -I src/monitor/utils -I src/parser -I src/parser_utils -I src/parser_utils/output -I src/parser_utils/output/printers -I src/parsing -I src/server -I src/server/protocol -I src/services/autocomplete -I src/services/inference -I src/services/flowFileGen -I src/services/port -I src/services/type_info -I src/third-party/lz4 -I src/third-party/ocaml-sourcemaps/src -I src/third-party/ocaml-vlq/src -I src/typing -I hack/dfind -I hack/find -I hack/globals -I hack/heap -I hack/injection/default_injector -I hack/procs -I hack/search -I hack/socket -I hack/third-party/avl -I hack/third-party/core -I hack/utils -I hack/utils/build_mode/prod -I hack/utils/collections -I hack/utils/disk -I hack/utils/hh_json -I hack/utils/sys -I hack/fsevents -I hack/fsnotify_darwin -I hack/stubs -I src/stubs -pkg sedlex -pkg lwt -pkg lwt.log -pkg lwt.unix -pkg lwt_ppx -pkg unix -pkg str -pkg bigarray \
		-lflags "hack/fsevents/fsevents_stubs.o src/common/xx/xx_stubs.o hack/heap/hh_shared.o hack/utils/get_build_id.o hack/utils/sys/files.o hack/utils/sys/handle_stubs.o hack/utils/sys/nproc.o hack/utils/sys/priorities.o hack/utils/sys/processor_info.o hack/utils/sys/realpath.o hack/utils/sys/sysinfo.o src/third-party/lz4/lz4.o src/third-party/lz4/lz4frame.o src/third-party/lz4/lz4hc.o src/third-party/lz4/xxhash.o hack/utils/get_build_id.gen.o -cclib -l -cclib pthread  -cclib -framework -cclib CoreServices -cclib -framework -cclib CoreFoundation" \
		 \
		src/flow.native
ocamlfind ocamlopt -c -unsafe-string -w A -warn-error A -w -27 -w -3-4-6-29-35-44-48-50-52 -package sedlex -package wtf8 -w -4-6-29-35-44-48-50 -package dtoa -package bigarray -package str -package unix -package lwt_ppx -package lwt.unix -package lwt.log -package lwt -I hack/procs -I src/parsing -I src/commands -I src/flowlib -I src/parser_utils -I src/common -I src/typing -I src/parser -I src/server -I src/monitor -I src/stubs -I src/services/port -I src/services/type_info -I src/services/inference -I src/services/flowFileGen -I src/services/autocomplete -I src/third-party/lz4 -I src/third-party/ocaml-vlq/src -I src/third-party/ocaml-sourcemaps/src -I src/commands/config -I src/parser_utils/output -I src/parser_utils/output/printers -I src/common/xx -I src/common/errors -I src/common/lints -I src/common/monad -I src/common/profiling -I src/common/audit -I src/common/span -I src/common/lwt -I src/common/tarjan -I src/common/utils -I src/common/ty -I src/server/protocol -I src/monitor/connections -I src/monitor/utils -I src/monitor/logger -I hack/socket -I hack/fsevents -I hack/find -I hack/heap -I hack/dfind -I hack/utils -I hack/fsnotify_darwin -I hack/stubs -I hack/third-party/avl -I hack/third-party/core -I hack/injection/default_injector -I hack/utils/hh_json -I hack/utils/collections -I hack/utils/disk -I hack/utils/sys -I hack/utils/build_mode/prod -o hack/procs/workerControllerLwt.cmx hack/procs/workerControllerLwt.ml
+ ocamlfind ocamlopt -c -unsafe-string -w A -warn-error A -w -27 -w -3-4-6-29-35-44-48-50-52 -package sedlex -package wtf8 -w -4-6-29-35-44-48-50 -package dtoa -package bigarray -package str -package unix -package lwt_ppx -package lwt.unix -package lwt.log -package lwt -I hack/procs -I src/parsing -I src/commands -I src/flowlib -I src/parser_utils -I src/common -I src/typing -I src/parser -I src/server -I src/monitor -I src/stubs -I src/services/port -I src/services/type_info -I src/services/inference -I src/services/flowFileGen -I src/services/autocomplete -I src/third-party/lz4 -I src/third-party/ocaml-vlq/src -I src/third-party/ocaml-sourcemaps/src -I src/commands/config -I src/parser_utils/output -I src/parser_utils/output/printers -I src/common/xx -I src/common/errors -I src/common/lints -I src/common/monad -I src/common/profiling -I src/common/audit -I src/common/span -I src/common/lwt -I src/common/tarjan -I src/common/utils -I src/common/ty -I src/server/protocol -I src/monitor/connections -I src/monitor/utils -I src/monitor/logger -I hack/socket -I hack/fsevents -I hack/find -I hack/heap -I hack/dfind -I hack/utils -I hack/fsnotify_darwin -I hack/stubs -I hack/third-party/avl -I hack/third-party/core -I hack/injection/default_injector -I hack/utils/hh_json -I hack/utils/collections -I hack/utils/disk -I hack/utils/sys -I hack/utils/build_mode/prod -o hack/procs/workerControllerLwt.cmx hack/procs/workerControllerLwt.ml
File "hack/procs/workerControllerLwt.ml", line 66, characters 12-15:
Error: This pattern matches values of type (b * Measure.record_data) Lwt.t
       but a pattern was expected which matches values of type
         b * Measure.record_data
Command exited with code 2.

closed time in 2 months

arbipher

issue commentfacebook/flow

OCaml 4.06.0 build failure

can't reproduce, all our builds are on 4.07 now so this must've been resolved at some point. sorry for the silence

arbipher

comment created time in 2 months

issue closedfacebook/flow

AppVeyor build is failing for all commits, even old ones that succeeded

The AppVeyor build is failing. Worse, it fails for commits that have previously passed. (Is this indicative of a config or version change somewhere?)

The error that seems to be consistent across the fails is this:

Error: Files C:/cygwin64/home/appveyor/.opam/4.05.0+mingw64c/lib/ocaml\unix.cmxa
       and C:/cygwin64/home/appveyor/.opam/4.05.0+mingw64c/lib/ocaml\unix.cmxa
       both define a module named Unix
Command exited with code 2.
make: *** [Makefile:96: ../../_build/src/parser/test/run_tests.native] Error 10
make: Leaving directory '/cygdrive/c/projects/flow/src/parser'
Command exited with code 2

For an example of a commit that should have succeeded, see #6249

closed time in 2 months

eedrah

issue commentfacebook/flow

AppVeyor build is failing for all commits, even old ones that succeeded

the windows builds (now on Circle) seem stable recently

eedrah

comment created time in 2 months

issue commentfacebook/flow

Flow tool remove-comments throws with unused suppression in [libs]

I believe it only shows [LIB] in the path when --strip-root is on. might be as simple as figuring out where that's set and whether it needs to be.

wbinnssmith

comment created time in 2 months

issue closedflowtype/flow-for-vscode

TypeScript types inline import syntax support

Latest versions of VS Code autocompletes types with TypeScript inline imports like so:

types.js

  export type Language = 'en' | 'fr';

index.js

  const language: import('./types).Language = 'en';

It would be very handy if this extension and flow itself supports this feature.

closed time in 2 months

Eugene-Musika

issue commentflowtype/flow-for-vscode

TypeScript types inline import syntax support

this would need to be implemented in Flow itself and would then come for free in this extension. would you mind reporting it there instead? unfortunately we can't move the issue since it's across different github orgs.

Eugene-Musika

comment created time in 2 months

issue openedtc39/test262

Test for ASI in `continue` is ineffective

https://github.com/tc39/test262/blob/25c9e334d301944537215caba1d7f44319f3e0da/test/language/statements/continue/12.7-1.js#L11-L18

this test claims to be testing that "a continue statement without an identifier may have a LineTerminator before the semi-colon".

however, I don't think it's working as intended. if ASI does insert a semicolon after continue, it still passes, just with an extra empty statement.

A test like this would make sure there's no ASI happening:

        var sum = 0;
        for (var i = 1; i <= 10; i++) {
            if (true) continue
            ; else {}
            sum += i;
        }

If it inserts a semicolon, then ; becomes an empty statement and the else becomes a syntax error.

created time in 3 months

issue openedtc39/test262

Add test for EvaluateNew execution order

I couldn't find a test that ensures that EvaluateNew steps 3 and 4 come before step 6: the reference to the constructor is evaluated before the arguments.

specifically, a test case like this:

(function (){var a=function(){};new a((a=1))})()

It should (I believe) construct the function with 1 as an arg, not try to construct 1 and TypeError.

I think this is relevant because this currently fails in JSC (macOS 10.15.3):

% cat test.js
(function (){var a=function(){};new a((a=1))})()
% /System/Library/Frameworks/JavaScriptCore.framework/Versions/A/Resources/jsc test.js
Exception: TypeError: 1 is not a constructor (evaluating 'new a((a=1))')
test.js:1:38
global code@test.js:1:47

created time in 3 months

issue closedfacebook/flow

Class properties is left by flow-remove-types utility

Flow version: 0.120.1 flow-remove-types version: 2.120.1

Expected behavior

Static and regular class properties need to be removed from //@flow files by flow-remove-types utility, because they are in Stage 3 yet and do not supports by all browsers.

class My {
    static name: string; // It is just to for type checking

    getName(): string { return My.name }
}

Must converts to

class My {
    getName() { return My.name }
}

Actual behavior

But flow-remove-types does not make it.

And now output of the utility is:

class My {
    static name // Is not desirable yet
    getName() { return My.name }
}

closed time in 3 months

YevhenKap

issue commentfacebook/flow

Class properties is left by flow-remove-types utility

in flow 0.120, we updated our class fields implementation to match the latest proposal. in the proposal, static name; means static name = undefined;, which is different than the field being completely stripped. flow-remove-types is only for stripping types, and static name: string; is not just a type annotation anymore.

We implemented a declare syntax for type-only class fields, similar to TypeScript's:

class My {
  declare static name: string;

  getName(): string { return My.name }
}

That's the recommended fix, but you can also pass --ignore-uninitialized-fields to flow-remove-types to strip the uninitialized fields... for now. We plan to remove this option in flow-remove-types 3.x, because it does not just remove types.

YevhenKap

comment created time in 3 months

push eventmroch/flow

Panagiotis Vekris

commit sha f6168fa2408c7c2cd064fa6703af0d4f1a3eb600

[Ty] Restructure toplevel type structure Summary: The structure we use to describe inferred types (Type.t) combines cases of *declaration* types (type aliases, class decls, modules, etc.) mixed with *value* types (number, object, etc.). This flat representation makes it harder to enforce invariants in the normalizer that intuitively should exist. E.g. * Type alias, class declaration types, etc. do not nest. * Type aliases, class declarations and modules are toplevel or parts of modules. This diff decouples declarations and types, enforcing the following structure as the output of normalization of a type Type.t (ie. replacing Ty.t): ``` type decl = | VariableDecl of string * t | TypeAliasDecl of { name: symbol; tparams: type_param list option; type_: t option } | ClassDecl of symbol * type_param list option | InterfaceDecl of symbol * type_param list option | EnumDecl of symbol | ModuleDecl of { name: symbol option; exports: decl list; default: t option } type t = ... (* remaining cases of Ty.t from before *) and elt = | Type of t | Decl of decl ``` `Ty.t`s now exclusively correspond to runtime types that program expressions can have, whereas `decl`s are declarations. The rest of the changes here adjust the rest of the repo to this change. Reviewed By: samwgoldman Differential Revision: D20194749 fbshipit-source-id: 64e1c8c2bb8bab1e9bd6cb04b8a1d82e478db5e9

view details

Marshall Roch

commit sha 18128a6fa6b39572ad2840ef8d6841997d4e67bb

fix circleci caching Summary: Pull Request resolved: https://github.com/facebook/flow/pull/8317 Differential Revision: D20315043 fbshipit-source-id: b28011142873764e2284c42f7c450a21eaf57d2b

view details

push time in 3 months

PR opened facebook/flow

fix circleci caching

Differential Revision: D20315043

+20 -10

0 comment

1 changed file

pr created time in 3 months

create barnchmroch/flow

branch : export-D20315043

created branch time in 3 months

PR opened facebook/flow

fix exception with long socket paths

Summary: the C struct used for unix sockets only allocates around 104 characters for the socket path.

for example, consider $TMPDIR/flow/zSpathzStozSroot.sockv3. we try removing the flow/ dir, and then replacing part of the basename with a hash, like $TMPDIR/zSpat.MD5HASHHERE.Sroot.sockv3.

If $TMPDIR is long enough, we still don't have enough space. Worse, when we try to String.sub 0 max_digest_length, max_digest_length could be negative and cause an exception! This is actually responsible for several failing tests in Circle on Windows right now.

Instead, we now chdir into $TMPDIR/flow/ and then use ./zSpathzStozSroot.sockv3 (or the hashed version), which is guaranteed to fit.

Differential Revision: D20313040

+96 -31

0 comment

6 changed files

pr created time in 3 months

create barnchmroch/flow

branch : export-D20313040

created branch time in 3 months

PR closed facebook/flow

debug socket exception CLA Signed

do not merge

+2 -0

0 comment

1 changed file

mroch

pr closed time in 3 months

PR opened facebook/flow

debug socket exception

do not merge

+2 -0

0 comment

1 changed file

pr created time in 3 months

PR closed facebook/flow

debug socket exception CLA Signed

do not merge

+2 -0

0 comment

1 changed file

mroch

pr closed time in 3 months

PR opened facebook/flow

debug socket exception

do not merge

+2 -0

0 comment

1 changed file

pr created time in 3 months

create barnchmroch/flow

branch : socket

created branch time in 3 months

push eventmroch/flow

Marshall Roch

commit sha 1998a09c65583f971285acf51e28a53c930f6cc6

[cleanup] Docblock.preventMunge doesn't need to be an option Summary: it's impossible to end up with `preventMunge = Some false` since, for example, there is no `allowMunge` directive. so it can just be a bool instead. Reviewed By: samwgoldman Differential Revision: D19335275 fbshipit-source-id: 2ee2a41c8de9a791225c7329389a2c2e3f9713a9

view details

Gabriel Miranda

commit sha eb534a474cec770f3223ac16e64bf74bc7f9b111

[PR] Fix fs.promises.mkdir signature Summary: Fixes https://github.com/facebook/flow/issues/8211 Pull Request resolved: https://github.com/facebook/flow/pull/8224 Differential Revision: D19325394 Pulled By: mroch fbshipit-source-id: a90e36bb89930754107e95da0b434f81ea0f9ae6

view details

Daniel Sainati

commit sha 7c0f3bd3811bb2f052e0bbcaf3834f21fc258e7a

turn on strict-sequence and strict-formats Summary: These compiler flags are safer to have than not. Reviewed By: mroch Differential Revision: D19278373 fbshipit-source-id: a1f24e52bebb1d9cadbafad1d0f3d5d68fa8bbe1

view details

George Zahariev

commit sha 204b19dc2dcf7bebe36f2f5aa1b62a598a3a6acd

Remove usage of `Symbol` from lib defs (only use `symbol`) Summary: Last half I added support for symbols as a primitive type (D18661792) using the new `symbol` type. We temporarily made the core lib defs use `symbol & Symbol` to support both until we removed usage of the `Symbol` type in our code. After removing usage of `Symbol` in WWW and Xplat, we can now remove it from our lib defs. Reviewed By: dsainati1 Differential Revision: D19379248 fbshipit-source-id: ff238d13765a7b808332e70b17499315891fc21c

view details

Marshall Roch

commit sha cf88da13c67b64b4eb4fca30026829fec21038b2

[PR] Publish Windows binary from Circle, remove Appveyor Summary: Pull Request resolved: https://github.com/facebook/flow/pull/8261 Differential Revision: D19382157 Pulled By: mroch fbshipit-source-id: d75339b02cfc62994ce4129c8fef02c0aa6e6c4b

view details

Daniel Sainati

commit sha 14f2c234543851c72f3e69154089f997e2cfe964

resolve type destructed unions after creation Summary: When we encounter a type destructor applied to a union type, we push the type destructor down into each element of the union to produce a union of eval types. Normally, when we see a flow involving a lower bound union of eval types, we take the time to evaluate each of the components so that the union is able to hit our optimizations. However, the priority of the tvar rules is such that the result of the type destructor hits is stored in a tvar before its component eval types are resolved. Overall, the process looks something like this: ``` UnionT [X, Y, Z] ~> TypeDestructorTriggerT (f, tvar) UnionT [EvalT (f,X), EvalT (f, Y), EvalT (f, Z)] ~> tvar ``` This means that if the tvar ever appears as an upper bound, we are unable to take advantage of our speculation optimizations, as none of them are capable of peeking inside of unevaluated eval types. Instead, we can flow the eval union produced by type destruction to a `ResolveUnionT`, and let the machinery that already exists for this purpose resolve the evals inside the union, and only then flow the resulting union to the tvar. This lets us hit our optimized checks. This also changes the behavior of `$Diff` with respect to unions. Before, this was pretty broken, so the new behavior should be an improvement. The rules for the new behavior: `$Diff<X | Y, Z> = X \ Z | Y \ Z` `$Diff<X, Y | Z> = X \ Y | X \ Z` Reviewed By: panagosg7 Differential Revision: D18715235 fbshipit-source-id: 3a13059be991fb994f5d33193269cbe3dc771935

view details

Marshall Roch

commit sha c39728b761795a439e08f5764016fa820ed8c06d

[PR] Fix dune after Hack fork Summary: Pull Request resolved: https://github.com/facebook/flow/pull/8216 Reviewed By: dsainati1 Differential Revision: D18847405 Pulled By: mroch fbshipit-source-id: 729e3daf8b17ece3c346c2734cefc373afe106d7

view details

Marshall Roch

commit sha e4a7354ff9b239e4ba11003d53a40fcbacc23540

[PR] fix dune again Summary: Pull Request resolved: https://github.com/facebook/flow/pull/8265 Differential Revision: D19411862 Pulled By: mroch fbshipit-source-id: 6f6b9fcb1fa31849c23962f30edab098278d787b

view details

Marshall Roch

commit sha bf44b686705d7ef05f299cbe471d6e56b2e2f482

improve error when watchman is not installed Summary: when initializing watchman, we call `watchman get-sockname`, looking `watchman` up on the path, and read its stdout. if `watchman` isn't found, stdout never gets set up and reading from it causes an `End_of_file` exception. instead, we can use `LwtSysUtils.exec` and actually get the exit code. code 127 means that the command wasn't found. for completeness, we also handle other exit codes and signals, to improve our logging. (note: watchman failing to init in general still causes an `Uncaught async exception: (Failure "Failed to initialize watchman")`, followup work will improve that) Reviewed By: samwgoldman Differential Revision: D19410461 fbshipit-source-id: 7122b5adec91989d5fd02f2acbab39e8c4561ff6

view details

Sam Goldman

commit sha 7d3aa8e53c4602dca8c2c088196a576dadf15fb9

Drop shm_dirs config Summary: Pull Request resolved: https://github.com/facebook/flow/pull/8258 Flow spawns multiple processes which communicate via shared memory. To make this work, the master process creates a shared file. Unfortunately, the various platforms we support do not all support the same means for creating this shared file. Before this change, we tried one of four different methods: * memfd_create, supported by Linux > 3.17 * shm_open, supported by BSD (OS X) and Linux * a tmpfile in /dev/shm (or configured shm_dir) * CreateFileMapping, a Windows-specific API On Linux, we preferred memfd_create if available, or a tmpfile otherwise. We avoid shm_open because the /dev/shm filesystem is often not large enough to accommodate the requested size. On BSD (OS X), we preferred shm_open if available, or a tmpfile otherwise. On Windows, we always use CreateFileMapping. This diff drops the tmpfile method. On Linux, if memfd_create is not available, we will fall back to shm_open instead. In the case where we would fall back to tmpfile, we will now fail to init. In practice, I don't expect this will ever cause an issue. The most likely failure scenario is where shm_open succeeds but ftruncate fails to resize the file to the requested length. In this case, the solution is to adjust the size of the shm file system. I tried to search for any existing uses of the shm_dir and shm_min_avail configuration, both internally and on GitHub, but could not find any existing uses. Reviewed By: mroch Differential Revision: D19356583 fbshipit-source-id: d01ee025f85d05bfdad0579a2cdfe642da79d289

view details

Marshall Roch

commit sha 042ad916b8fd455b572bc3e2db21d9d8db07aaca

[easy] Printexc -> Exception in Watchman Summary: Exception wraps up this ugly Printexc stuff Reviewed By: samwgoldman Differential Revision: D19430032 fbshipit-source-id: 6a77ae3fc424c519b3431dc058a9f1e654cb9d01

view details

Marshall Roch

commit sha 8180e829ba7641b5fd527a5e6b2faff497dde6dc

unbreak dune again Summary: really gotta add this to CI and maintain it... Reviewed By: dsainati1 Differential Revision: D19434884 fbshipit-source-id: cff3d0f93a0f892de00ca46f81974004ef4f9851

view details

Marshall Roch

commit sha 0131ccb799f26894c9ea99d54c8268fa6ef7d006

[PR] [circle] improve caching of Mac builds Summary: brings the `build_mac` job's time **with a warm cache!!!** from 31 minutes to 9 minutes (7 min building flow, 1 min building libflowparser, 1 min overhead). saves 10 minutes on cold caches too, by getting rid of `brew`. Pull Request resolved: https://github.com/facebook/flow/pull/8262 Reviewed By: dsainati1 Differential Revision: D19387551 Pulled By: mroch fbshipit-source-id: 95f66e5e2326f7f6e77f0f4635f06ddd3ccd61c7

view details

Nat Mote

commit sha 5239c4c08ae44549d4141d20000eb870e659ed08

Fix endless recheck loops Summary: Starting in Flow v0.115.0, we began to get reports of Flow getting stuck in a recheck cancellation loop. I believe that D18739041 is to blame: it caches promises (`Lwt.t`s), which can complete nondeterministically even if the underlying computation is deterministic. This happens when something external to the computation triggers a cancellation. At that point, `Lwt` bubbles up an `Lwt.Canceled` exception. Because we cache that promise, subsequent cache hits get canceled unintentionally, leading to endless retries. This change makes the `Cache` data structure aware of `Lwt`. This way, it will cache results rather than the promises themselves. Fixes #8259 Reviewed By: mroch, panagosg7 Differential Revision: D19435541 fbshipit-source-id: 0062c2dd7be8dfad4cb89bd9923ad1e6e0992e8f

view details

Marshall Roch

commit sha f6d97596254982dda8f4a15f209669a706c44231

kill the server when monitor can't start file watcher Summary: when we can't init watchman, we raise an exception which bubbled all the way up and fataled the monitor process. in practice, this is ok because we exit anyway when we can't init watchman. handling it fixes the monitor process's exit code, improves logging, and properly notifies the server process to shut down instead of it just noticing that the monitor's pipe is unexpectedly closed. it'll also let us react better in the future (e.g. try watchman again). Changelog: fix: Fixed `flow server` exit code when watchman can't be initialized Reviewed By: avikchaudhuri Differential Revision: D19431136 fbshipit-source-id: b75f111085b8487d97cb6ebcb8070438b5de74d0

view details

Nat Mote

commit sha 9c8b40e2156e74ef053a58e2f6263cc326b17ab2

v0.116.1 Reviewed By: dsainati1 Differential Revision: D19439228 fbshipit-source-id: 5e5f103299d44956a173055a086d6a6ffb2fba35

view details

Marshall Roch

commit sha c9f11bfa81590601e9e239af7a4569e359e0c122

[PR] [circle] set OPAMDOWNLOADJOBS=1 on Windows Summary: when multiple opam packages have the same source, like `dune` and `dune-configurator`, and opam downloads them in parallel, there's a race in which they both try to write the same file to the cache. it seems that on Windows, the `cp` fails with `permission denied`, while on other platforms the `cp` just overwrites. by turning off parallel downloads, opam skips downloading the duplicate source because it's already cached. See fdopen/opam-repository-mingw#71 Pull Request resolved: https://github.com/facebook/flow/pull/8268 Differential Revision: D19449255 Pulled By: mroch fbshipit-source-id: a695c160026d523fb59412793f49fc74ec7d112e

view details

Luke Page

commit sha 2b2aa138d4acc65f112ddd8a5c7ab6ed1d7e6dc4

[PR] Add dir to Document Summary: https://developer.mozilla.org/en-US/docs/Web/API/Document/dir Pull Request resolved: https://github.com/facebook/flow/pull/8226 Reviewed By: panagosg7 Differential Revision: D19452438 Pulled By: dsainati1 fbshipit-source-id: 096ed2d71bb32c6594c9c6f14dc0133e0ad44753

view details

Daniel Sainati

commit sha 7f78643958f946e95f7b852b2911be79d0a9d83b

distinguish between union branches for polymorphic instantiation caching Summary: Consider the following code: ``` type Filter = [number] | [string]; function convert(filter: Filter) { filter.slice(0); } ``` When we call `slice` on the `filter` object, this produces a `UnionT ~> MethodT` flow, which decomposes into two separate `t ~> MethodT` flows, one for each branch of the union. It is important to note, however, that because `t` in this case is a tuple (this also applies to arrays and read-only arrays), the two `t`s in each of these flows have the same reason. When we later attempt to instantiate the polymorphic type of the return of `slice`, we unify these two `t`s with a tvar representing the return of `slice`. Unfortunately, because we use reasons to implement the polymorphic instantiation cache, and because these two `t`s have the same reason, we attempt to unify both `t`s with the same type variable, and thus get an incompatibility between `number` and `string`. This changes the instantiation cache to take into account the `desc` of the `reason_tapp`, and changes the union lower bound decomposition logic to modify the reason of each of the lower bounds with a "transparent" (in that it will not show up in any error output) description that differentiates between the different branches of the union. This way, the cache will properly recognize the difference between these two types and correctly produce a different unification variable for each case. Fixes #8263 Reviewed By: mvitousek Differential Revision: D19436341 fbshipit-source-id: da44513d8727f3339c71a453f46b536912d295bc

view details

Panagiotis Vekris

commit sha 4746f6aa2306fef9651c14eecc9eeb05e300c1d6

Back out "[Flow][normalizer] Fix bug in normalizer cache" Summary: Original commit changeset: 6405a6fd4418 Reviewed By: samwgoldman Differential Revision: D19526515 fbshipit-source-id: 690bfb7afd4084ff5d757f1e526bc646b2df6cc7

view details

push time in 3 months

issue openedmicrosoft/language-server-protocol

Clarification: can `SignatureHelp.signatures` be an empty array?

The interface for SignatureHelp (as of 3.15) says that signatures contains "one or more", but then activeSignature talks about signatures.length === 0.

export interface SignatureHelp {
	/**
	 * One or more signatures.
	 */
	signatures: SignatureInformation[];

	/**
	 * The active signature. If omitted or the value lies outside the
	 * range of `signatures` the value defaults to zero or is ignored if
	 * `signatures.length === 0`. [...]
	 */
	activeSignature?: number;

	[...]
}

It also says "Signature help represents the signature of something callable" which suggests that when the Position is not something callable, the correct response is null, not { signatures: [] }.

If that's the case, I think the docs for activeSignature should not mention signatures.length === 0. Further, why would activeSignature ever be outside the range of signatures? It's confusing that it talks about all these invalid states.

created time in 3 months

more