Error when importing a class definition with use <modname> only <typename>

[ty1027]

Summary of Problem

In the following code, I am importing the definition of a class from a different file
(mydef.chpl), instantiate it in the main routine, and then write some number
to a file. This code works fine if I import the class definition as use mydef;,
but the compilation fails (with the following message) if I use use mydef only Mytype;.
In the latter case, the code works again if I comment out writeln( a ); or use
file.writeln() instead of file.writef().

$CHPL_HOME/modules/standard/IO.chpl:3188: error: unresolved call 'qio_regexp_t.writeThis(channel(true,dynamic,false))'
$CHPL_HOME/modules/internal/ChapelBase.chpl:1948: note: candidates are: chpl_ModuleDeinit.writeThis(ch)
(... long messages follow ...)

Steps to Reproduce

Source Code:

//== test.chpl ==

//use mydef;              // OK
use mydef only Mytype;    // error

proc main()
{
    var a = new borrowed Mytype();
    writeln( a );

    var file = openwriter( "test.dat" );

    file.writef( "%10.3dr\n", 1.23 );
    // file.writeln( 1.23 );
}

//== mydef.chpl ==

class Mytype
{
    var x : real;
}

Compile command:
chpl test.chpl

Execution command:
./test

Configuration Information

• chpl --version:
  chpl version 1.18.0
  Copyright (c) 2004-2018, Cray Inc. (See LICENSE file for more details)

• $CHPL_HOME/libexec/util/printchplenv --anonymize:
  CHPL_TARGET_PLATFORM: darwin
  CHPL_TARGET_COMPILER: clang
  CHPL_TARGET_ARCH: native
  CHPL_LOCALE_MODEL: flat
  CHPL_COMM: none
  CHPL_TASKS: qthreads
  CHPL_LAUNCHER: none
  CHPL_TIMERS: generic
  CHPL_UNWIND: none
  CHPL_MEM: jemalloc
  CHPL_ATOMICS: intrinsics
  CHPL_GMP: none
  CHPL_HWLOC: hwloc
  CHPL_REGEXP: none
  CHPL_AUX_FILESYS: none

• clang --version
  Apple LLVM version 8.0.0 (clang-800.0.42.1)
  Target: x86_64-apple-darwin15.6.0

[lydia-duncan]

Huh, that's super weird. writef and writeThis should be available to the main module due to its hidden use of ChapelStandard. I have a vague recollection that using other module might impact the use of ChapelStandard, but it seems wrong for it to get turned off in this case even so. I'll take a look at it.

[lydia-duncan]

Oh, wait, qio_regexp_t is an extern type so shouldn't ever have a writeThis method. We saw something similar with channel_regexp_info in #11893, I think this just means tracking down where we try to call the writeThis method on that type and make it stop.

[lydia-duncan]

I can reproduce this failure with 1.18.0 but not with current master. I'm going to submit your test file to ensure we don't regress and move on if that's okay.

[ty1027]

@lydia-duncan Thanks very much for testing with the master version. I've just downloaded the master from Github, built the compiler with Ubuntu18, and the above code works with no problems!

And a general question: Is it usually recommended also try the (near-)latest master as well as the latest released version to submit a potential bug issue? I had imagined that the master version might be less stable due to continuous development, so did not try to use the master for testing/coding. Is the master more recommended, generally speaking?

[lydia-duncan]

Releases are generally more stable than our master branch. We're pretty good about not committing horribly broken code to master, but will often have one or two little errors come and go.

I would say try to develop from the latest release as much as possible and if you encounter an error, feel free to point it out to us. If you do a search for that error mode before submitting, you may find an issue on it that got closed in the current release cycle - if updating to master shows that your version of the problem is resolved as well, all the better and likely no need to submit another issue (though if you feel your use case is sufficiently different, a comment with it on that issue would probably be useful).

If you don't find an issue similar to the one you encountered, I would say it is up to you whether to check against master before submitting. Having that information up front saves us having to discover it and may help us resolve things more quickly if the error mode has changed. That said, it isn't a burdensome step for us to do and arguably our job rather than yours. We don't get very many false positive reports and additional tests are great, so we're unlikely to be annoyed at you for not checking (and it lets us know folks are using Chapel :) )

[ty1027]

@lydia-duncan Thanks very much for explanasions, I think I understood the overall procedure (before submitting a report). Because the build process does not take much time, so I will also try a master (when possible) to get more info. Thanks much!

[bradcray]

For simplicity, I don't think users should feel the need to test against master before filing a bug report. You're welcome to of course, but it doesn't take us long to test a reported bug on master, and I think it's more exciting than frustrating to learn that the bug has already been fixed (so I never mind when it happens).