Bug #1685

charmc Chokes on @explicit@ constructors

Added by Nils Deppe almost 2 years ago. Updated almost 2 years ago.

Target version:
Start date:
Due date:
% Done:



If I mark a constructor explicit using the explicit keyword as follows:

entry explicit Klass(int);

I get the error:

STDIN:8:error: constructors cannot return a value
  entry explicit Klass(int);

STDIN:8:error: non-void return type in a non-sync/non-local entry method
To return non-void, you need to declare the method as [sync], which means it has blocking semantics, or [local].
  entry explicit Klass(int);

Fatal Error by charmc in directory /home/nils/SpECTRE/spectre/build_clang/src/Parallel
   Command /home/nils/SpECTRE/charm/multicore-linux64-gcc/bin/charmxi -orig-file returned error code 1
charmc exiting...


#1 Updated by Phil Miller almost 2 years ago

  • Status changed from New to Feedback

I'm not sure what it would mean to mark a chare class constructor explicit at all, let alone declaring it in the .ci file. The only way a chare constructor can get called is through code that's made a CProxy_Foo::ckNew or array_proxy[k].insert call, leading the RTS code to deliver a message that calls the constructor.

Do you have functions that are taking chare types as arguments, for which you're trying to prevent accidental conversion from some other type that could be used to construct the chare?

#2 Updated by Nils Deppe almost 2 years ago

I'm trying to maintain consistency between my C++ code and the CI file, that is all. I would not expect marking the constructors explicit to cause problems (aside from parsing), and we've found that marking constructors explicit unless they should be converting constructors helps catch bugs at compilation time with zero runtime and compile time cost.

#3 Updated by Phil Miller almost 2 years ago

So, it wasn't stated earlier, but it looks like having explicit in the class declarations in the C++ code does work fine (just tested on tests/charm++/simplearrayhello), it just doesn't match what's allowed in the .ci file.

I'm inclined toward closing this. We're hoping to phase out .ci files, and hence obviate deficiencies in their parsing, rather than working more and more on the parser. Is that OK by you?

#4 Updated by Nils Deppe almost 2 years ago

Ah good. Yes, with moving away from ci files I don't think this is worth anyone's time to fix.

#5 Updated by Phil Miller almost 2 years ago

  • Assignee set to Phil Miller
  • Status changed from Feedback to Closed

Also available in: Atom PDF