View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0000843LDMudLPC Compiler/Preprocessorpublic2015-09-01 20:332019-08-29 21:39
Reporter_xtian_ Assigned ToGnomi  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Summary0000843: struct runtime lookup regression
DescriptionWhen upgrading to a september 2015 version of 3.5 (from early 2014 version), I found a regression in the struct runtime lookup code.

the following used to compile (note the use of polymorphism for the struct argument):

---

struct a_t {
  mapping m; // compiles without this line
};

struct b_t (a_t) {
  int i;
};

void fun(struct a_t a, string s)
{
  a->(s)= 42;
}

void create()
{
  struct b_t b = (<b_t>);

  fun(b, "i");

  printf("%O\n", b);
}
TagsNo tags attached.
External Data (URL)

Relationships

related to 0000049 closedGnomi LDMud 3.3 Computed struct name lookup should be smarter 

Activities

Gnomi

2015-09-01 20:55

manager   ~0002263

Oh, this is soo mean. I was so glad to have finally solved Lars' test case t-040413:

struct Door
{
    string flags;
};

struct Exit
{
    string flags;
};

struct Exits
{
    struct Exit up;
    struct Exit down;
};

struct Room
{
    struct Exits exit;
};

void main()
{
    struct Room room;
    string dir;

    // The in the following line the driver should be able to determine
    // that only a struct Exit could be the result of the computed lookup.

    room->exit->(dir)->flags;
}

But given the example in the bug report that test scenario is not true, because room->exit could be some derived struct containing other entries that are not a struct Exit.

So, the solution would be to just undo f69c91bb464077b3465d8ae5793dd041591b6a95 and remove that test scenario.

_xtian_

2015-09-06 03:44

reporter   ~0002264

Concerning Lars' test case:

- If find it is ambig, because structs do implement polymorphism. It is a bad test case.
- with the usage of ->(dir) the programmer explicitly states that he wants runtime lookup, anyway, doesn't he? In that case compile-time lookup seems unexpected.

I would compare the case to C++ dynamic_cast. You wouldn't want the compiler to start guessing types based on some arbitrary scope.

Issue History

Date Modified Username Field Change
2015-09-01 20:33 _xtian_ New Issue
2015-09-01 20:55 Gnomi Note Added: 0002263
2015-09-01 20:56 Gnomi Assigned To => Gnomi
2015-09-01 20:56 Gnomi Status new => assigned
2015-09-06 03:44 _xtian_ Note Added: 0002264
2015-09-07 17:31 Source_changeset_attached => ldmud.git master 595561dd
2015-09-07 17:32 Gnomi Status assigned => resolved
2015-09-07 17:32 Gnomi Resolution open => fixed
2018-01-29 18:59 Gnomi Source_changeset_attached => ldmud.git master 595561dd
2018-01-29 21:57 Gnomi Source_changeset_attached => ldmud.git master 595561dd
2018-01-30 03:59 Gnomi Source_changeset_attached => ldmud.git master 595561dd
2019-08-29 21:39 Gnomi Relationship added related to 0000049