This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Created attachment 116491 [details] screenshot of CC See attached screenshot. When the comment is unfinished, I'm not able to choose @var annotation item from the CC list. It's related to my question from begging of the week - I was pretty sure that the annotation var wasn't there but I was confused why it worked to me at work. :)
It's because your PHPDoc block involves your field definition...so the context is not recognized as a "field" context...there is no PHP token for a field. Just method context is recognized :) So there is only one way how to solve it. I'll have to enable @var annotation for method context as well. It's quite dirty, but unfortunately there is no other solution.
Just an idea... I don't code around, but wouldn't be better/possible to fix that with sanitizer? It would mean, that you could try to complete the comment virtually and offer complete CC then. But as I said, I don't code around, just a thought.
Yes I had it in my mind too, but I'm afraid that it will not be as easy as it looks like. I can try it later, it will not be fixed today.
(In reply to comment #3) > Yes I had it in my mind too, but I'm afraid that it will not be as easy as it > looks like. I can try it later, it will not be fixed today. Sure, no problem once I know that it's easily WAable. ;) I was thinking that another fix could mean slow end of context sensitive CC, so that's why I would prefer sanitizer. Thanks a lot Ondro...
Hmm...I think that only "AST broken" source should be sanitized, shouldn't be? But this: <?php class ClassName { /** @v private $field1; /** */ function __construct() {} } ?> ...is valid PHP source. So we have to break it somehow...e.g. to don't allow "/**" token inside a PHPDoc comment...but it's allowed by PHP grammer. Hmhm. And your case, where @var is not suggested, is just for fields directly before method declaration. If you try this snippet, it works, because "the next element" is field again ;) <?php class ClassName { /** @v private $field1; /** */ private $field2; /** */ function __construct() {} } ?> Quite funny issue...
(In reply to comment #5) > Hmm...I think that only "AST broken" source should be sanitized, shouldn't be? It probably depends what should or shouldn't. :) It crossed my mind just because it looks to me like a way for optimal fix (instead of violating context sensitive CC). So since you have features available in comments it seems to me valid to sanitize little bit comments as well (if it's possible). > ...is valid PHP source. So we have to break it somehow...e.g. to don't allow > "/**" token inside a PHPDoc comment...but it's allowed by PHP grammer. Hmhm. I undestand that it's not simple at all. :/ > > And your case, where @var is not suggested, is just for fields directly before > method declaration. If you try this snippet, it works, because "the next > element" is field again ;) I know. On the other hand when I'm adding new field (which doesn't belong to some category), it's every time to the last position. > Quite funny issue... Really is. Ondro, feel free to resolve that in any of your ways. I believe that you do your best as usually. :)
After some discussion -> P4.