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. 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). m code, it would be accessed by a binary search or hash table. From C++ code, it could be accessed through a enumeration. Instead of using an octave_map, the octave: namespace would use a look-up table, autogenerated from warning_ids.m. (This isn't quite what Matlab does it treats "off" as "action=on, verbosity=quiet".) If the state is "off", the remaining fields are ignored. Verbose (print ID, to allow it to be turned off),įallback 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. Local (current stack frame and all descendants)Īt each scope, a warning's state can either be specified explicitly, or fall through to the next lower scope.Įach warning has an 8-bit state, consisting of four 2-bit fields. The flexibility would come from having a hierarchy of "scopes" of warnings: I've been thinking of a big overhaul of the warning system to make warnings more flexible and, perhaps, faster. (This is just a minimally tested proof-of-concept - please do NOT commit it.)
#FREEMAT UNABLE TO RESOLVE GLOBAL TO A FUNCTION CALL PATCH#
The attached patch allows parse-time pragmas per file. It also involves much more bookkeeping than simply changing parse-time settings. That would mean it would need to be 'stat'ed every time a function file is to make sure that it didn't change.
Following up from jwe's comment #9, I'm not sure if the PKG_ADD file should specify run-time warnings.
0 kommentar(er)
