Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

conditional variable assignment results in: undefined Missing annotation #219

Closed
tommilimmot opened this issue Jan 15, 2015 · 2 comments
Closed

Comments

@tommilimmot
Copy link

/* @flow */

var evil;
var name = evil ? 'Frank' : undefined;

results in error

/* @flow */

var evil;
var name;
if (evil) name = 'Frank';

doesn't

I'd prefer the one-liner over iffing. Is there a reason why the variable has to be declared first?

@mroch
Copy link
Contributor

mroch commented Feb 18, 2015

does this still repro? it doesn't error for me in 0.3.0

$ echo "var evil; var name = evil ? 'Frank' : undefined;" | flow check-contents
No errors!
$ echo "var evil; var name = evil ? 'Frank' : undefined; var f = name[0];" | flow check-contents

-:1:58,64: access of computed property/element
Computed property/element cannot be accessed on possibly undefined value
  -:1:39,47: undefined

Found 1 error

so it definitely knows that name can be undefined or a string.

@tommilimmot
Copy link
Author

Works with 0.4.0! Thanks

facebook-github-bot pushed a commit that referenced this issue Oct 31, 2016
Summary:
The `hh_show` pseudo-function is very useful for debugging Hack type inference: it displays on the terminal the type that Hack believes an expression to have at the point that it type checks the line in which it occurs. (So, for example, it will show multiple times in a loop as Hack seeks a fixed point.)

But there is currently no way to dump any other aspect of Hack internals such as the type parameter environment. This diff rectifies this situation. It introduces a new nullary pseudo-function `hh_show_env` that causes Hack to dump information about its environment, including:

* The types of all locals (`local_types`)
* The lower and upper bounds on all type parameters in scope (`tpenv`)
* The state of the type-variable-to-type variable substitution (`subst`)
* The state of the type-variable-to-type environment (`tenv`)

The last two aren't shown in full but instead as a delta from the previous time that `hh_show_env` was called.

Some other aspects:
* Colour display, with indentation!
* The position information of the `hh_show_env` command is shown above the environment information, with an iteration number in square brackets (because it might be invoked more than once e.g. round a loop).

The `hh_show` command is also improved, to display this position information.

Finally, type variable numbers are shown in types so that the `subst` and `tpenv` parts of the environment can be debugged.

Here is an example: the test `erling_loop5.php` with `hh_show_env()` inserted at the end of the inner loop. The output from `hh_single_type_check` is as follows:
```
File "erling_loop5.php", line 34, characters 5-17:[1]
  local_types
    $obj: X as X<#216(int | string)>
    $x: (int)
    $y: (int)
    $z: (int | string)
    $i: int
  subst(changes)
    #199: #216; #201: #212; #212: #214; #214: #216;
  tenv(changes)
    #198: [unresolved]; #199: [unresolved]; #200: [unresolved]; #201: int; #212: int;
    #214: int; #216: (int | string);
File "erling_loop5.php", line 34, characters 5-17:[2]
  local_types
    $obj: X as X<#223(int | string)>
    $x: (string | int)
    $y: (int | string)
    $z: (int | string)
    $i: int
  subst(changes)
    #223: #223; #216: #219; #219: #221; #221: #223;
  tenv(changes)
    #219: (string | int); #221: (int | string); #223: (int | string);
```

Reviewed By: dabek

Differential Revision: D4068570

fbshipit-source-id: cb96d5178bc41f73a8ddd8776ab7f91f69de2b71
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants