Introduce yet-check Command#332
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
To resolve #289, we added the following
yet-checkcommand:result
It takes two specification versions (e.g., git commit hashes or tags) as input and reports the steps and types that are newly introduced in the "to" specification compared to the "from" specification. The output includes GitHub warning annotations that can be directly used in GitHub Actions to highlight the unsupported steps and types in pull requests.
The main difference from the existing yet-checker is that this command ignores the steps and types that are already unsupported in the "from" specification. For each pair of "removed" and "added" lines in the diff of the spec, if the "removed" lines contain unsupported steps (or types), then the corresponding "added" lines are ignored even if they contain unsupported steps (or types).
The diff chunks are often divided into unusual chunks because of the large context changes in the surrounding lines. To handle this, we merge adjacent diff chunks if they are close enough defined by a threshold (default: 1 line). You can adjust this threshold using the
-yet-check:merge-thresholdoption.Additionally, it dumps the summary file
summary.mdand the detailed JSON filesyet-steps.jsonandyet-types.jsonin thelogs/yet-checkdirectory for further investigation. For example, the following table is included in thesummary.mdfile generated in the above example:summary.md
Newly Introduced Yet Steps
11 newly introduced yet steps found.
Type check will not be performed after these lines.
INTRINSICS.Uint8Array.fromBase64Set the value at each index of _ta_.[[ViewedArrayBuffer]].[[ArrayBufferData]] to the value at the corresponding index of _result_.[[Bytes]].INTRINSICS.Uint8Array.fromHexSet the value at each index of _ta_.[[ViewedArrayBuffer]].[[ArrayBufferData]] to the value at the corresponding index of _result_.[[Bytes]].INTRINSICS.Uint8Array.prototype.toBase64Let _outAscii_ be the sequence of code points which results from encoding _toEncode_ according to the base64 encoding specified in section 4 of <a href="https://datatracker.ietf.org/doc/html/rfc4648">RFC 4648</a>. Padding is included if and only if _omitPadding_ is *false*.INTRINSICS.Uint8Array.prototype.toBase64Let _outAscii_ be the sequence of code points which results from encoding _toEncode_ according to the base64url encoding specified in section 5 of <a href="https://datatracker.ietf.org/doc/html/rfc4648">RFC 4648</a>. Padding is included if and only if _omitPadding_ is *false*.INTRINSICS.Uint8Array.prototype.toHexFor each byte _byte_ of _toEncode_, do [...]DecodeFullLengthBase64ChunkLet _byteSequence_ be the unique sequence of 3 bytes resulting from decoding _chunk_ as base64 (i.e., the sequence such that applying the base64 encoding specified in section 4 of <a href="https://datatracker.ietf.org/doc/html/rfc4648">RFC 4648</a> to _byteSequence_ would produce _chunk_).DecodeFullLengthBase64ChunkReturn a List whose elements are the elements of _byteSequence_, in order.FromBase64if the sole code unit of _char_ is not an element of the standard base64 alphabet, then [...]FromBase64Let _remaining_ be _maxLength_ - the number of elements in _bytes_.FromHexif _hexits_ contains any code units which are not in *"0123456789abcdefABCDEF"*, then [...]FromHexLet _byte_ be the integer value represented by _hexits_ in base-16 notation, using the letters *A* through *F* and *a* through *f* for digits with values 10 through 15.Newly Introduced Yet Types
10 newly introduced yet types found.
These types will be treated as bottom (⊥) type initially but will be joined with argument types when the algorithm is called.
GetUint8ArrayByteseither a normal completion containing a List of byte values or a throw completionSetUint8ArrayBytesa List of byte valuesDecodeFinalBase64Chunkeither a normal completion containing a List of byte values, or a throw completionDecodeFinalBase64Chunka String of length 2 or 3DecodeFullLengthBase64Chunka List of byte values of length 3DecodeFullLengthBase64Chunka String of length 4FromBase64a Record with fields [[Read]] (an integer), [[Bytes]] (a List of byte values), and [[Error]] (a *SyntaxError* object or ~none~)FromBase64*"base64"* or *"base64url"*FromBase64*"loose"*, *"strict"*, or *"stop-before-partial"*FromHexa Record with fields [[Read]] (an integer), [[Bytes]] (a List of byte values), and [[Error]] (a *SyntaxError* object or ~none~)