This is an archive of the discontinued LLVM Phabricator instance.

[YAMLParser] Refactor BlockStyle and BlockChomping type
Needs ReviewPublic

Authored by HassanElDesouky on Mar 6 2022, 1:49 AM.

Details

Reviewers
scott.linder
Summary

In D102590, we agreed to create a BlockStyle and BlockChomping enums. This Diff address that change.

Diff Detail

Event Timeline

HassanElDesouky created this revision.Mar 6 2022, 1:49 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 6 2022, 1:49 AM
HassanElDesouky requested review of this revision.Mar 6 2022, 1:49 AM

@scott.linder Would you mind giving this a review?
Please, if we are going to merge this can you author the commit for me? Here's my GitHub email hassaneldesouky@icloud.com

Thank you for following up! The change looks correct, but I have some nits about the general approach. Let me know what you think.

llvm/lib/Support/YAMLParser.cpp
163

This isn't actually a possible style, right? It seems like we could instead represent the cases where this comes up by using an Optional<BlockStyleIndicator>, which would keep this enum 1:1 with the YAML spec.

169

I think this representation is subtley different than the spec, where CLIP is just the default and applies whenever the indicator is "empty" or absent. This small inconsistency would also push me towards using the enum class approach.

1566–1568

This feels like this straddles multiple possible implementations, with a mix of the benefits/problems of each.

I would suggest using a type-safe enum class for the new enumerations; in that case, the char comparisons here are the single source-of-truth, at which point we enter a type safe world where one cannot accidentally compare the enumeration values to char. It also has the (subjectively) nice property that it is properly namespaced, so the BSI_ and BCI_ prefixes aren't necessary. While at it, I'd address the removal of None as a possibility, and hide some of the details by using Scanner::consume. All together, I'd suggest something like:

enum class BlockStyleIndicator {
  Literal,
  Folded
};

Optional<BlockStyleIndicator> Scanner::scanBlockStyleIndicator() {
  if (consume('>'))
    return BlockStyleIndicator::Folded;
  if (consume('|'))
    return BlockStyleIndicator::Literal;
  return None;
}

Alternatively, with the version you have using non-class enums the '>' here could be BSI_Folded, or you could just leave the implementation as-is, using the implicit conversion from char to the enum type. I think this approach is perfectly valid, but it isn't the first one I reach for if there is no other compelling reason.

1578–1590

This would get a similar treatment as above, assuming we go the enum class route.