Suppress a particular "not assignable to parameter type" inspection?

In my JS file I have declared an @enum type POSITION and a function foo declared to take @param {POSITION}.  This works beautifully.  However, I have one piece of code that makes a POSITION by using string methods instead of passing around known POSITION strings.  When I pass one of these to foo, I quite correctly get the warning "Argument type string is not assignable to parameter type POSITION".  Is there a way to suppress just this instance of the warning?  I looked around for possible noinspection values from a list someone made (https://gist.github.com/discordier/ed4b9cba14652e7212f5), but the one that seemed the closest doesn't do anything:

    // noinspection JSValidateTypesInspection
    var result = foo(pos);


Is there a better value?

And in general, is there an authoritative mapping from inspections to these magic noinspection values?

(Actually, I can't find this inspection in Settings, so I don't know how I'd even suppress it globally.)
10 comments
Comment actions Permalink

Hi there,

Alt+Enter while having caret on problematic place and choose corresponding entry from Quick Fix menu, e.g.
http://blog.jetbrains.com/webstorm/files/2015/06/disable-inspection.png
That works if warning/notice produced by actual Inspection and not by Lexer/Parser (which is a lower level thingy and is not suppressible)

(P.S. Image taken from http://blog.jetbrains.com/webstorm/2015/06/10-webstorm-shortcuts-you-need-to-know/ )

0
Comment actions Permalink

Fine generic advice, but no help in this case -- Alt-Enter offers no inspection options.

FWIW, It also offers no inspection options for by far my most common warning: unresolved variable (and there is an inspection for that, which I could turn off globally in Settings if it annoyed me enough).

0
Comment actions Permalink
FWIW, It also offers no inspection options for by far my most common warning: unresolved variable (and there is an inspection for that, which I could turn off globally in Settings if it annoyed me enough).

Ok...

var b = aaa + 1;


screen02.png

screen01.png

0
Comment actions Permalink
Fine generic advice, but no help in this case -- Alt-Enter offers no inspection options.

Would be great it you could provide standalone example (file(s) that I could load locally and see myself).

0
Comment actions Permalink

My mistake.  For some inspections, Alt-Enter has a menu item "Inspection 'name of inspection' options", and if you click it you get a submenu with options that include global and sometimes local suppression.

For other inspections, Alt-Enter gives no clue that there are any suppression options.  You have to click the little arrow on the right edge of one of the corrections offered to get the submenu (and be careful not to miss, or it will run the cleanup instead of showing the submenu!).  I always wondered why menu items that looked like they might have submenus never opened for me when I rolled over them (unlike every other hierarchical menu system I'm familiary with).  The UX could use a little help here.

For the record, the answer to my original question turns out to be

    //noinspection JSCheckFunctionSignatures

0
Comment actions Permalink
(and be careful not to miss, or it will run the cleanup instead of showing the submenu!)

"Use keyboard, Luke" (c)

Have you tried arrow-right ? Nice and safe.

------

But yes -- overall you are correct -- it's not that easily discoverable if you have not seen it used by somebody else before.

0
Comment actions Permalink

Thanks for the tip, that should come in handy.

0
Comment actions Permalink
I always wondered why menu items that looked like they might have submenus never opened for me when I rolled over them (unlike every other hierarchical menu system I'm familiary with)

For situation like from my last screenshot, the "Create variable 'aaa'" entry is a primary action (activated if you press Enter or mouse click), the submenu is secondary and very unlikely that will be needed by many users (as compared to the primary action). That's for "why submenu is not shown when I hover over".

Plus, the overall idea/approach from devs on all these inspections -- the "suppress inspection" should be used very rarely when inspection's logic fails and ideally instead of just suppressing you should be reporting the issue to the Issue Tracker for devs to investigate (that's, of course, is debatable and depends on situation -- some code could be written/organized badly so inspection fails.. or inspection simply does not yet support (and/or unlikely to support in nearest future) your specific setup/logic). In some cases devs accept such as bugs/feature requests, in some cases will advice to just use suppress.

If you think that IDE is definitely incorrect in your case, then it could be worth submitting such ticket to the Issue Tracker ...

0
Comment actions Permalink

Well, "definitely incorrect" is a strong statement, but it certainly is "inconsistent UI".  In every program I know with hierarchical menus, rolling over a menu item automatically opens its submenu.  And clicking on the main menu item itself does nothing.  If nothing else, this is how Webstorm's own main menu bar and context menus work.  A more consistent UI would use the regular hierarchical menu behavior and have another menu item named something like "more options".  After all, it's kind of weird that the menu for "unresolved variable" has 3 menu items, all of which have the same submenu!  Even if I know about the menu behavior, I'm led to wonder, "is suppressing via the 'create variable' submenu different than suppressing via the 'create parameter' submenu?"

Now that I know that Alt-Enter is displaying a different kind of tool that only superficially looks like a conventional hierarchical menu, I can adjust my expectations.  But this seems like an unecessary extra part of the learning curve for a new user (and I'm not that new, but for some reason my UI expectations never led me to try to open up those submenus before).

As for how frequently I need the submenu, my code gets lots of warnings on unknown property references, because some of my objects are created by loading them from a database, rather than explicitly setting each property somewhere in visible code. I haven't figured out a way to use JSDoc to declare the set of properties one of these objects could have.  (As it is, 'undeclared property" as an inspection is pretty weak, since it seems to only happen on properties that are set nowhere in my code on any kind of object.  But to do better is probably impossible in JS.)

0
Comment actions Permalink

Please note:

1) my "definitely incorrect" was referring to the actual inspection and not UI.

2) on my last screenshot both entries with light bulb icon have the same submenu. That's because they are Quick Fixes (Intentions?) that are linked to the same Inspection.

0

Please sign in to leave a comment.