Function parameter types should default to what is doc'd if a type cannot be computed

[mrennie]

Use the following snippet in the Tern demo:

/**

• @name f
• @param {Number} one the first one
• @param {orion.Editor} two
  */
  function f(one, two, three) {
  loop: do{
  t//ASSIST HERE
  //empty
  continue loop;
  } while(true)
  }

Activate assist where indicated and notice the type for 'two' is computed to be '?' I would expect it to be 'orion.Editor' since thats what I said it is.

[marijnh]

Is it possible that Tern can not find a type called orion.Editor?

[mrennie]

Yes, that type would not be available in the demo, but I assumed that since the demo was using the doc plugin it would be able to infer the type as orion.Editor. Or does tern ignore what is specified in doc if it cannot find the type while inferring?

[marijnh]

Tern currently doesn't have a mechanism for storing types that it only knows the string name of -- it works with type objects that it either got from loading a .json definition file or from analyzing the code itself. You could write a simple .json file that defines orion.Editor and the other types you need, as a way to work around this.

[jgiles]

Alternatively, the third-party tern-closure plugin creates stand-in types for types in docs that it cannot locate (meaning that an orion.Editor type would be reported, though it probably wouldn't have any useful information until the file where orion.Editor is defined was loaded).

[marijnh]

@jgiles That sounds good. How did you solve the problem of the made-up type introducing ambiguity later on?

[jgiles]

@marijnh At present, stand-in types are just propagated with a low weight, and when the actual value is declared and assigned later it displaces the stand-in.

[marijnh]

Attached patch adds something like this to the doc_comments plugin.