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

call of method get Unknown global name. But why ? #212

Closed
ghost opened this issue Jan 10, 2015 · 4 comments
Closed

call of method get Unknown global name. But why ? #212

ghost opened this issue Jan 10, 2015 · 4 comments

Comments

@ghost
Copy link

ghost commented Jan 10, 2015

This is the code:

 var req = https.get(request, function(res) {
      res.setEncoding('utf8');

and this is the declaration

declare module "https" {
    declare function get(config: https$Config, callback: (res: https$Response) => void): https$Request;
}

This gives me "call of method get Unknown global name". But why ?

@garetht
Copy link

garetht commented Jan 15, 2015

I'm also getting this, and as far as I can tell it seems to occur with Node module names. In this simplified example requiring https and declaring the module https produces the error, changing both to fs or stream produces the error, but changing it to a non-core Node module name does not.

Code

var M = require("https");
M.foo()

Declaration

declare module https {
  declare function foo(): void;
}

Output

.js:3:1,7: call of method foo
Unknown global name

@garetht
Copy link

garetht commented Jan 15, 2015

This probably has to do with the interaction of the core library definitions and the user's. The error seems to arise because the https and other node declarations have not yet been implemented in the core library. I downloaded and built the latest version of flow and ran it with the --no-flowlib option, which removed the error.

I think the bug here might be unexpected behavior when two or more declaration blocks for the same module are present. I would expect one of them to override the other, rather than each being considered as a separate block.

@ghost
Copy link
Author

ghost commented Aug 5, 2015

Thank you for reporting this issue and appreciate your patience. We've notified the core team for an update on this issue. We're looking for a response within the next 30 days or the issue may be closed.

@gabelevi
Copy link
Contributor

gabelevi commented Aug 5, 2015

We are planning to introduce some way to override declarations eventually. Let's use #396 to track that.

@gabelevi gabelevi closed this as completed Aug 5, 2015
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