New Extension - Naggy

Go To Last Post
132 posts / 0 new

Pages

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

Hi Senthil,

I have just briefly checked the new version with my (C-only) sources. I'm under the impression that the error numbers have changed and the content in the "BlacklistedDiagnostics.txt" needs to be adjusted for the new version.

Anyways, thank you very much for this most useful tool!

Regards,
Paul

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

Thanks very much for updating the naggy tool.

I am using the latest 6.1 and get many errors with a c++ project

Error	57	1640 : invalid output constraint '=z' in asm
Error	7	1761 : cast from pointer to smaller type

The errors occur on lines containing "pgm_read_word" and "pgm_read_byte"

Is anyone else having a similar experience?

regards
Greg

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

Ah, Naggy is using a newer version of Clang under the hood, and yes, the error numbers have changed. My bad, didn't notice the change. I'll add testcases to the test suite to catch this in future versions.

This page (https://github.com/saaadhu/naggy...) has instructions on how to blacklist diagnostics. "invalid output asm constraint"'s error id is now 1640 instead of 1636. Editing the file to update the error code(s) and restarting Atmel Studio should fix the problem.

Meanwhile, I'll push an update to the Atmel gallery to fix this.

Regards

Senthil

 

blog | website

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

Thanks for the quick feedback.

I also get warning 3780/unknown attribute for progmem and 3545/cast to pointer. It seems that naggy has a view that a pointer is longer than an int.

I can clobber them by editing the blacklist but wonder if I am blacklisting comments that would otherwise be useful.

regards
Greg

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

I pushed an updated BlacklistedDiagnostics.txt file here (https://github.com/saaadhu/naggy...).

The pointer size thing is a real problem - there is port of the AVR target to Clang/LLVM in the main LLVM source base. I arbitrarily chose i386, and therefore the size of a pointer and other builtin datatypes will be incorrect for AVR (int is 4 bytes etc..). You can safely blacklist those warnings/errors, until I manage to find time to hack on a minimal implementation of the AVR target for Clang/LLVM - just whatever is necessary for the Clang frontend to know about.

Regards

Senthil

 

blog | website

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

Darn! Deleted the product instead of the release in the gallery! Now no one can download it unless it gets approved. Previous releases, comments and ratings are gone as well. Double darn :(

I uploaded the binary to github as a workaround (with updated BlacklistedDiagnostics.txt) - you can download it from https://github.com/saaadhu/naggy...

Regards

Senthil

 

blog | website

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

Thanks for the updates.

Quote:
I also get warning 3780/unknown attribute for progmem and 3545/cast to pointer. It seems that naggy has a view that a pointer is longer than an int.
Any thoughts on the attribute warning?

regards
Greg

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

Does clang/llvm recognise gcc attributes?

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

No, it doesn't. Unknown attribute warnings would have to go into the blacklist as well. Thought I already had them there - one more update then.

[EDIT] : The updated blacklist file has the correct error id for unknown attributes as well.

Regards

Senthil

 

blog | website

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

Senthil,
I am happily using naggy with c++. Thanks very much.
A bug/improvement that you might like to look at when you has a minute is that naggy seems to put the focus on the "error list" window even when there are no errors.

This means that when I build with no errors the focus is moved to the error window. when I do a find rather than seeing the find results I see that there are no errors.

thanks again for naggy and interested in your thoughts on the above.

regards
Greg

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

Well, whether there are errors or not. E.g., when using the search all functionality it lists all the found matches briefly and then switches to the errors tab again. It might be useful to only switch if there was actually a change in the sources.

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

Glad that you like Naggy.

Yup, that's super annoying. I've fixed it and pushed a new 0.3.5 release. Naggy will no longer explicitly "show" the error window itself - it will silently add diagnostics to it.

The release is available in github already (https://github.com/saaadhu/naggy...), and I've uploaded it to the Atmel gallery as well. Should be available inside Atmel Studio once it gets approved.

Regards

Senthil

 

blog | website

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

Hot diggity - the auto-switching was making using my Data Size Viewer a bit harder when navigating symbols, thanks!

Feedback from APPS TRD: "Would be nice to have a 'Naggy' prefix on the error messages, so we don't confuse them with the GCC output errors..."

- Dean :twisted:

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

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

In my case, Naggy says that the very first #included file can't be found and seemingly does nothing more.

The project builds just fine, so GCC has no problem finding the file.

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

Quote:

so GCC has no problem finding the file.


That's to be expected, Naggy has nothing to do with GCC. In fact it uses a completely different C compiler to check the syntax of the code.

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

clawson wrote:

That's to be expected,

How on Earth can a C compiler "be expected" to fail to find includes?

clawson wrote:
Naggy has nothing to do with GCC. In fact it uses a completely different C compiler to check the syntax of the code.

I know, I mentioned long ago how I had been looking for a way to use LLVM directly instead of GCC, and how I hoped Naggy would be "enough".

For that though I will need it getting includes :P. And you can see how there has been some discussion about Naggy getting the needed directories from project properties and such. Only, something seems broken, at least in my case.

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

Quote:

How on Earth can a C compiler "be expected" to fail to find includes?

That is not what I wrote. You said

so GCC has no problem finding the file. 

I was pointing out that just because Naggy (which actually uses the Clang/LLVM compiler) fails to find a .h file does not mean that GCC will have the same problem, because it is a DIFFERENT compiler. In other words just because Naggy says something is wrong doesn't mean it really is wrong (as far as GCC is concerned).

I therefore expected GCC to find the file and that's what you reported so I said "that's to be expected". I wasn't expecting that Naggy/Clang/LLVM wouldn't find it - that's just an unfortunate bug in the way it works.

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

And my point is that back in May there was already discussion on this, how it might even be a problem in Clang's parser, and I was just reasserting the bug I reported back then.

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

Here's an interestingly tortured bug.

NOTE: this problem appears with Naggy installed and enabled in the Extension Manager, but disabled from the Tools menu. If I disable Naggy in the Extension Manager, the problem doesn't appear, so this has to be caused by Naggy.

I have a .c file which calls a function-like macro in an .h file. The macro declares/inits some structure:

#define CIRCBUF_VAR_DECLARE(TYPE, TYPELABEL, QUALIF, QUALIFLABEL, NAME, BUF_NUM_ELEMS)\
	uint8_t buffer_##NAME[BUF_NUM_ELEMS];  			\
	circbuf##TYPELABEL##QUALIFLABEL NAME ={			\
		.buffer_num_elems=BUF_NUM_ELEMS, 				\
		.buffer=buffer_##NAME,                       \
	}

If the .c file is opened (so presumably parsed by the supposedly disabled Naggy) and the .h file is edited, trying to save the .h file causes a dialog box saying "The requested operation cannot be performed on a file with an user-mapped section open".

Naggy is evidently not totally disabled, because the .c file shows some #ifdef lowlighting which is another effect of Naggy. So I guess that Naggy is trying to parse the function-like macro, choking on it and dying while leaving the file kind-of-locked.

If the .h file is edited but the .c file was not opened in the editor, the problem does not appear.

Once the problem appears, closing the .h file in the editor (losing its changes!) and opening it again doesn't fix the problem; the whole Atmel Studio must be restarted to free the .h file.

Incidentally, another bug is that trying to disable Naggy from the Tools menu when no source file has been yet opened fails with a dialog saying "Object reference not set to an instance of an object".

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

hmijail wrote:
Here's an interestingly tortured bug.
If the .c file is opened (so presumably parsed by the supposedly disabled Naggy) and the .h file is edited, trying to save the .h file causes a dialog box saying "The requested operation cannot be performed on a file with an user-mapped section open".

Pretty strange. Naggy actually reads the in-memory contents of the file you're editing, but included files are read from the disk by clang. Did you disable Naggy after you started editing the file? I'll take a look at this anyway

Quote:

Incidentally, another bug is that trying to disable Naggy from the Tools menu when no source file has been yet opened fails with a dialog saying "Object reference not set to an instance of an object".

Nasty - will fix this in the next release.

Do you have a sample project that shows Naggy failing to handle the first #include?

Regards

Senthil

 

blog | website

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

abcminiuser wrote:

Feedback from APPS TRD: "Would be nice to have a 'Naggy' prefix on the error messages, so we don't confuse them with the GCC output errors..."

- Dean :twisted:

'Naggy' is probably too long, unless you're working on a high-res monitor. Maybe N::diag or something like that would work better, I guess. Will add this to the next release.

Regards

Senthil

 

blog | website

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

saaadhu wrote:
Pretty strange. Naggy actually reads the in-memory contents of the file you're editing, but included files are read from the disk by clang. Did you disable Naggy after you started editing the file? I'll take a look at this anyway

No, I disabled it before even opening the file.

saaadhu wrote:
Do you have a sample project that shows Naggy failing to handle the first #include?

The projects I was editing yesterday now seem to work OK with Naggy... or at least don't show any clear problem. Strange because pretty little has changed.
If I find another problem of that kind I'll let you know. I will try to leave Naggy enabled for now.

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

Naggy seems to have problems with function-like macros. Sometimes it emits warnings as if it thought that they are implicitly-declared functions (particularly when a function-like macro is "calling" another function-like macro passed as a parameter, as in FMACRO(FMACRO2)). But when the project is built, those errors disappear.

Also, I am getting duplicate warnings coming from "#pragma message" lines.

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

hmijail wrote:
Naggy seems to have problems with function-like macros. Sometimes it emits warnings as if it thought that they are implicitly-declared functions (particularly when a function-like macro is "calling" another function-like macro passed as a parameter, as in FMACRO(FMACRO2)). But when the project is built, those errors disappear.

Do you have an example that demonstrates the problem?

Quote:

Also, I am getting duplicate warnings coming from "#pragma message" lines.

I'm not seeing those, perhaps you're seeing both build output from the actual compiler along with Naggy's diagnostics?

Regards

Senthil

 

blog | website

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

Just released a new version of Naggy (0.3.6), with a fix for the "unable to save" bug. In case you uninstalled Naggy, do give this release a try.

Regards

Senthil

 

blog | website

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

Hi Senthil,

just installed Naggy 0.3.6 and I'm seeing many complaints regarding variable widths that were not present before, like:

Warning	12	[N] 3517 : 
implicit conversion from 'long' to 'uint32_t' (aka 'unsigned int') changes value from 268435455 to 65535

For me Naggy seems to consider 32bit wide values to be 16bit only.

Regards,
Paul

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

Is this an AVR project?

Dang, looks like I can never win :(. While I just made Naggy aware of the size of avr data types (int = 16 bits, pointers are 16 bits etc..), stdint.h defines uint32_t as

typedef unsigned int uint32_t __attribute__ ((__mode__ (__SI__)));

and Clang/Naggy doesn't (yet) understand the __mode__ attribute, so it just treats it as an int. Which, of course, is not 32 bits, and that's why you're seeing the warning.

Until this release, the size of datatypes was wrong (int was 32 bits), so that's why you weren't seeing it before.

I'll see if I can teach Clang about the __mode__ attribute.

Regards

Senthil

 

blog | website

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

Just pushed a new release (0.3.7) which should hopefully fix that problem.

Like I said, I had to hack into the LLVM code to make it map the modes to the right datatypes.

Regards

Senthil

 

blog | website

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

If you keep going like this, how long until avr-clang is done ? :P

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

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

Hi Senthil,

thank you very much for the fast update to Naggy version 0.3.7. The wrong messages are gone now.

Unfortunately I'm no longer seeing complaints like 2345 (ambiguous), 2188 (out-of-line definition) or 2431 (redefinition) as it was the case with Naggy 0.3.5. The project is AVR/Arduino with cpp-files handled via the VisualMicroExtension.

Other complaints work as expected.

Regards,
Paul

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

I've just published a new version of Naggy that works with Atmel Studio 7.0. You can download it from https://github.com/saaadhu/naggy/releases/tag/0.4.0 , until it eventually shows up in the extensions gallery.

 

I'm now piggy backing off the avr-llvm project (https://github.com/avr-llvm/llvm), rather than my own patch. In case you missed it - the guys working on that have started merging it to upstream LLVM, so there'll soon be a avr-clang out there to compete with avr-gcc :)

Regards

Senthil

 

blog | website

Pages