Remove ambiguous LineTerminator generation from `proper_argo_graphql_…

…language`

README.md

@@ -1,6 +1,6 @@
 # `argo`
 
-[![Build Status](https://github.com/WhatsApp/erlang-argo/actions/workflows/ci.yml/badge.svg?branch=main)](https://github.com/WhatsApp/argo/actions) [![Hex.pm](https://img.shields.io/hexpm/v/argo_graphql.svg)](https://hex.pm/packages/argo_graphql)
+[![Build Status](https://github.com/WhatsApp/erlang-argo/actions/workflows/ci.yml/badge.svg?branch=main)](https://github.com/WhatsApp/erlang-argo/actions) [![Hex.pm](https://img.shields.io/hexpm/v/argo_graphql.svg)](https://hex.pm/packages/argo_graphql)
 
 `argo` for GraphQL.
 

apps/argo_test/src/proper_argo_graphql_language.erl

@@ -190,7 +190,17 @@ strip_whitespace_right([]) ->
 
 -spec block_string_character() -> proper_types:type().
 block_string_character() ->
-    unicode_codepoint_upto(4).
+    % LineTerminator in the scanner can produce mismatched descriptions that visually look identical
+    % after scanning, parsing, and outputting the block string characters again.
+    %
+    % The problematic characters are
+    %
+    % 1. \x{000D} (\r)
+    % 2. \x{2028} (Unicode Line Separator)
+    % 3. \x{2029} (Unicode Paragraph Separator)
+    %
+    % To simplify things, the only LineTerminator we allow is \x{000A} (or \n).
+    ?SUCHTHAT(C, unicode_codepoint_upto(4), (C =/= 16#000D andalso C =/= 16#2028 andalso C =/= 16#2029)).
 
 -spec block_string_value() -> proper_types:type().
 block_string_value() ->