View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000882 | LDMud 3.6 | LPC Compiler/Preprocessor | public | 2020-08-07 09:36 | 2022-01-09 20:29 |
| Reporter | zesstra | Assigned To | Gnomi | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Platform | x86_64 | OS | GNU/Linux | OS Version | 0 |
| Product Version | 3.6.2 | ||||
| Fixed in Version | 3.6.5 | ||||
| Summary | 0000882: Warning about applied lfuns being implemented with incompatible signature | ||||
| Description | In 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). | ||||
| Tags | No tags attached. | ||||
|
|
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. |
|
|
I think, that would be acceptable. But we need a suitable pragma for it, I guess. |
|
|
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?) |
|
|
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. |
|
|
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. ;-) |
|
|
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. |
| 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 |
