// Copyright (c) 2013-2014 Sandstorm Development Group, Inc. and contributors
// Licensed under the MIT License:
//
// Permission is hereby granted, free of charge, to any person obtaining a copy
// of this software and associated documentation files (the "Software"), to deal
// in the Software without restriction, including without limitation the rights
// to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
// copies of the Software, and to permit persons to whom the Software is
// furnished to do so, subject to the following conditions:
//
// The above copyright notice and this permission notice shall be included in
// all copies or substantial portions of the Software.
//
// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
// IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
// FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
// AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
// LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
// OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
// THE SOFTWARE.

#pragma once

#include "array.h"
#include "string.h"
#include "vector.h"
#include "function.h"

KJ_BEGIN_HEADER

namespace kj {

class ProcessContext {
  // Context for command-line programs.

public:
  virtual StringPtr getProgramName() = 0;
  // Get argv[0] as passed to main().

  KJ_NORETURN(virtual void exit()) = 0;
  // Indicates program completion.  The program is considered successful unless `error()` was
  // called.  Typically this exits with _Exit(), meaning that the stack is not unwound, buffers
  // are not flushed, etc. -- it is the responsibility of the caller to flush any buffers that
  // matter.  However, an alternate context implementation e.g. for unit testing purposes could
  // choose to throw an exception instead.
  //
  // At first this approach may sound crazy.  Isn't it much better to shut down cleanly?  What if
  // you lose data?  However, it turns out that if you look at each common class of program, _Exit()
  // is almost always preferable.  Let's break it down:
  //
  // * Commands:  A typical program you might run from the command line is single-threaded and
  //   exits quickly and deterministically.  Commands often use buffered I/O and need to flush
  //   those buffers before exit.  However, most of the work performed by destructors is not
  //   flushing buffers, but rather freeing up memory, placing objects into freelists, and closing
  //   file descriptors.  All of this is irrelevant if the process is about to exit anyway, and
  //   for a command that runs quickly, time wasted freeing heap space may make a real difference
  //   in the overall runtime of a script.  Meanwhile, it is usually easy to determine exactly what
  //   resources need to be flushed before exit, and easy to tell if they are not being flushed
  //   (because the command fails to produce the expected output).  Therefore, it is reasonably
  //   easy for commands to explicitly ensure all output is flushed before exiting, and it is
  //   probably a good idea for them to do so anyway, because write failures should be detected
  //   and handled.  For commands, a good strategy is to allocate any objects that require clean
  //   destruction on the stack, and allow them to go out of scope before the command exits.
  //   Meanwhile, any resources which do not need to be cleaned up should be allocated as members
  //   of the command's main class, whose destructor normally will not be called.
  //
  // * Interactive apps:  Programs that interact with the user (whether they be graphical apps
  //   with windows or console-based apps like emacs) generally exit only when the user asks them
  //   to.  Such applications may store large data structures in memory which need to be synced
  //   to disk, such as documents or user preferences.  However, relying on stack unwind or global
  //   destructors as the mechanism for ensuring such syncing occurs is probably wrong.  First of
  //   all, it's 2013, and applications ought to be actively syncing changes to non-volatile
  //   storage the moment those changes are made.  Applications can crash at any time and a crash
  //   should never lose data that is more than half a second old.  Meanwhile, if a user actually
  //   does try to close an application while unsaved changes exist, the application UI should
  //   prompt the user to decide what to do.  Such a UI mechanism is obviously too high level to
  //   be implemented via destructors, so KJ's use of _Exit() shouldn't make a difference here.
  //
  // * Servers:  A good server is fault-tolerant, prepared for the possibility that at any time
  //   it could crash, the OS could decide to kill it off, or the machine it is running on could
  //   just die.  So, using _Exit() should be no problem.  In fact, servers generally never even
  //   call exit anyway; they are killed externally.
  //
  // * Batch jobs:  A long-running batch job is something between a command and a server.  It
  //   probably knows exactly what needs to be flushed before exiting, and it probably should be
  //   fault-tolerant.
  //
  // Meanwhile, regardless of program type, if you are adhering to KJ style, then the use of
  // _Exit() shouldn't be a problem anyway:
  //
  // * KJ style forbids global mutable state (singletons) in general and global constructors and
  //   destructors in particular.  Therefore, everything that could possibly need cleanup either
  //   lives on the stack or is transitively owned by something living on the stack.
  //
  // * Calling exit() simply means "Don't clean up anything older than this stack frame.".  If you
  //   have resources that require cleanup before exit, make sure they are owned by stack frames
  //   beyond the one that eventually calls exit().  To be as safe as possible, don't place any
  //   state in your program's main class, and don't call exit() yourself.  Then, runMainAndExit()
  //   will do it, and the only thing on the stack at that time will be your main class, which
  //   has no state anyway.
  //
  // TODO(someday):  Perhaps we should use the new std::quick_exit(), so that at_quick_exit() is
  //   available for those who really think they need it.  Unfortunately, it is not yet available
  //   on many platforms.

  virtual void warning(StringPtr message) = 0;
  // Print the given message to standard error.  A newline is printed after the message if it
  // doesn't already have one.

  virtual void error(StringPtr message) = 0;
  // Like `warning()`, but also sets a flag indicating that the process has failed, and that when
  // it eventually exits it should indicate an error status.

  KJ_NORETURN(virtual void exitError(StringPtr message)) = 0;
  // Equivalent to `error(message)` followed by `exit()`.

  KJ_NORETURN(virtual void exitInfo(StringPtr message)) = 0;
  // Displays the given non-error message to the user and then calls `exit()`.  This is used to
  // implement things like --help.

  virtual void increaseLoggingVerbosity() = 0;
  // Increase the level of detail produced by the debug logging system.  `MainBuilder` invokes
  // this if the caller uses the -v flag.

  // TODO(someday):  Add interfaces representing standard OS resources like the filesystem, so that
  //   these things can be mocked out.
};

class TopLevelProcessContext final: public ProcessContext {
  // A ProcessContext implementation appropriate for use at the actual entry point of a process
  // (as opposed to when you are trying to call a program's main function from within some other
  // program).  This implementation writes errors to stderr, and its `exit()` method actually
  // calls the C `quick_exit()` function.

public:
  explicit TopLevelProcessContext(StringPtr programName);

  struct CleanShutdownException { int exitCode; };
  // If the environment variable KJ_CLEAN_SHUTDOWN is set, then exit() will actually throw this
  // exception rather than exiting.  `kj::runMain()` catches this exception and returns normally.
  // This is useful primarily for testing purposes, to assist tools like memory leak checkers that
  // are easily confused by quick_exit().

  StringPtr getProgramName() override;
  KJ_NORETURN(void exit() override);
  void warning(StringPtr message) override;
  void error(StringPtr message) override;
  KJ_NORETURN(void exitError(StringPtr message) override);
  KJ_NORETURN(void exitInfo(StringPtr message) override);
  void increaseLoggingVerbosity() override;

private:
  StringPtr programName;
  bool cleanShutdown;
  bool hadErrors = false;
};

typedef Function<void(StringPtr programName, ArrayPtr<const StringPtr> params)> MainFunc;

int runMainAndExit(ProcessContext& context, MainFunc&& func, int argc, char* argv[]);
// Runs the given main function and then exits using the given context.  If an exception is thrown,
// this will catch it, report it via the context and exit with an error code.
//
// Normally this function does not return, because returning would probably lead to wasting time
// on cleanup when the process is just going to exit anyway.  However, to facilitate memory leak
// checkers and other tools that require a clean shutdown to do their job, if the environment
// variable KJ_CLEAN_SHUTDOWN is set, the function will in fact return an exit code, which should
// then be returned from main().
//
// Most users will use the KJ_MAIN() macro rather than call this function directly.

#define KJ_MAIN(MainClass) \
  int main(int argc, char* argv[]) { \
    ::kj::TopLevelProcessContext context(argv[0]); \
    MainClass mainObject(context); \
    return ::kj::runMainAndExit(context, mainObject.getMain(), argc, argv); \
  }
// Convenience macro for declaring a main function based on the given class.  The class must have
// a constructor that accepts a ProcessContext& and a method getMain() which returns
// kj::MainFunc (probably building it using a MainBuilder).

class MainBuilder {
  // Builds a main() function with nice argument parsing.  As options and arguments are parsed,
  // corresponding callbacks are called, so that you never have to write a massive switch()
  // statement to interpret arguments.  Additionally, this approach encourages you to write
  // main classes that have a reasonable API that can be used as an alternative to their
  // command-line interface.
  //
  // All StringPtrs passed to MainBuilder must remain valid until option parsing completes.  The
  // assumption is that these strings will all be literals, making this an easy requirement.  If
  // not, consider allocating them in an Arena.
  //
  // Some flags are automatically recognized by the main functions built by this class:
  //     --help:  Prints help text and exits.  The help text is constructed based on the
  //       information you provide to the builder as you define each flag.
  //     --verbose:  Increase logging verbosity.
  //     --version:  Print version information and exit.
  //
  // Example usage:
  //
  //     class FooMain {
  //     public:
  //       FooMain(kj::ProcessContext& context): context(context) {}
  //
  //       bool setAll() { all = true; return true; }
  //       // Enable the --all flag.
  //
  //       kj::MainBuilder::Validity setOutput(kj::StringPtr name) {
  //         // Set the output file.
  //
  //         if (name.endsWith(".foo")) {
  //           outputFile = name;
  //           return true;
  //         } else {
  //           return "Output file must have extension .foo.";
  //         }
  //       }
  //
  //       kj::MainBuilder::Validity processInput(kj::StringPtr name) {
  //         // Process an input file.
  //
  //         if (!exists(name)) {
  //           return kj::str(name, ": file not found");
  //         }
  //         // ... process the input file ...
  //         return true;
  //       }
  //
  //       kj::MainFunc getMain() {
  //         return MainBuilder(context, "Foo Builder v1.5", "Reads <source>s and builds a Foo.")
  //             .addOption({'a', "all"}, KJ_BIND_METHOD(*this, setAll),
  //                 "Frob all the widgets.  Otherwise, only some widgets are frobbed.")
  //             .addOptionWithArg({'o', "output"}, KJ_BIND_METHOD(*this, setOutput),
  //                 "<filename>", "Output to <filename>.  Must be a .foo file.")
  //             .expectOneOrMoreArgs("<source>", KJ_BIND_METHOD(*this, processInput))
  //             .build();
  //       }
  //
  //     private:
  //       bool all = false;
  //       kj::StringPtr outputFile;
  //       kj::ProcessContext& context;
  //     };

public:
  MainBuilder(ProcessContext& context, StringPtr version,
              StringPtr briefDescription, StringPtr extendedDescription = nullptr);
  ~MainBuilder() noexcept(false);

  class OptionName {
  public:
    OptionName() = default;
    inline OptionName(char shortName): isLong(false), shortName(shortName) {}
    inline OptionName(const char* longName): isLong(true), longName(longName) {}

  private:
    bool isLong;
    union {
      char shortName;
      const char* longName;
    };
    friend class MainBuilder;
  };

  class Validity {
  public:
    inline Validity(bool valid) {
      if (!valid) errorMessage = heapString("invalid argument");
    }
    inline Validity(const char* errorMessage)
        : errorMessage(heapString(errorMessage)) {}
    inline Validity(String&& errorMessage)
        : errorMessage(kj::mv(errorMessage)) {}

    inline const Maybe<String>& getError() const { return errorMessage; }
    inline Maybe<String> releaseError() { return kj::mv(errorMessage); }

  private:
    Maybe<String> errorMessage;
    friend class MainBuilder;
  };

  MainBuilder& addOption(std::initializer_list<OptionName> names, Function<Validity()> callback,
                         StringPtr helpText);
  // Defines a new option (flag).  `names` is a list of characters and strings that can be used to
  // specify the option on the command line.  Single-character names are used with "-" while string
  // names are used with "--".  `helpText` is a natural-language description of the flag.
  //
  // `callback` is called when the option is seen.  Its return value indicates whether the option
  // was accepted.  If not, further option processing stops, and error is written, and the process
  // exits.
  //
  // Example:
  //
  //     builder.addOption({'a', "all"}, KJ_BIND_METHOD(*this, showAll), "Show all files.");
  //
  // This option could be specified in the following ways:
  //
  //     -a
  //     --all
  //
  // Note that single-character option names can be combined into a single argument.  For example,
  // `-abcd` is equivalent to `-a -b -c -d`.
  //
  // The help text for this option would look like:
  //
  //     -a, --all
  //         Show all files.
  //
  // Note that help text is automatically word-wrapped.

  MainBuilder& addOptionWithArg(std::initializer_list<OptionName> names,
                                Function<Validity(StringPtr)> callback,
                                StringPtr argumentTitle, StringPtr helpText);
  // Like `addOption()`, but adds an option which accepts an argument.  `argumentTitle` is used in
  // the help text.  The argument text is passed to the callback.
  //
  // Example:
  //
  //     builder.addOptionWithArg({'o', "output"}, KJ_BIND_METHOD(*this, setOutput),
  //                              "<filename>", "Output to <filename>.");
  //
  // This option could be specified with an argument of "foo" in the following ways:
  //
  //     -ofoo
  //     -o foo
  //     --output=foo
  //     --output foo
  //
  // Note that single-character option names can be combined, but only the last option can have an
  // argument, since the characters after the option letter are interpreted as the argument.  E.g.
  // `-abofoo` would be equivalent to `-a -b -o foo`.
  //
  // The help text for this option would look like:
  //
  //     -o FILENAME, --output=FILENAME
  //         Output to FILENAME.

  MainBuilder& addSubCommand(StringPtr name, Function<MainFunc()> getSubParser,
                             StringPtr briefHelpText);
  // If exactly the given name is seen as an argument, invoke getSubParser() and then pass all
  // remaining arguments to the parser it returns.  This is useful for implementing commands which
  // have lots of sub-commands, like "git" (which has sub-commands "checkout", "branch", "pull",
  // etc.).
  //
  // `getSubParser` is only called if the command is seen.  This avoids building main functions
  // for commands that aren't used.
  //
  // `briefHelpText` should be brief enough to show immediately after the command name on a single
  // line.  It will not be wrapped.  Users can use the built-in "help" command to get extended
  // help on a particular command.

  MainBuilder& expectArg(StringPtr title, Function<Validity(StringPtr)> callback);
  MainBuilder& expectOptionalArg(StringPtr title, Function<Validity(StringPtr)> callback);
  MainBuilder& expectZeroOrMoreArgs(StringPtr title, Function<Validity(StringPtr)> callback);
  MainBuilder& expectOneOrMoreArgs(StringPtr title, Function<Validity(StringPtr)> callback);
  // Set callbacks to handle arguments.  `expectArg()` and `expectOptionalArg()` specify positional
  // arguments with special handling, while `expect{Zero,One}OrMoreArgs()` specifies a handler for
  // an argument list (the handler is called once for each argument in the list).  `title`
  // specifies how the argument should be represented in the usage text.
  //
  // All options callbacks are called before argument callbacks, regardless of their ordering on
  // the command line.  This matches GNU getopt's behavior of permuting non-flag arguments to the
  // end of the argument list.  Also matching getopt, the special option "--" indicates that the
  // rest of the command line is all arguments, not options, even if they start with '-'.
  //
  // The interpretation of positional arguments is fairly flexible.  The non-optional arguments can
  // be expected at the beginning, end, or in the middle.  If more arguments are specified than
  // the number of non-optional args, they are assigned to the optional argument handlers in the
  // order of registration.
  //
  // For example, say you called:
  //     builder.expectArg("<foo>", ...);
  //     builder.expectOptionalArg("<bar>", ...);
  //     builder.expectArg("<baz>", ...);
  //     builder.expectZeroOrMoreArgs("<qux>", ...);
  //     builder.expectArg("<corge>", ...);
  //
  // This command requires at least three arguments: foo, baz, and corge.  If four arguments are
  // given, the second is assigned to bar.  If five or more arguments are specified, then the
  // arguments between the third and last are assigned to qux.  Note that it never makes sense
  // to call `expect*OrMoreArgs()` more than once since only the first call would ever be used.
  //
  // In practice, you probably shouldn't create such complicated commands as in the above example.
  // But, this flexibility seems necessary to support commands where the first argument is special
  // as well as commands (like `cp`) where the last argument is special.

  MainBuilder& callAfterParsing(Function<Validity()> callback);
  // Call the given function after all arguments have been parsed.

  MainFunc build();
  // Build the "main" function, which simply parses the arguments.  Once this returns, the
  // `MainBuilder` is no longer valid.

private:
  struct Impl;
  Own<Impl> impl;

  class MainImpl;
};

}  // namespace kj

KJ_END_HEADER