[Bug]: fileWriter argument checks false against stdout, when it should be true

[nldias]

Summary of Problem

Description:

when passing stdout to a fileWriter argument, inside the procedure it checks false against itself.

Is this issue currently blocking your progress?

It renders my code less elegant. Instead of checking against stdout, I need to check
the path against "/dev/pts/0"

Steps to Reproduce

Source Code:

use IO;
var f = stdout;
f.writeln("hello");
again(f);
proc again(
   const in g: fileWriter(true)
   ) {
   if g == stdout {
      g.writeln("hello again");
   }
}

Compile command:

just save the file and compile with chpl foo.chpl

Execution command:

Just run the file ./foo

Associated Future Test(s):

Are there any tests in Chapel's test system that demonstrate this issue?

Not that I am aware of

Configuration Information

• Output of chpl --version:
  chpl version 2.6.0
  built with LLVM version 18.1.3
  available LLVM targets: xtensa, m68k, xcore, x86-64, x86, wasm64, wasm32, ve, systemz, sparcel, sparcv9, sparc, riscv64, riscv32, ppc64le, ppc64, ppc32le, ppc32, nvptx64, nvptx, msp430, mips64el, mips64, mipsel, mips, loongarch64, loongarch32, lanai, hexagon, bpfeb, bpfel, bpf, avr, thumbeb, thumb, armeb, arm, amdgcn, r600, aarch64_32, aarch64_be, aarch64, arm64_32, arm64
  Copyright 2020-2025 Hewlett Packard Enterprise Development LP
  Copyright 2004-2019 Cray Inc.
  (See LICENSE file for more details)

• Output of $CHPL_HOME/util/printchplenv --anonymize:
  CHPL_TARGET_PLATFORM: linux64
  CHPL_TARGET_COMPILER: llvm
  CHPL_TARGET_ARCH: x86_64
  CHPL_TARGET_CPU: native
  CHPL_LOCALE_MODEL: flat
  CHPL_COMM: none
  CHPL_TASKS: qthreads
  CHPL_LAUNCHER: none
  CHPL_TIMERS: generic
  CHPL_UNWIND: none
  CHPL_TARGET_MEM: jemalloc
  CHPL_ATOMICS: cstdlib
  CHPL_GMP: bundled
  CHPL_HWLOC: bundled
  CHPL_RE2: bundled
  CHPL_LLVM: system *
  CHPL_AUX_FILESYS: none

• Back-end compiler and version, e.g. gcc --version or clang --version: clang

• (For Cray systems only) Output of module list:

[bradcray]

Thanks for taking the time to file this, @nldias! We'll hope to get this ironed out in the new year.

[bradcray]

Just noting for developers that, putting the following writeln()s into the code, it looks to me like the serializers are not being considered ==, though I didn't get far enough to determine the reason why.

   writeln((g.locking, stdout.locking));
   writeln(g.locking == stdout.locking);
   writeln((g.serializerType:string, stdout.serializerType:string));
   writeln(g._serializer.type:string ==stdout._serializer.type:string);
   writeln(g._serializer == stdout._serializer);
   writeln((g._home.id, stdout._home.id));
   writeln(g._home == stdout._home);
   writeln((g._channel_internal, stdout._channel_internal));
   writeln(g._channel_internal == stdout._channel_internal);
   writeln((g._readWriteThisFromLocale, stdout._readWriteThisFromLocale));
   writeln(g._readWriteThisFromLocale == stdout._readWriteThisFromLocale);

[bradcray]

@nldias : This seems to be a fairly easy fix—sorry that I didn't have quite enough time to get to it before the holidays. Hope to have it up soon.

[bradcray]

My branch is going well, but in a discussion about how copies of a fileReader/Writer should respond to == and != today, there was hesitation expressed about the notion that they should work with ==/!= which I've opened #28268 to capture.

Personally, I don't think that issue should hold up this "bug fix" because I think the fix is consistent with how things are implemented today (and how I believe they were designed to work); but we also shouldn't rush the fix in until a bit more discussion's been held there.

[mppf]

It renders my code less elegant. Instead of checking against stdout, I need to check
the path against "/dev/pts/0"

You don't necessarily need to include "/dev/pts/0" in your code. You can compare files:

use IO;
var f = stdout;
f.writeln("hello");
again(f);
proc again(
   const in g: fileWriter(true)
   ) {
   if g.getFile() == stdout.getFile() {
      g.writeln("hello again");
   }
}

Or compare the paths of the files:

use IO;
var f = stdout;
f.writeln("hello");
again(f);
proc again(
   const in g: fileWriter(true)
   ) {
   if g.getFile().path == stdout.getFile().path {
      g.writeln("hello again");
   }
}

(Note that both of these use getFile() which is currently unstable; I suspect it is unstable because it would ideally have a nicer name, but calling it .file will probably lead to name conflict issues with the type).

It's not immediately obvious to me if == on these fileWriters should return true (for example, if they actually have different serializer state, perhaps it should return false? Most I/O state is in the qio_channel_ptr, but not all of it is, so in practice today I think we have a mix of copying by reference and by value). Of course, it would be nice for == to work as it was expected to in this case, if it does not cause other problems.