[all-commits] [llvm/llvm-project] c5f34d: [CommandLine] Keep option default value unset if n...

[Yevgeny Rouban via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: c5f34d169244db3f321d75d036902751ec03fe42
      https://github.com/llvm/llvm-project/commit/c5f34d169244db3f321d75d036902751ec03fe42
  Author: Yevgeny Rouban <yrouban at azul.com>
  Date:   2022-03-11 (Fri, 11 Mar 2022)

  Changed paths:
    M llvm/include/llvm/Support/CommandLine.h
    M llvm/unittests/Support/CommandLineTest.cpp

  Log Message:
  -----------
  [CommandLine] Keep option default value unset if no cl::init() is used

Current declaration of cl::opt is incoherent between class and non-class
specializations of the opt_storage template. There is an inconsistency
in the initialization of the Default field: for inClass instances
the default constructor is used - it sets the Optional Default field to
None; though for non-inClass instances the Default field is set to
the type's default value. For non-inClass instances it is impossible
to know if the option is defined with cl::init() initializer or not:

cl::opt<int> i1("option-i1");
cl::opt<int> i2("option-i2", cl::init(0));
cl::opt<std::string> s1("option-s1");
cl::opt<std::string> s2("option-s2", cl::init(""));

assert(s1.Default.hasValue() != s2.Default.hasValue()); // Ok
assert(i1.Default.hasValue() != i2.Default.hasValue()); // Fails

This patch changes constructor of the non-class specializations to keep
the Default field unset (that is None) rather than initialize it with
DataType().

Reviewed By: lattner
Differential Revision: https://reviews.llvm.org/D114645