forums.silverfrost.com

mecej4 · Joined: 31 Oct 2006 Posts: 1896

In the code shown below, there is an erroneous declaration for three variables that are already in scope through USE association. The compiler flags only one of the three variables in its error message. If that variable is removed and the compiler is run again, the next re-declared variable is flagged. When such an error occurs while refactoring a large program, it would be more convenient for the compiler to flag all the re-declared variables the first time.

LitusSaxonicum · Posted: Tue Dec 27, 2022 1:36 am Post subject:

Hi Mecej4,

RHODH has NOT been declared twice! (EDIT: well it wasn't as originally posted, but Mecej4 has edited his original post in light of this response, which is cheating - a little).

I think that working on Christmas Day has caused you to suffer some Dannian Devilry!

While you are right to imply that it would be helpful if the double specification of all variables could be indicated, I suspect that the compiler stops looking after the first error is detected. Moreover, if I was looking at the code after an error had been indicated I do think that there's a fair chance I might see the double specification of DIS as well.

The declaration of RHODH in the DOUBLE PRECISION statement has no impact as far as I can see, as RHODN is in the code and in the MODULE while RHODH is not used in the demonstrator. (So the demonstrator has been edited).

Eddie

mecej4 · Joined: 31 Oct 2006 Posts: 1896

Thanks for spotting the slip, Eddie. I have corrected the reproducer above.

The issue still stands. In the actual code (not the small reproducer that I posted), the common block contains hundreds of variables, so the issue regarding (reporting one at a time versus reporting all) is quite real.

When one programmer error causes a clump of error messages to be given out, my habit of glancing at line numbers in the error messages is usually effective in detecting such clumps.

PaulLaidler · Posted: Tue Dec 27, 2022 8:25 am Post subject:

mecj4

Thank you for the feedback. This behaviour is by design but I have changed it to suit your preferences. The change may not be in time for the pending full release.

The FTN95 error handling has a flag (set by the FTN95 developer) that suppresses further errror reports for the current line. I have simply removed this flag.

Naturally the downside is that, if you have many such errors on one line then you will get a whole batch of error reports.

mecej4 · Joined: 31 Oct 2006 Posts: 1896

Thanks, Paul, perhaps a better solution would be to allow that hidden flag (now accessible only to the compiler developers) to be set by the user in FTN95.cfg or as a compiler command option. As Eddie states, many users may prefer the current behaviour. I can understand that users who develop using Plato or VS may prefer to keep the current behaviour.

LitusSaxonicum · Posted: Tue Dec 27, 2022 11:18 am Post subject:

Mecej4,

I don't think that I've ever represented 'many users' (much as I'd like to), and as you point out, just being given a tip off enables an experienced programmer to detect the other weeds in that particular clump of vegetation.

Your solution of making the behaviour configurable seems to me to be a particularly useful suggestion, and one that I commend to Paul. What about a compiler option?

Eddie

PaulLaidler · Posted: Wed Dec 28, 2022 8:32 am Post subject:

The error in question is number 655. This is one of about 200 error reports out of about 1300 that have a flag that suppresses a repeat of the given error message on the current line.

The simplest and probably best solution is that we provide a command line option that over-rides this flag for all 200 error reports of this kind. Otherwise the user will have more flexibility than is useful and also the change would become much more time consuming to implement.

The new command line option will be /ALL_ERRORS.

LitusSaxonicum · Posted: Wed Dec 28, 2022 12:25 pm Post subject:

Brilliant solution, Paul. Simple, elegant, and meets everyone's needs.

It will have to do until you implement the psychic algorithm to detect what the programmer meant, instead of what they typed!

Eddie

simon · Joined: 05 Jul 2006 Posts: 270

I second that. I will be glad to have the /ALL_ERRORS compiler option.

JohnCampbell · Joined: 16 Feb 2006 Posts: 2580 Location: Sydney

This looks to be a good approach.

I also use ftn95.cfg to include:
/SET_ERROR_LEVEL Warning 327
( I assume there can be multiple of these instructions in ftn95.cfg or multiple error numbers listed; either way is ok. )

I am hoping this will not be confused with /ALL_ERRORS

The use of C:\Program Files (x86)\Silverfrost\FTN95_8.92.37b\ftn95.cfg works effectively for me.

PaulLaidler · Posted: Thu Dec 29, 2022 9:50 am Post subject:

John

Yes. /SET_ERROR_LEVEL allows you the option to change the status of particular error messages and to upgrade or downgrade their severity.

Also /CONFIG provides a dialog that allows you to configure FTN95 in order to change the severity of particular error messages.

/ALL_ERRORS will be configurable via /CONFIG. It should have no adverse effect on the existing mechanism.

Almost all of the error messages that relate to /ALL_ERRORS are in fact "error" as opposed to "warning", "comment" or "fatal". In theory some of these may also be upgraded to "fatal" or downgraded to "warning". But downgrading is often unsafe.

PaulLaidler · Posted: Mon Jan 09, 2023 8:23 am Post subject:

/ALL_ERRORS has now been added for the next release of FTN95.