This is an archive of the discontinued LLVM Phabricator instance.

[clang-format] Replace DeriveLineEnding and UseCRLF with LineEnding
ClosedPublic

Authored by owenpan on Jan 12 2023, 9:35 PM.

Details

Summary

Below is the mapping:

LineEnding  DeriveLineEnding UseCRLF
LF                false       false
CRLF              false       true
DeriveLF          true        false
DeriveCRLF        true        true

Diff Detail

Event Timeline

owenpan created this revision.Jan 12 2023, 9:35 PM
Herald added a project: Restricted Project. · View Herald TranscriptJan 12 2023, 9:35 PM
owenpan requested review of this revision.Jan 12 2023, 9:35 PM
Herald added a project: Restricted Project. · View Herald TranscriptJan 12 2023, 9:35 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript
rymiel accepted this revision.Jan 13 2023, 2:32 AM

(This needs to run the updated dump script from D138446)

I'm not sure what the strict benefit of squishing the two options together is, but I support it

This revision is now accepted and ready to land.Jan 13 2023, 2:32 AM

(This needs to run the updated dump script from D138446)

I'm not sure what the strict benefit of squishing the two options together is, but I support it

Having just one option instead of two, for one feature is better, especially when the two options are that far apart in the documentation.

owenpan updated this revision to Diff 489125.Jan 13 2023, 2:42 PM

Rebased and ran the latest dump_format_style.py to generate ClangFormatStyleOptions.rst.

owenpan edited the summary of this revision. (Show Details)Jan 13 2023, 3:38 PM

(This needs to run the updated dump script from D138446)

I'm not sure what the strict benefit of squishing the two options together is, but I support it

Having just one option instead of two, for one feature is better, especially when the two options are that far apart in the documentation.

+1.

I'm not sure what the strict benefit of squishing the two options together is, but I support it

See D108752 and the added table in the summary.

This revision was landed with ongoing or failed builds.Jan 13 2023, 3:46 PM
This revision was automatically updated to reflect the committed changes.

This also made me wonder, is there an actual policy on deprecated options? As in, when they are actually removed. Is there even prior precedent for doing this? (I wouldn't know because I'm a very recent user)

This also made me wonder, is there an actual policy on deprecated options? As in, when they are actually removed. Is there even prior precedent for doing this? (I wouldn't know because I'm a very recent user)

I think the first one was D108752 and the documentation can handle that since D127578.
Removing an option is not different than changing the type of an option, users of libformat have to adapt, and users of clang-format don't notice (if everything is done right), because the parsing for the removed options is still there, see lines 1068 and following of Format.cpp in this change.

This also made me wonder, is there an actual policy on deprecated options? As in, when they are actually removed. Is there even prior precedent for doing this? (I wouldn't know because I'm a very recent user)

I think the first one was D108752 and the documentation can handle that since D127578.
Removing an option is not different than changing the type of an option, users of libformat have to adapt, and users of clang-format don't notice (if everything is done right), because the parsing for the removed options is still there, see lines 1068 and following of Format.cpp in this change.

+1.

owenpan added a comment.EditedJan 21 2023, 8:19 PM

This also made me wonder, is there an actual policy on deprecated options? As in, when they are actually removed.

We deprecate options only as a cleanup (as in this patch) or when adding new options (as in D108752) and should maintain backward compatibility. (Also see the original idea from @MyDeveloperDay in D19031#1745767.)