"Functions may not be nested" [SOLVED]

[benoitstjean]

Compiler: 5.026
Device: PIC24EP512GP806

I know what "Functions may not be nested" mean but the problem is that I have 27 files in my project and many many thousands of lines of code. Trying to find the missing '}' is like looking for a needle in a haystack.

The compiler pops me that error and points to a line... but that line is, in my case, a function at the begining of a file and that file is fine. Therefore the error is before that... but where?

This is something that has always ticked-me off with CCS - when an error occurs, it doesn't always point to the right spot... Sometimes the error is fine and points directly to it but sometimes it's not and this is the case with the missing brackets.... it's almost as if it's saying "hey, there's a bracket missing but find it yourself"...

Any tips are appreciated.

Thanks,

Ben

[temtronic]

OK, re 'where' is the problem.....
When the compiler does find an error, it can be several lines ago, and I understand that. Kinda like a car crash, you know where the car is but why did it skid off the road (follow the tracks...). Heck, IF you can improve the error checking of the compiler, please tell CCS how to 'tweak' it, everyone will be happy !

As for your code, I'd remove each of the 27 files you have one at a time or at least check each one out individually. Presumably these files are 'functions or sub functions', like LCD interface, KBD interface, etc. so should be testable by themselves ?

Jay

[Ttelmah]

I must admit in the past I used a syntax checker like lint, and created custom rules to track down this sort of problem.
However the checking in CCS has improved and in recent years this has become less common, The 'find matching brace' ability in the iDE is your friend (or if you are not using the IDE, get a copy of vi, which has the same ability).
The actual CCS syntax checker, 'ploughs on', until it can't cope, rather than realising that something is wrong much earlier. However it should be fairly easy to narrow things down by excluding files one by one.

[benoitstjean]

Alright, thanks guys.

That's what I am currently doing... one file at a time. Good thing I have a 'working' backup at the office that I will use tomorrow and compare each file.

That's what happens on a sunday morning, while having coffee... "Baaah... I'll just 'look' at my code"... next thing you know, you're typing away and adding stuff then BAM! Introduce errors....

Thanks!

Ben

[Gabriel]

The few times ive seen this, its because i added something and missed/forgot a close bracket.

G.
_________________
CCS PCM 5.078 & CCS PCH 5.093

[dyeatman]

You can use the file history to go back to a previous version that didn't have
the error to compare....if that helps. It has for me many times.
_________________
Google and Forum Search are some of your best tools!!!!

[benoitstjean]

FOUND IT.

Damn thing. Be aware "functions cannot be nested" is not caused only by a missing bracket '}' or a missing ')' but also a missing #endif to an #ifdef statement.

It just so happened that I have accidentally forgot an #endif to a previous #ifdef. That was the problem.... Everything now compiles just fine.

So rather than spewing-out an "ifdef without matching #endif" like *I believe* I have seen before, it just says that "functions cannot be nested"...

Even if the statements are before and after the code block, same error.

FIXED.

Ben

[temtronic]

NICE !!! hopefully you can take off what's left of the weekend and celebrate......

Jay

[Ttelmah]

Just as an update on this. #IFDEF will give 'Missing #ENDIF' in most cases. It appears you can only get the 'functions may not be nested' error in certain rare combinations. So far I've only been able to trigger it once, by then including a file.
So for most code, you should get the 'Missing #ENDIF' error.

[RF_Developer]

In C the compiler never sees the #endif - that's dealt with by the pre-processor in a previous pass. In most C implementations, the compiler cannot report one is missing, and so could not produce such an error. The preprocessor might, but then the preprocessor knows nothing of the syntax of C, indeed it may not be working on C code at all.

In CCS C the functions of the preprocessor and compiler appear to implemented in one pass, which presumably could detect such errors, but as #endif is almost not related to the syntax, structure and semantics in any way - in other words #ifs and #endif can come practically anywhere in C source source files - it's difficult to see how it it could do so usefully, let alone reliably. This is one of the reasons pre-processors are not used in many later members of the C family, and rarely found on other high-level languages: it has become pretty much a C quirk.

[Ttelmah]

Have to disagree.....

Normally the compiler calls the pre-processor, and the pre-processor will report it's errors back to the calling program. So the compiler calls the pre-processor, which if it then finds an imbalance in the #ifdef/#endif counts, will exit returning an error code to the compiler. The exit codes may well be simple (so will often 'share' codes for several similar errors), but just because this part of the scan is being done by a separate program, it doesn't prevent an error of this type being reported.
The pre-processor knows the syntax of what it has to parse, which is the #define's, #if expansion etc.. Not the actual C language, but the pre-expansion, which is where this error actually is.

Now separately, you can get the situation where the pre-expansion actually works OK, but only after the expansion is there an error in the C syntax (very common with #defines), which is why you can normally ask the pre-processor to output the expanded listing. This is an area where the CCS 'one pass' approach causes significant problems. It actually does have to parse the macro expansions etc., first, but never outputs this, feeding it internally directly into the C compiler. Means that you have no ability to access the expanded output, and finding such faults can be a real pain.

[PCM programmer]

Getting back to the original problem of how to find a missing brace, the
"code folding" feature of MPLAB-X seems like it might be helpful.

In MPLAB-X vs. 3.15, if you tell it to "collapse all", it will collapse
everything until it hits a section with a missing brace. In that section
it will either not collapse it, or it will collapse most of it, but show an
extra brace at the end. I haven't tested other versions.
Then I suppose you can use the "Ctrl [" keys to match the brace (or not)
to further help you.