yes it can.
the error in OP is because there's an existing directory with a conflicting name. if you give it a file name without conflicts, it will happily generate a file without .exe suffix.
that's a windows thing, not a compiler thing.
granted, the msvc compiler frontend uses a special option /Fefilename, which translates to the linker option /out:filename.exe, but this is a microsoft special behavior, it's not the usual behavior of most cross-platform non-microsoft tools, unless the tool is claiming to be compatible with msvc compiler command line, such as clang-cl.
for example, gcc will not append the .exe suffix if you give it an explicit -o option, neither will clang (not clang-cl). and rustc isn't claiming to to compatible with msvc either.
even the microsoft linker will happily generate an output without .exe if you give it an /out:filename option.
you can play with these commands to see how msvc handles different output file names:
> rem compile only, no linking, /Fo is respected, /Fe is ignored
> cl /c /Fofoo /Febar test.c
> rem compile and link, /Fe is translated to /out: when invoking the linker
> cl /Fofoo /Febar test.c
> rem compile and link, but manual linker option /out: will override /Fe, no .exe appended
> cl /Fofoo /Febar test.c /link /out:baz
that's not a "bug". that's the behavior you have to take into account when you manually invoke the compiler.
for example, if I write my own build commands, I have to do something like this if I want the makefile to be portable:
ifeq ($(OS),Windows_NT)
EXE_EXT = .exe
else
EXE_EXT =
endif
TARGET = myprogram$(EXE_EXT)
alternatively, I can use cmake, which handles the platform specific suffix automatically:
add_executable(myprogram myprogram.c)
it's the similar case for rustc and cargo, if you invoke rustc in makefile or scripts, you should handle the platform specific behavior yourself. if you want a tool handle that for you, there's cargo.