Move the check for SOURCE_DATE_EPOCH to the driver and use a cc1 option to pass it to the frontend. This avoids hidden state in the cc1 invocation and makes this env variable behave more like other env variables that clang handles in the driver.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/lib/Frontend/CompilerInvocation.cpp | ||
---|---|---|
4324 | Is it worth making err_fe_invalid_source_date_epoch a driver diagnostic? I think driver validation is more common. | |
clang/test/Driver/SOURCE_DATE_EPOCH.c | ||
3 | In case someone put the build directory under a directory with the string -source-date-epoch, even if it is highly unlikely. |
clang/lib/Frontend/CompilerInvocation.cpp | ||
---|---|---|
4324 | I wasn't sure if we could just move the validation to the driver or if we would end up duplicating it -- how bad is it to have a value that's too large? If it could cause UB or something I wouldn't want to remove the check from the frontend. |
clang/test/Driver/SOURCE_DATE_EPOCH.c | ||
---|---|---|
2 | Hi @benlangmuir, this test fails in our build environment, because we have the SOURCE_DATE_EPOCH env variable set globally. Is there any way to update the test to handle this scenario? |
clang/test/Driver/SOURCE_DATE_EPOCH.c | ||
---|---|---|
2 | I'm not aware of a portable way to unset environment variables (env -u doesn't work on some of our platforms) and this first check is low-value anyway, so I'm fine with just dropping it and only having the ones below that explicitly set a value. https://reviews.llvm.org/D142511 |
Is it worth making err_fe_invalid_source_date_epoch a driver diagnostic? I think driver validation is more common.