I looked through the code.  This is explicitly handled, and ignored, with a commit message by Roland from 1995 saying only:

commit 636435e5c25d39fc5d52edf936e8e7a410b31b1a
Author: Roland McGrath <roland@redhat.com>
Date:   1995-03-07 22:31:01 +0000

    (decode_switches): If non-option arg is "-", ignore it.

So, I'm not sure why this was done or what the right thing to do is going forward.  Maybe we should be printing a warning.  I wonder if it's there because some makefiles contain recipes like this:

  submake:
          $(MAKE) -$(MAKEFLAGS)

where, if MAKEFLAGS is empty you get make -.

I will think about it.

Yes it is a valid filename but the problem, as pointed out in the original description, is that make doesn't treat it that way.  At least not all the time.  It appears that the code wants to treat it as if you'd used "-f-" but it doesn't appear to work correctly.  I do agree that this behavior is duplicative and unpleasant.

For example:

$ make x
make: *** No rule to make target 'x'.  Stop.

but:

$ make -
make: *** No targets specified and no makefile found.  Stop.

The behavior of "make --" is as expected because according to the POSIX standard, the argument -- specifies that no files after it are to be considered options even if they begin with "-".

So for example if you wanted to make a target named -f you can't use make -f because "-f" is a valid option name.  You'd have to use make -- -f.

However, I do agree that make - (one dash) should be considered an error.  Many programs use a single dash to mean "read from stdin" but make doesn't do this.