RFC on not documenting -fpreprocessed, -fmodule-private options.

[Brooks Moses]

So, I've worked my way through half of PR 28122 ("Undocumented gfortran 
options") without writing any documentation, assuming that my "remove 
-fno-backend" patch is approved.  That leaves -fpreprocessed and 
-fmodule-private as the remaining undocumented options.  I propose not 
to write any documentation for these either, based on the following 
reasoning; I'd appreciate comments.


On -fpreprocessed: This is used for communication between the gfortran 
and f951 executables, to indicate that f951 is being passed a 
preprocessed version of the file and should look in the file to find the 
original filename to use for include-path and error-message purposes.

I don't see any way that this would be very useful for an end user.  One 
can't pipe the output of a preprocessor into gfortran, and if one 
manually runs a file through a preprocessor and then compiles the 
resulting output file, it almost certainly makes more sense to treat 
this resulting output file as the source file.  (Besides which, I don't 
think there's any guarantee that the output file would have the 
"original source file" information in it in the way gfortran expects.)

Thus, my suggestion would be to leave -fpreprocessed undocumented, and 
set it as Undocumented in lang.opt.  Thoughts?


On -fmodule-private: I have found no references to this in the 
changelog, nor in the mailing list archives, nor in the testsuite, nor 
even in Google.  Personally, I don't think it's a good option -- at 
best, it might be useful for checking a programming style that requires 
everything public to be explicitly declared such, but using it for 
anything other than checking purposes is merely enabling sloppy 
nonstandard coding.  Moreover, using it for checking also is poor, since 
it doesn't check for default-public module entities that aren't used 
outside the module.

Thus, I propose that -fmodule-private should be removed.  If there's any 
call for such a thing for checking purposes, it IMO would be better 
served by a warning option like -Wmodule-default-public which would warn 
about code that violates the desired coding style, rather than changing 
the semantics.  Again, thoughts?

- Brooks