New Extension - Naggy

Go To Last Post
132 posts / 0 new

Pages

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Senthil,

Thanks for Naggy - its a great add-on.


Thanks. Glad you like it.

clawson wrote:

BTW one nice feature in AS6.1 is that as soon as you'd posted the update then the next time I started Studio it popped up to say "a new version of Naggy is available".

I'd turned on the "Don't show this again" box on that update popup a long while back and totally forgot about its existence.

One shameless self-plug post once in a while is ok I guess? :)

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry, but it doesn´t work in AS6.1. it produces obscure errors in sources which where compiled without errors previously.

One example I described here:
http://son.ffdf-clan.de/include....

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

peter9999 wrote:
Sorry, but it doesn´t work in AS6.1
Could you post a complete test case/project that doesn't work? The link you posted was in a non English language and didn't seem to have a complete test case that I could reproduce and debug.

And does that bug occur in AS 6.0 as well?

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Senthil,

You can use Google to translate. The error he's talking about is not at the end of the page where he linked to but in the first post. He uses the C99 feature :

 for (int i=0; i

at two places in the code and is getting warned about "redefinition of i" so it sounds like Naggy's parsing code may not be aware of the limit on the name scope of i. My guess is that once it's seen the definition it may be thinking the name remains in scope until the end of the function.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Cliff. I just pushed in a commit that turns on C99 mode in Naggy if it sees -std=gnu99 or -std=c99 on the Atmel Studio compiler command line. That fixes this and other C99 syntax related issues.

Peter, the fix should be available in the next update of Naggy.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi saaadhu, thank you for the quick response!

peter

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Senthil,

I think you might call this a bug now the Naggy errors are added to the error list. If you open a file such as iom32.h for editing (just to look up a bit name or something) then it floods the Error List with warnings. For example the #error near the top about not including it directly and in the iom32.h a whole load of warning about the "poison" macros.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah - I have a partial fix for that in the latest version (should be available in a day), but now I'm wondering if I should even attempt to run Naggy on header files that are not part of the solution.

Thanks for letting me know.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Saaadhu,

thank you very much for Naggy - I had been looking for some way to use LLVM instead of GCC, but in fact what Naggy provides might be enough.

But Naggy (in Atmel Studio 6.0) is giving me tens of nonsense warnings and errors in projects that otherwise compile without warnings and run correctly; looks like Naggy is not really honoring the includes. I have a feeling that this might have something to do with my filesystem organization / include directories configuration / files added as links to the solution, but no idea.

So, I would like to ask for some option to see the output of clang's run (console? some log file?). Maybe that way some hint about what's happening could be gathered...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hmijail wrote:

But Naggy (in Atmel Studio 6.0) is giving me tens of nonsense warnings and errors in projects that otherwise compile without warnings and run correctly; looks like Naggy is not really honoring the includes. I have a feeling that this might have something to do with my filesystem organization / include directories configuration / files added as links to the solution, but no idea.

The include file path settings are picked from the project file. Are you using an external make file or Studio's build system? Can you attach a sample project (either here or at https://github.com/saaadhu/naggy...) that shows the issue?

hmijail wrote:

So, I would like to ask for some option to see the output of clang's run (console? some log file?). Maybe that way some hint about what's happening could be gathered...

There's no console/log right now. I don't actually have Clang compile the file - I only ask it to do a syntax/semantic check and give me the diagnostics, and all of them happen in-memory. I should probably do some kind of logging though.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

saaadhu wrote:
The include file path settings are picked from the project file. Are you using an external make file or Studio's build system?

Studio's build system.

saaadhu wrote:
Can you attach a sample project (either here or at https://github.com/saaadhu/naggy...) that shows the issue?

I'll try later.

saaadhu wrote:
There's no console/log right now. I don't actually have Clang compile the file - I only ask it to do a syntax/semantic check and give me the diagnostics, and all of them happen in-memory. I should probably do some kind of logging though.

If that provides even more information, why not :).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have tried creating an issue in GitHub to attach the example project, but I don't see an option to attach random files there, only images. So I'm posting it here.

The solution file is PRB-ADC1/PRB-ADC1.atsln . I didn't want to alter much the directory structure in case it has anything to do - since the problems I'm seeing seem somewhat random. The zip file is 47 KB, but the source in fact is a few tens of lines, mostly comments and #defines.

Interesting things:

  • The program compiles without even a warning
  • Naggy complains about TIMER8_0 not being defined, though it is, via the #include "lib_mcu/timer/timer8_drv.h"
  • That complaint disappears if the #include commented out or moved before the other #include
  • When opening timer8_drv, Naggy finds errors even in the comment lines
  • Those comment lines cause no complaint if copied to a new file
  • the line numbers reported by Naggy are always nonsense

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hmijail wrote:
I have tried creating an issue in GitHub to attach the example project, but I don't see an option to attach random files there, only images. So I'm posting it here.

The solution file is PRB-ADC1/PRB-ADC1.atsln . I didn't want to alter much the directory structure in case it has anything to do - since the problems I'm seeing seem somewhat random. The zip file is 47 KB, but the source in fact is a few tens of lines, mostly comments and #defines.

Interesting things:

  • The program compiles without even a warning
  • Naggy complains about TIMER8_0 not being defined, though it is, via the #include "lib_mcu/timer/timer8_drv.h"
  • That complaint disappears if the #include commented out or moved before the other #include
  • When opening timer8_drv, Naggy finds errors even in the comment lines
  • Those comment lines cause no complaint if copied to a new file
  • the line numbers reported by Naggy are always nonsense

All the problems go away if I put a space between the / and the * in the first line of timer_drv.h i.e. change
//********
to
// ***

Does that fix it for you as well? Make that change, save the header file, and then type something in the .c file to trigger a reparse, and see if the error goes away.

Looks like a bug in the Clang lexer :). I'll check if the latest code in Clang's trunk fixes this problem.

The number before the colon in Naggy's diagnostics is the diagnostic code - not the line number, in case you misread it. The line/column number show up in separate columns in the error list. The code can be used to blacklist certain diags that are bogus or gcc/avr specific.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

saaadhu wrote:

All the problems go away if I put a space between the / and the * in the first line of timer_drv.h i.e. change
//********
to
// ***

Does that fix it for you as well?

Yes, that fixes it.
Interestingly, even though Doxygen plays a lot with the different comment formats, it seems to avoid using the sequence //* . Maybe there is something about it?

saaadhu wrote:
Make that change, save the header file, and then type something in the .c file to trigger a reparse, and see if the error goes away.

Needing to type something to trigger a reparse feels wrong to me. Can't/shouldn't that be automatic? (of course I have no idea how difficult that would be...)

saaadhu wrote:
Looks like a bug in the Clang lexer :). I'll check if the latest code in Clang's trunk fixes this problem.

Great, thanks.

saaadhu wrote:
The number before the colon in Naggy's diagnostics is the diagnostic code - not the line number, in case you misread it. The line/column number show up in separate columns in the error list. The code can be used to blacklist certain diags that are bogus or gcc/avr specific.

Sorry, I totally misread it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

After changing some of those //** comments, other strange errors are coming to the front. Now Naggy errors on "unknown type name uint16_t" (and lots of others) in various header files (as spi_drv.h from the Atmel CAN libs), which I'd say don't do anything different from other header files which don't cause errors...

I guess I will have to wait for some way to track better the reason for these errors.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,
uint32_t and bool still not recognized in 0.3.2.
Example:
bool isHere = false; // is producing "968: expected expression"

uint32_t myNbr = 0; // is producing "1127 : unknown type name 'uint32_t"

a #define MY_NUMBER 3 in an included file of an include file makes that is is not beeing recognized in the outer file (include file nesting) => "2694 : use of undeclared identifier 'MY_NUMBER'"

The command line (AVR32/GNU C Compiler => Miscellaneous) contains "-std=gnu99" as stated by you, but it does not help.

Any ideas?

Thanks & regards

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Any ideas?

Sounds like you aren't doing:

#include 
#include 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

Any ideas?

Sounds like you aren't doing:

#include 
#include 

They were already included through main.h => asf.h => compiler.h

But I included now both again, explicitly in main.h, compiled => no more errors :D
Then commented both files out again from main.h, compiled (after doing a "Clean") => no more errors :?:

Sounds as if Naggy needed a refresh to the (nested) included files...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

See this example:
- foo.c includes(i.e.) stdint.h, defs.h and foo.h in the right order and uses

uint32_t myFoo[MY_DEF_CONST];

(see below)
- foo.h contains the line

extern uint32_t myFoo[MY_DEF_CONST];

- defs.h defines

#define MY_FOO_CONST 10

then
- compiler shows no error
- foo.c shows no Naggy problems
- foo.h (Naggy) shows

    1127:unknown type name 'uint32_t
    2694:use of undeclared identifier 'MY_DEF_CONST'

Any ideas? All this red lines in the .h - files are not really beautiful...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Any ideas? All this red lines in the .h - files are not really beautiful...

Ok, I really should get off my butt and push out another update :(

Yes, header files are a problem - Naggy parses each editor buffer in isolation. It therefore doesn't know that you included stdint.h in foo.c file when parsing foo.h file.

I'd assumed that most header files would be complete i.e., they'd include all the headers needed to compile. Doesn't look like that's the case, at least with the Atmel Studio crowd :)

I'll push out a new version in the next couple of days to make Naggy ignore parsing of header files. Unfortunately, that's the only solution I can think of right now. I'm all ears if someone can think of a better one.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

saaadhu wrote:
Quote:

Any ideas? All this red lines in the .h - files are not really beautiful...

Ok, I really should get off my butt and push out another update :(

Yes, header files are a problem - Naggy parses each editor buffer in isolation. It therefore doesn't know that you included stdint.h in foo.c file when parsing foo.h file.

I'd assumed that most header files would be complete i.e., they'd include all the headers needed to compile. Doesn't look like that's the case, at least with the Atmel Studio crowd :)

I'll push out a new version in the next couple of days to make Naggy ignore parsing of header files. Unfortunately, that's the only solution I can think of right now. I'm all ears if someone can think of a better one.


Ideas:
    Maybe a "Configuration" - Window, like AStyle does, also with checkboxes to switch parsing of h-files on/off?
    Maybe a configurable list of "common includes" to be parsed with the opened file? Also because you can include special files at compile time, with "-include" - flag and those would lead always to an error.
    I think, if not possible in a configuration window, also a project specific text file (like the blacklist, but at project level) may do the job.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I guess any solution you try to implement at the editor buffer level will just be a stopgap with lots of uncovered corner cases. To avoid that, shouldn't LLVM be run on the same level than GCC?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hmijail wrote:
... To avoid that, shouldn't LLVM be run on the same level than GCC?

I think that is a good idea; at least it should run more often.

Please consider this situation: a .c-file and the header file; with the c-file including the header file, of course.

When I type a new statement in the c-file using a currently undefined e.g. CONSTANT, Naggy will highlight this fact. Very nice, this is how it should be.

OK, I go to the header and type there the definition for the CONSTANT. Should be ok.

Well, it compiles ok, but Naggy still highlights the undefined CONSTANT in the c-File. Only when I touch the c-File, Naggy finds that the issue has be resolved.

I found myself looking for the cause of the issue twice today, only finding that Naggy had not been triggered.

Regards,
Paul

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I didn't really understand about running at the same level as GCC. Naggy sees exactly the same thing as GCC does - except that it has to deal with in-memory (unsaved) files. Would you elaborate a bit on what you meant?

The example that Paul gave is fixable though - running Naggy whenever the focused editor changes will make the squiggle go away. Making it work if the header file wasn't saved is more trickier though. I'm working on an update that fixes this and a couple of other problems - I'll push out the update sometime next week.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Saaadhu, I disagree - Naggy is not seeing "the exactly same thing" as GCC, since Naggy misses includes that GCC does see. I guess Naggy is not doing a full preprocessor pass?

And so that's what I meant about Naggy running at the same level than GCC: so it sees full translation units, instead of usaved buffers + some includes.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Senthil,

Silly question but is there any way just to temporarily turn Naggy off. Some times (if I switch target processors a few times) it seems to get confused about what the active header files are and will red line things I know to be valid.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hmijail wrote:
Saaadhu, I disagree - Naggy is not seeing "the exactly same thing" as GCC, since Naggy misses includes that GCC does see. I guess Naggy is not doing a full preprocessor pass?

No, Naggy uses Clang under the hood, and therefore does everything a compiler would do except for emitting code.

That said, there are a bunch of things that can cause Naggy to emit incorrect diagnostics.

Macros automatically defined by avr-gcc
Headers automatically included by avr-gcc
GCC specific language extensions.
Inline assembly
Naggy misreads project settings

While full fidelity is not gonna happen, I do try and make sure Naggy gets close to what GCC does. If you see that it doesn't, post about it here, or file an issue at https://github.com/saaadhu/naggy and I'll see what I can do.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Senthil,

Silly question but is there any way just to temporarily turn Naggy off.

Without restarting Atmel Studio, unfortunately no. Otherwise, you can do Tools -> Extension Manager -> Installed Extensions, scroll to Naggy and click Disable.

I'll add a menu option to disable/enable it on the go in the next update (https://github.com/saaadhu/naggy...)

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I'll add a menu option to disable/enable it on the go in the next update

Cool :-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

saaadhu wrote:

I'll add a menu option to disable/enable it on the go in the next update (https://github.com/saaadhu/naggy...)

:wink: anything new?

Regards
Gerardo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gerardo64 wrote:
saaadhu wrote:

I'll add a menu option to disable/enable it on the go in the next update (https://github.com/saaadhu/naggy...)

:wink: anything new?

Regards
Gerardo

Closed out that issue today. I've also turned off diagnostics for header files. I still have to build LLVM/Clang and check if the /** comment issue is fixed, so a couple of more days atleast before I push out 0.3.3.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Great! :D
Can you please post the availability of the new release, so we all become automatically a message?
Thanks, Gerardo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just uploaded a new release (0.3.3) to the atmel gallery. It should up in the Extension Manager in a couple of days.

Important note: If you've customized the blacklisted diagnostics file, please it back up before you upgrade, and restore it after you're done.(%localappdata%/Atmel\AtmelStudio\6.\Extensions\Senthil Kumar Selvaraj\Naggy\0.3./BlacklistedDiagnostics.txt). The VSIX upgrade process deletes the folder containing the old version, taking that file along with it :( I'll move the file to a more permanent location for the next release.

Changes
Diagnostics parsing is disabled for header files.
A new menu option (Tools -> Disable Naggy) can be used to turn Naggy on/off with immediate effect.
Upgraded LLVM/Clang version used to 3.3

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I recently installed Naggy and find that it doesn't understand my c++.

Is this something I need to configure or is the scope C only.

If the latter can someone explain how I uninstall Naggy. I tried what I thought were the obvious ways in extension manager and add-ons and windows control panel....... but to no success.

regards
Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I figured out an answer to the uninstall question....

remove the folder in ...\Atmel\AtmelStudio\6.1\Extensions\

I am still interested in whether Naggy should support c++

regards
Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Tools -> Extension Manager -> Naggy -> Uninstall doesn't work?

Oh and yes, C++ support will likely be in the next release.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The reason I asked for an on/off switch above was for the very reason that if I switch from editing C to C++ then pretty much everything turns to red squiggles and it's very difficult to follow.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cliff, there's a wee bit of work involved in extracting the C++ toolchain settings from Atmel Studio, and that's what's holding me back. The underlying LLVM/Clang libraries are perfectly capable of emitting diagnostics for C++ code.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Version 0.3.3 still not showing up in my Atmel Studio 6.1.2562... is that normal?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nope, it's still not "approved". My guess - whoever is responsible for approving new releases of extensions is on vacation :)

Will ping a couple of guys next week to see if there is some other problem.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, thanks - waiting with abated breath :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Any news on Naggy? I still appear to have 0.3.2 with no sign of an update being available.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

...and still waiting...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yup sadly I uninstalled it as it makes editing C++ code almost impossible as virtually everything is underlined.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can probably fix that if Senthil doesn't mind - I'll clone it and see what's what.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That would be great. I would like to use Naggy for c++

regards
Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well I tried to build the code as-is last night and ran into problems - I guess there are some dependencies that aren't listed in the code. I'll contact Senthil and see how to build it.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry about the long delay and the no show. Not easy finding free time with an 8 months old kid to take care of :)

I did upload a 0.3.3 release, but it never made it to your machines because I did not confirm the release in the Atmel gallery after it was approved. Doh!

Anyway, found some spare time yesterday to work on this, and I have working code that does lowlighting and squiggling for C++ projects as well. Will make 0.3.4 release sometime next week.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Pushed the confirm button on the Atmel gallery today for a new release with C++ diagnostics support :) Please do give it a shot and let me know how it works.

Here's the changelog.

0.3.4

Add C++ and C++11 diagnostics support for C++ projects in Atmel Studio.
Fix broken support for ARM projects (include path resolution and symbol definition).

0.3.3

Diagnostics parsing is disabled for header files.
A new menu option (Tools -> Disable Naggy) can be used to turn Naggy on/off with immediate effect.
Upgraded LLVM/Clang version used to 3.3

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And oh, if someone wants to build the code fromh ttps://github.com/saaadhu/naggy (I know Dean tried to), switch to Release mode first. The Debug mode settings cause linking against debug mode built libraries of clang, which happen to be bigger than what github allows in a repo :(

Regards

Senthil

 

blog | website

Pages