Unit tests fail when compiled with GFortran about json-fortran

[zbeekman]

It seems like I may have been wrong about my speculation in #18 that this was due to a * edit descriptor. The error being produced is the following:

Error in json_get_something: Unable to resolve path: some.path

When the JSON structure being read is printed to stdout, the structure name/key/string is missing for each component, and only ”” is printed. I dug around a bit, but have yet to localize the issue.

It’s possible that this is a GFortran bug, but it would be nice to find a work around if one exists. Deferred length character components are an “experimental" feature in 4.9, so maybe there is no hope for getting this to work right now.

My gut feeling is that object name/key/string does not get correctly allocated when reading the JSON object from a file. Right now I suspect an issue with json_module/parse_string and/or json_module/parse_value. My hunch is that GFortran can’t handle line 3637: string = string//c or 3130: call parse_string(unit, value%data%str_value) correctly, but I have yet to find hard evidence of this.

[zbeekman]

I've isolated the 3 sources of this problem and a pull request should be in later tonight with a work around.

Basically, sourced allocation works to manipulate deferred length character components, but move_alloc() reallocation on assignment and dummy arguments with intent out seem to have issues.

[zbeekman]

Two sources that cause the test to fail are when parse_string is called. These are easily fixed. The tests “pass” now, but only because they aren’t checking the complete output. The remaining issue is much more challenging to find work around for, and has to do with the optional argument str to json_value_print and is taking longer to resolve than I anticipated… Hopefully I’ll find more time this weekend to poke at this.

[jacobwilliams]

Based on your findings, I went ahead and started looking at it. I just pushed what I believe to be a workaround. It's not too bad. (I haven't tested it with ifort though, I hope that's not broken now).

[zbeekman]

Thanks, you beat me to it! I didn’t go over the diff/patch in too much detail, but I did:

1. Run all the tests with the Intel compiler and the GFortran compiler, all of which passed
2. Compare the output of the Intel build unit tests with the previous output to check for regressions—none were found
3. Check that the output of the GFortran unit test now matches the output of the Intel built tests, which it does

From the sections of 612322b that I did look at, it seems like this issue should be mostly fixed.

✨ 👍 ✨

It’s possible that other issues stemming from GFortrans trouble using deferred length character scalars and deferred length character components together exist, but if they do, hopefully we can expose them with more testing down the road.

I think 612322b is sufficient to close this issue. Feel free to reopen if you disagree.