Allow to suppress import in typedef JSDoc parse error.

[zavr-1]

This is to allow writing stuff like because everyone is using import since VSCode has enabled it. It'd be great to have this in Closure as well otherwise types have to be imported via externs and that stops advanced mangling.

/**
 * @suppress {nonStandardJsDocs}
 * @typedef {import('restream').Rule} restream.Rule
 */

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here (e.g. I signed it!) and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[brad4d]

Created internal issue http://b/130218393

[brad4d]

I believe this PR is intended as a step toward resolving #3041

[brad4d]

@zavr-1 you'll need to accept the CLA before we can go any further here.

[zavr-1]

@googlebot @brad4d I signed it!

[brad4d]

@zavr-1 maybe you should try to sign the CLA again, since the check for that is still failing?

[brad4d]

@zavr-1 or maybe just double-check the instructions for CLA signing. Looks like there are a few things that could be out of whack (email address mismatch, etc.)
Thanks.

[zavr-1]

@brad4d hi i've signed it yesterday but it got voided as I'd signed with wrong title, today I've changed the title to the correct one so I suppose just waiting for it to be checked again.

[brad4d]

@zavr-1 I took a look at a view of the CLA state I get as a Googler for this PR.

It's the first time I've ever needed to do that, so I'm not really familiar with it.
However, it looks like there's some kind of mismatch between the email address recorded in the GitHub commits and the PR sender.

Basically it seems to say that @zavr-1 is the PR sender, but with no known email address.
While the email of the GitHub committer is [REDACTED], which has no known GitHub user name.

FTR, I the UI also had a "Force Rescan" button, which I clicked, but resulted in no change of state.

[googlebot]

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

[zavr-1]

@brad4d ok just as I commented the bot got it (thanks @googlebot green is 💚 beautiful)! Thanks for looking into it btw. Also this is why I need this PR https://github.com/artdecocode/typal/ (cmd-f to @suppress to get straight to the point).
all best

[brad4d]

PR imported and sent for testing.

[brad4d]

minimal testing was successful
sending for "test all the things" testing
FYI, I needed to do a minor fix in JsDocInfoParser.java.

typeNode.getString() == "import" => "import".equals(typeNode.getString())

I haven't bothered to push that back to the PR branch, though.
Some permissions errors I encountered when importing the PR probably mean I don't have permissions needed to do that anyway. (Before you ask, I don't remember the error details now, just that my standard procedure for importing didn't work in some way.)

[brad4d]

I'm submitting the internal change today.
I expect it to be pushed to GitHub tomorrow.

@zavr-1
BTW, I'm not sure this will really solve your original problem.
Errors with parsing JSDoc that get caught at code-parsing time rather than later can't really be suppressed because they happen at a point in the compiler where the suppression logic doesn't get invoked.
I'm not sure this will be a problem for you, but I thought I should at least warn you it could be an issue.

[zavr-1]

@brad4d thanks for you time into working this pr through. Also I've had successfully suppressed these errors in many packages now so not sure what you say is correct, sorry. I've been testing this feature on the custom build quite extensively. nonStandardJsDocs always worked perfectly well with all the

/**
 * @suppress {nonStandardJsDocs}
 * @typedef {import('test').Test} test.Test
 */

I'll be looking into making the necessary changes to actually enable the import statements in due time. It would amazing if all it got down to resolving the type names to strings like Test$$module$tt (for import Test from './tt') but it's probably not as easy, so I'll try to understand the JSDoc code and its relation to the actual "types map" better.

[brad4d]

@zavr-1 I'm glad to hear it works for you.
I didn't know for certain it wouldn't, just thought you might hit the problem I'd seen before.

Re: closure-compiler support for dynamic import the tracking issue is #2770