Recommendation to Downgrade Errors to Warnings for COMPILER OPTIONS - Forum - OpenEdge Development - Progress Community

Recommendation to Downgrade Errors to Warnings for COMPILER OPTIONS

 Forum

Recommendation to Downgrade Errors to Warnings for COMPILER OPTIONS

This question is answered

A new feature was introduced with 11.7.0 called COMPILER OPTIONS. This feature allows a developer to set rules for the compiler to enforce stricter compilations. The feature is documented under the COMPILE statement [ OPTIONS | OPTIONS-FILE ] phrases : documentation .

This new feature grew out of an outreach program with the Progress Communities : Strict mode for the ABL Compiler - Community input is requested

There has been continued discussions under Communities through the ESAPs leading up to the release. One particular point discussed was how the compiler reacts when the enabled rules for COMPILER OPTIONS are broken within the compiled source. The initial implementation was to generate an error at the first failure and stop the compilation. This was deemed too difficult to manage by the developer. So, we updated the implementation to generate error messages with each instance of failure but continued the compilation to the end, but do not generate r-code. This is currently how it is implemented in the 11.7.0 FCS.

However, there was continued discussion between the final ESAP and the release that not generating r-code makes the feature unusable in certain cases. That brings us to this posting.

We are now considering a change for an 11.7 service pack and 12.0 to the feature. We would change the errors generated when the rules for the OPTIONS are broken to warnings and if the only issues seen during the compilation were from the options then we would generate r-code. That is, failing to meet the standards of the COMPILER OPTIONS would result in only warning messages that would not cause the compilation to fail.

Again, we would like to hear what the community thinks of this.

Verified Answer
  • Okay, so the discussion has simmered.

    The real answer is that Community wants both. Or, more to the point, control over it.

    Instead of rushing a change into an early 11.7 service pack I am going to take a look at implementing something along the lines of the sub-option described here in 12.0. We will leave 11.7 alone for now and see what we can put together for 12.0. Then we can consider porting something to 11.7 in a service pack. I am making no promises here! We may leave 11.7 alone, we may downgrade to warnings, or we my port the 12.0 changes (if they happen).

    I will try and get a pseudo-specification for 12.0 posted here this weekend.

All Replies
  • I'd prefer if the behavior was controlled by a :ERROR or :WARNING switch on the option the same way debugging levels are set in the various LOG-MANAGER settings.

    That way the developer can control the feature's behavior to match their current requirements and there's no second-guessing required.

  • No options no nothing. It should be treated as an error, period. If you ever abbreviated database fields and keywords, you should get slapped in the face. Also period. And yes, I will actually slap every idiot that ever abbreviated database field and/or a keyword, accidentally or intentionally, I don't care. Just deal with it. + ABL should be case sensitive. Period. This is a very long overdue option. Thank you for that.

  • I do love the passion and verve shown by tpavlovic... (yep poorly written code has kept many of us awake at night).

    Having said that... the answer lays in being flexible. We are talking about developers being the end-users in this case. The more flexible the solution can be, the better it can be utilised for your particular need. All the way from warnings being given at compile and producing r-code to... strict errors and no r-code.

    The more flexible the better, but that's also up to the Progress developers to see what issues it causes in their code....

    We all want to promote good coding practices... so the defaults can always be setup to promote this.

  • I've already expressed my opinion during the ESAP, an error-only mode is not possible when working with  legacy code (so basically anything written before the strict mode compiler).

    From a developer perspective, having to fix all abbreviated keywords or table names before being able to do anything on the code is a blocker problem.

    From a continuous integration perspective, I've solved nicely the problem with Ant / PCT and SonarQube to track all those strict mode errors.

  • Whilst I agree that in theory nobody should have ever abbreviated anything, the fact is, they have. For whatever reason. Whilst I want to encourage developers to fix the code, I don't want to build a situation where I can't compile code to ship to a customer. Therefore having the option to produce rcode if the only errors are strict compile errors would be a big benefit.

    Yes you could probably work around the issue with different compile operations depending on requirements, but why should I have to?

  • I'll echo the opinion that it's the developers that should get the option to control if breaking a strict rule is a warning or an error condition, for reasons that others already mentioned above.

    Further, you may want to enforce some options more strictly than others, so being able to set this per option would be nice.

    Something like "require-full-names:E , require-field-qualifiers:W require-full-keywords:E" -> E = error, W = warning, similar to how log entry types allow overriding logging level for that specific type.

  • In my opinion this should be configurable.

  • Although the ideas being put forward for extending the feature to allow sub-options that allow either errors and warnings are good, the discussion here is how we handle this in the immediate future.

    The 11.7 release will be the long term support for OE 11. We are now getting started on 12.0. Since there will be no more major changes for 11.7 in the service packs, we do not have the option of making a major feature upgrade there. Thus, this question is how to address this most simply as possible. For OE 12 we will be focusing on getting new options suggested by Community implemented and may not consider the sub-option concept for quite some time.

    So, excluding additional changes, what do you see as the preferred way that we handle it. Shall we default to errors and no r-code as it is now, or would you prefer that we generate only warning and produce r-code.

    Some of the earlier discussions are on the ESAP Community. I don’t know if the ESAP posting are open to the public at large, so those not on the ESAP Community may not have access to them. So go ahead and repeat earlier arguments if you feel strongly enough about them.

    New compiler options

    REQUIRE-* messages as warnings instead of errors

  • The ESAP postings are only open to the folks in the ESAP group, so not public.

    To answer your question, Alex, in my opinion it is imperative to be able to produce rcode if the only errors are strict compiler ones, so downgrade to warnings please.

  • Alex, if the compiler can ‘digest’ the s**t there is no reason not to generate r-code - I don’t think there is anyone out there that would like to be either forced to fix all warnings or simply shift them all together, time constraints will make the second option be the only valid choice anyway :(


    Marian Edu

    Acorn IT 
    +40 740 036 212

  • Alex Herbstritt

    Although the ideas being put forward for extending the feature to allow sub-options that allow either errors and warnings are good, the discussion here is how we handle this in the immediate future.

    The 11.7 release will be the long term support for OE 11. We are now getting started on 12.0. Since there will be no more major changes for 11.7 in the service packs, we do not have the option of making a major feature upgrade there. Thus, this question is how to address this most simply as possible. For OE 12 we will be focusing on getting new options suggested by Community implemented and may not consider the sub-option concept for quite some time.

    Alex - this kind of bureaucratic language has no place in Progress's operation. We are not talking about a "major change" here, we're talking about adding a check on an element of a CSV string for :ERROR or :WARNING, setting a flag, setting the flag to a default value if the :ERROR / :WARNING is not present, passing that flag to the compiler, and have that control the compiler's behavior.

    You guys messed up my mandating a 'one-size-fits-all' instead of implementing a configuration setting, and rather than fixing the mistake correctly you're asking if we want to make a different mistake by imposing a different one-size-fits-all that will eliminate the possibility of mandating that strict compiles are an absolute requirement in the future. 

    One-size-fits-all was the wrong decision before FCS, it's the wrong decision now, and you need to fix it instead of mandating a different bad decision. 

    The correct decision is to give the developers control of the behavior whether it's via an ERROR and :WARNING flag or some other mechanism. 

  • I agree with Tim that it *should* be up to the user.

    But if I must choose one or the other in the short term then I would go with "warnings".  My thinking is that early adoption would be more likely that way.

    --
    Tom Bascom
    tom@wss.com

  • This is a little harsh – it certainly doesn’t warrant a “you guys  screwed up” comment IMO.  The fact that there are (and were, in the ESAP too) opposing views on what the behavior should be seems to indicate that there’s no Absolutely Right solution. The dev team talked about this in the ESAP and continue to do so here, even though historically once shipped, behavior doesn’t really change.
     
     
     
     
  • Tom - the issue is this isn't a 'short term' decision - Alex stated that whatever they do will be it for the foreseeable future past when 12.0's release. 

    If the decision is error-only, then this becomes useless for larger, long-lived code bases. Cleaning these code bases of these issues would require significant developer effort - or the use of an automated tool that doesn't exist yet (as far as I know). 

    If the decision is warning-only, then each site that wants to mandate strict compile as an absolute requirement will have to write code to catch these warnings and implement their own "error-only" behavior as opposed to simply changing a string setting. 

    An error-only decision means a good idea won't get used where it's needed the most.

    A warning-only decision means the customer base will need to collectively expend a significant amount of time in order for Progress to save a bit of time on their side. 

  • Peter - there is no appropriate "one size fits all" solution which is why mandating either one or the other is a bad decision. Furthermore, for PSC to state that it will be one size fits all past the release of 12.0 (and potentially for the foreseeable future) significantly raises the stakes on what is done now.

    I love that the feature's been added, I look forward to using it, what I need from Progress is the ability to use it as circumstances dictate w/out having to write more code to get something I should've gotten out of the box.