search for: filecheck_commandline

...ileCheck invocations. >>> >>> I don't like it when the behavior of such a low-level tool like this changes based on environment variables. It isn't discoverable in --help. If for some reason, it is bad for lit to implicitly pass the option, I'd rather have a standard FILECHECK_COMMANDLINE environment variable, and have filecheck parse arbitrary options out of it using the cl::ParseEnvironmentOptions function. >> >> I agree that a command line option would be better. But in that case >> all tests should be updated. It is not an issue for me -- it is >> mostl...

...), and adds the flag to FileCheck invocations. I don't like it when the behavior of such a low-level tool like this changes based on environment variables. It isn't discoverable in --help. If for some reason, it is bad for lit to implicitly pass the option, I'd rather have a standard FILECHECK_COMMANDLINE environment variable, and have filecheck parse arbitrary options out of it using the cl::ParseEnvironmentOptions function. -Chris

...invocations. >>>> >>>> I don't like it when the behavior of such a low-level tool like this changes based on environment variables. It isn't discoverable in --help. If for some reason, it is bad for lit to implicitly pass the option, I'd rather have a standard FILECHECK_COMMANDLINE environment variable, and have filecheck parse arbitrary options out of it using the cl::ParseEnvironmentOptions function. >>> >>> I agree that a command line option would be better. But in that case >>> all tests should be updated. It is not an issue for me -- it is &g...

...ds the flag to FileCheck invocations. > > I don't like it when the behavior of such a low-level tool like this changes based on environment variables. It isn't discoverable in --help. If for some reason, it is bad for lit to implicitly pass the option, I'd rather have a standard FILECHECK_COMMANDLINE environment variable, and have filecheck parse arbitrary options out of it using the cl::ParseEnvironmentOptions function. I agree that a command line option would be better. But in that case all tests should be updated. It is not an issue for me -- it is mostly mechanical. So should I change t...

...ions. >>>>> >>>>> I don't like it when the behavior of such a low-level tool like this changes based on environment variables. It isn't discoverable in --help. If for some reason, it is bad for lit to implicitly pass the option, I'd rather have a standard FILECHECK_COMMANDLINE environment variable, and have filecheck parse arbitrary options out of it using the cl::ParseEnvironmentOptions function. >>>> >>>> I agree that a command line option would be better. But in that case >>>> all tests should be updated. It is not an issue for me...

Hello, When someone breaks a FileCheck-based test on some buildbot, sometimes it may not be obvious *why* did it fail. If the failure can not be reproduced locally, it can be very hard to fix. I propose adding a "very verbose" mode to FileCheck. In this mode FileCheck will dump the input file in case of failure. This mode will be enabled by an environment variable

...lag to FileCheck invocations. >> >> I don't like it when the behavior of such a low-level tool like this changes based on environment variables. It isn't discoverable in --help. If for some reason, it is bad for lit to implicitly pass the option, I'd rather have a standard FILECHECK_COMMANDLINE environment variable, and have filecheck parse arbitrary options out of it using the cl::ParseEnvironmentOptions function. > > I agree that a command line option would be better. But in that case > all tests should be updated. It is not an issue for me -- it is > mostly mechanical. S...

...t;>> > >>>> I don't like it when the behavior of such a low-level tool like this > changes based on environment variables. It isn't discoverable in --help. > If for some reason, it is bad for lit to implicitly pass the option, I'd > rather have a standard FILECHECK_COMMANDLINE environment variable, and have > filecheck parse arbitrary options out of it using the > cl::ParseEnvironmentOptions function. > >>> > >>> I agree that a command line option would be better. But in that case > >>> all tests should be updated. It is not an...

...behavior of such a low-level tool like this >> >>>> changes based on environment variables. It isn't discoverable in --help. >> >>>> If for some reason, it is bad for lit to implicitly pass the option, I'd >> >>>> rather have a standard FILECHECK_COMMANDLINE environment variable, and have >> >>>> filecheck parse arbitrary options out of it using the >> >>>> cl::ParseEnvironmentOptions function. >> >>> >> >>> I agree that a command line option would be better. But in that case >> &...

...ool like > this > >> >>>> changes based on environment variables. It isn't discoverable in > --help. > >> >>>> If for some reason, it is bad for lit to implicitly pass the > option, I'd > >> >>>> rather have a standard FILECHECK_COMMANDLINE environment variable, > and have > >> >>>> filecheck parse arbitrary options out of it using the > >> >>>> cl::ParseEnvironmentOptions function. > >> >>> > >> >>> I agree that a command line option would be better. Bu...

...nvironment variables. It isn't discoverable in >> >> >>>> --help. >> >> >>>> If for some reason, it is bad for lit to implicitly pass the >> >> >>>> option, I'd >> >> >>>> rather have a standard FILECHECK_COMMANDLINE environment variable, >> >> >>>> and have >> >> >>>> filecheck parse arbitrary options out of it using the >> >> >>>> cl::ParseEnvironmentOptions function. >> >> >>> >> >> >>> I agree t...