This is an archive of the discontinued LLVM Phabricator instance.

Use OpenFlags instead of boolean to set a file as text/binary
Needs ReviewPublic

Authored by abhina.sreeskantharajan on Apr 20 2021, 10:45 AM.

Details

Summary

This patch updates the functions createDefaultOutputFile, createOutputFile, createOutputFileImpl to use OpenFlags instead of a boolean binary flag.

I mapped the bool to the OpenFlags like the following
Binary = true -> OF_None
Binary = false -> OF_TextWithCRLF

Diff Detail

Event Timeline

abhina.sreeskantharajan requested review of this revision.Apr 20 2021, 10:45 AM
abhina.sreeskantharajan created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptApr 20 2021, 10:45 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
rnk added a subscriber: dexonsmith.Apr 20 2021, 3:58 PM

+@dexonsmith who touched this API last.

clang/include/clang/Frontend/CompilerInstance.h
738–740

I think this is only going to be worth it if we can roll up all of these booleans into a new flags enum for compiler instance. It also prevents introducing a new use of FileSystem.h, which is an expensive header to include.

clang/include/clang/Frontend/CompilerInstance.h
738–740

Sorry, I don't think I completely understand your suggestion. Are you proposing that we create a new enum just for CompilerInstance.h for the other booleans like RemoveFileOnSignal, UseTemporary, CreateMissingDirectories? And this new enum also contain text/binary flags so we don't need to use the enum in FileSystem.h?

For background, I need this specific change to set some more text files with OF_Text because my old commit got reverted since it caused CRLF issues on Windows https://reviews.llvm.org/D96363.

dexonsmith added inline comments.
clang/include/clang/Frontend/CompilerInstance.h
738–740

Yes, I think that's what @rnk is suggesting, maybe along the lines of the OutputConfigFlag in the (languishing, I need to get back to it) OutputBackend/OutputManager proposal I have (see, e.g., https://reviews.llvm.org/D95501, which needs to be split up), or maybe as a struct with named members as @sammccall suggests there.

It also prevents introducing a new use of FileSystem.h, which is an expensive header to include.

Another option that'd be more isolated would be to split the OpenFlag enum (and/or its friends) out to another header in llvm/include/llvm/Support/FileSystem/ (say, .../FileSystem/FileSystemEnums.h), like was done for UniqueID.h.

clang/include/clang/Frontend/CompilerInstance.h
738–740

Thanks for clarifying. I think having a duplicate copy of the OpenFlags may be confusing. I like the idea of putting the enums in its own header file. But can that be done in a separate change than this patch? It will be a much larger change touching more files than this patcch.