In D102590, we agreed to create a BlockStyle and BlockChomping enums. This Diff address that change.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Event Timeline
@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. |
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.