Error trying to read map from file

[benharsh]

Summary of Problem

I was updating the reading and writing implementation of various things, and observed this error while trying to confirm something unrelated. In the sample test below we print a map to a file and try to read it back in, but encounter a formatting error involving the ending curly-brace.

Steps to Reproduce

Source Code:

use IO;
use Map;

proc main() {
  var f = openmem();

  var m = new map(int, real);
  for i in 1..10 do m[i] = (i**2):real;

  var w = f.writer();
  w.write(m);

  {
    var r = f.reader();
    var contents : string;
    r.readstring(contents);
    writeln("Wrote:");
    writeln("==========");
    writeln(contents);
    writeln("==========");
  }

  var r = f.reader();
  var x : map(int,real);
  try {
    r.read(x);
    writeln(x);
  } catch (e : Error) {
    writeln("Error reading map:");
    writeln(e.message());
  }

}

This program fails with the following message when attempting to read the map back in:

bad format: missing expected literal (while reading ioLiteral "}" with path "unknown" offset 1)

Associated Future Test(s):
test/library/standard/Map/testMapIO.chpl #19983

[bradcray]

I hate to be a pessimist, but I feel as though I would not be surprised if read() on most of the collection types in the standard library had similar issues (?).

[benharsh]

I think there's a good chance of that. In going through some of the recent IO work I noticed a number of expressions like "<~> '['", where were implementing a 'readWriteThis'. Such expressions will fail to compile (passing const to ref), and so I suspect we were never resolving a path where the type was read.

I've added some compiler warnings to the cases I noticed over in #19983

[bradcray]

Yeah, I definitely believe we've been very optimistic sometimes about thinking "I'll use <~> and things will just magically work" without actually checking ourselves, and only leaning on write(). And I think I've definitely been guilty of this at times, personally.

[benharsh]

Checking back in on this, it appears that the core issue is that Map's readThis invokes a helper method that also implements writeThis, with a bit of param-checking to call either read or write in the right cases. The problem with this approach is that it results in the readThis case only trying to read as many key-value pairs as there are in the map, which in the example program above is zero. Therefore, the program attempts to read none of the key-value pairs in the channel and instead tries to read the closing curly brace, which of course is further down the line.

The new serialization effort handles this by clearing the map at the beginning of a read, and using the new API to add as many key-value pairs as there are in the fileReader's stream. Once serializers are enabled, I will be able to close this issue.

[benharsh]

This is resolved by #23207, which enabled serializers by default.