[Octave-bug-tracker] [bug #36743] Octave:language-extension warning warns about Octave's own files

[Lachlan Andrew]

Follow-up Comment #13, bug #36743 (project octave):

Following up from jwe's comment #9, I'm not sure if the PKG_ADD file should
specify run-time warnings.  That would mean it would need to be 'stat'ed every
time a function file is to make sure that it didn't change.  Would that
overhead be excessive?

It also involves much more bookkeeping than simply changing parse-time
settings.  The attached patch allows parse-time pragmas per file.  (This is
just a minimally tested proof-of-concept -- please do NOT commit it.)


I've been thinking of a big overhaul of the warning system to make warnings
more flexible and, perhaps, faster.

The flexibility would come from having a hierarchy of "scopes" of warnings:
  local_only  (current stack frame)
  file        (from pragma in current file)
  directory   (from pragma in PKG_ADD)
  local       (current stack frame and all descendants)
  global

At each scope, a warning's state can either be specified explicitly, or fall
through to the next lower scope.

Each warning has an 8-bit state, consisting of four 2-bit fields.

1. Action: fallback, off, on, error
2. verbosity: fallback,
              quiet (set lastwarn only),
              verbose (print ID, to allow it to be turned off),
              normal
3. backtrace: fallback,
              off,
              on,
              unused
4. debugging: fallback,
              off,
              on,
              unused   (perhaps "on and beep")

Fallback first falls back to the status of "all" in the current scope, and if
that is also fallback, it falls back to the next lower scope.

If the state is "off", the remaining fields are ignored. (This isn't quite
what Matlab does; it treats "off" as "action=on, verbosity=quiet".)

Instead of using an octave_map, the octave: namespace would use a look-up
table, autogenerated from warning_ids.m.  From C++ code, it could be accessed
through a enumeration.  From .m code, it would be accessed by a binary search
or hash table.

This also allows throwing errors when the state of a non-existent warning is
set -- useful for example when a warning is re-named, or merged with another
(like octave:automatic-broadcast was).

Having lookup more efficient would mean that we could have finer-grained IDs
to give more flexibility about what is to be turned on/off.

The code to set initial states and define the enum of states could be
generated from warning_ids.m, to keep them in sync.  That way, when
introducing a new ID or the default of an existing one, it is only necessary
to change one file.

A similar framework could apply to debug_on_...

To keep the overhead of creating a stack frame low, a stack frame would start
with a NULL pointer to a warning_options object, and only create the object if
a "local_only" is called.

One gotcha will be ensuring that "warning on ID" updates the global scope, and
also ensures that the new state isn't overridden by one of the higher scopes
-- unless we want it to be.  The purpose of the directory and file scopes is
to override everything, so we would probably just want to make sure that local
and local_only are set to fallback.

My planned work order would be
1. Replace the current warning_options (an octave_map) by a dedicated
err_warn_debug object, keeping it as the same octave_map internally.

2. Implement per-directory parse-time pragmas.  (That is enough for this
bug.)

3. Implement "Action = fallback".

4. Replace octave_map by look-up table (for "Octave:" namespace) + STL map
(for everything else).

5. Implement remaining state fields

6. Re-implement "local" warnings.  (This may need to be done in conjunction
with 4.)

7. Implement "file" and "local_only" scopes.

What do people think?

(file #36991)
    _______________________________________________________

Additional Item Attachment:

File name: pragma_warning                 Size:4 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?36743>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/