View Issue Details

IDProjectCategoryView StatusLast Update
0000882LDMud 3.6LPC Compiler/Preprocessorpublic2022-01-09 20:29
Reporterzesstra Assigned ToGnomi  
PrioritynormalSeverityfeatureReproducibilityN/A
Status resolvedResolutionfixed 
Platformx86_64OSGNU/LinuxOS Version0
Product Version3.6.2 
Fixed in Version3.6.5 
Summary0000882: Warning about applied lfuns being implemented with incompatible signature
DescriptionIn MG we currently have a discussion if the compiler should warn/abort when an lfun, that the driver applies (i.e. it is part of the Mudlib<->Driver-API), is defined in an incompatible way.

This would require to check for the hard-coded applies, but also the configured driver hooks (at the time of compilation).
TagsNo tags attached.

Activities

Gnomi

2020-08-07 10:37

manager   ~0002543

I think the only hardcoded applied lfuns (in non-compat mode) are in the master object. Compat mode has some hardcoded applies for normal objects, too.
All the others are configurable via driver hooks.

This is doable nevertheless, the compiler knows if it is compiling a master object and can use the current configuration for the other objects. But it would also check for functions even if they would never apply, for example H_MODIFY_COMMAND_FNAME even if the object never enables commands.

zesstra

2020-08-07 14:00

administrator   ~0002544

I think, that would be acceptable. But we need a suitable pragma for it, I guess.

Gnomi

2020-08-07 20:45

manager   ~0002545

What would be an incompatible definition? Only cases where the runtime type checks would throw errors? (Parameters of incompatible types?) Would a wrong number of parameters be criticized (currently it's not a problem)? Would another return type be a problem (for some applies the driver expects an integer, and treats all other types as the answer 'no', but doesn't raise an error)? Should visibility be a concern? (The applies can be static or protected, but not private. A private definition is just ignored, should the driver warn about that?)

zesstra

2020-08-15 21:23

administrator   ~0002547

Mhmm. I think, there two use cases:
a) prevent a definition, that causes runtime errors later.
b) warn about wrong usage (e.g. forgetting that this function will have special meaning)

I think for b) it would be good to warn about the wrong number of arguments and a wrong return type. Therefore I would also warn about private definitions.

zesstra

2020-08-15 21:25

administrator   ~0002548

Addition, why b) would be relevant: The recent crash in clean_up in MG was because the programmer forgot about the clean_up mechanism and just used a function named clean_up for something completely else. There it seems to happen. ;-)

Gnomi

2020-08-17 09:51

manager   ~0002549

Then I would think about two pragmas (warn_applied_functions, warn_applied_functions_strict?). The first one would warn about incompatible types and the second one about everything. The pedantic pragma would make them errors.

Issue History

Date Modified Username Field Change
2020-08-07 09:36 zesstra New Issue
2020-08-07 10:37 Gnomi Note Added: 0002543
2020-08-07 14:00 zesstra Note Added: 0002544
2020-08-07 20:45 Gnomi Note Added: 0002545
2020-08-15 21:23 zesstra Note Added: 0002547
2020-08-15 21:25 zesstra Note Added: 0002548
2020-08-17 09:51 Gnomi Note Added: 0002549
2021-04-16 16:51 zesstra Assigned To => zesstra
2021-04-16 16:51 zesstra Status new => confirmed
2021-04-17 08:35 zesstra Assigned To zesstra =>
2021-04-22 16:03 Gnomi Assigned To => Gnomi
2021-04-22 16:03 Gnomi Status confirmed => assigned
2022-01-09 20:29 Gnomi Status assigned => resolved
2022-01-09 20:29 Gnomi Resolution open => fixed
2022-01-09 20:29 Gnomi Fixed in Version => 3.6.5