update from origin 2020-07-02 #9
Merged
Conversation
This file contains 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
On Windows the InnoSetup installer was superseded by the MSI installer. It's no longer needed.
This allows us to write
fn char_to_string() -> String {
'a'.into()
}
which was not possible before.
Make it possible to customize the location of musl libdir using musl-libdir in config.toml, e.g., to use lib64 instead of lib.
Fixed grammar and sentence structure on appropriate instances.
…s recently merged This commit updates rustc's LLVM submodule to include new AVR-specific fixes recently merged on the Rust LLVM 'rustc/10.0-2020-05-05' branch. All of these cherry-picked commits exist in upstream LLVM and were cherry-picked into Rust's LLVM fork in commit 6c040dd86ed. |- 6c040dd86ed Merge pull request #66 from dylanmckay/avr-pick-upstream-llvm-fixes |- 12dfdd3aed7 [AVR] Rewrite the function calling convention. |- 118ac53f12b [AVR] Don't adjust for instruction size |- bc27c282e13 [AVR] Fix miscompilation of zext + add |- cfbe205a7e8 [AVR] Remove faulty stack pushing behavior |- 143e1469e96 [AVR] Fix stack size in functions with a frame pointer |- 6b2445d841e [LLVM][AVR] Support for R_AVR_6 fixup |- 93ee4da19cf [AVR] Fix I/O instructions on XMEGA |- 962c2415ffb [AVR] Do not place functions in .progmem.data |- 65b8b170aef [AVR] Do not use divmod calls for bigger integers |- 93a3b595d1c [AVR] Generalize the previous interrupt bugfix to signal |- handlers too |- cc4286349b4 [AVR] Respect the 'interrupt' function attribute |- 954d0a92205 [AVR] Fix reads of uninitialized variables from constructor of AVRSubtarget |- 1c0ddae73c9 [AVR] Fix read of uninitialized variable AVRSubtarget:::ELFArch |- 0ed0823fe60 [AVR] Fix incorrect register state for LDRdPtr |- 96075fc433d [AVR] Don't adjust addresses by 2 for absolute values |- 6dfc55ba53b [AVR] Use correct register class for mul instructions These changes include both correctness fixes and LLVM assertion error fixes. Once all of these commits have been cherry-picked, all of the LLVM plumbing for rust-lang/master to compile the AVR blink program will be in place. Once this commit is merged, only PR #73270 will be blocking successful compilation and emission of the AVR LED blink program.
I know very little about rust, so I saw this example and tried to generalize it by writing,
```
let layout = Layout::new::<T>();
let new_obj = unsafe {
let ptr = alloc(layout) as *mut T;
*ptr = obj;
Box::from_raw(ptr)
};
```
for some more complicated `T`, which ended up crashing with SIGSEGV,
because it tried to `drop_in_place` the previous object in `ptr` which is
of course garbage. I also added a comment that explains why `.write`
is used, but I think adding that comment is optional and may be too verbose
here. I do however think that changing this example is a good idea to
suggest the correct generalization. `.write` is also used in most of the rest
of the documentation here, even if the example is `i32`, so it would additionally
be more consistent.
Co-authored-by: Niko Matsakis <[email protected]>
Linked the logo/svg to https://www.rust-lang.org/ (change if required)
Added responsiveness to image logo based on device width (set at 90% of device width, which can be changed as per requirement)
update master
They are gated by internal feature gate const_likely
This commit applies the existing 'extra angle bracket recovery' logic when parsing fields in struct definitions. This allows us to continue parsing the struct's fields, avoiding spurious 'missing field' errors in code that tries to use the struct.
Co-authored-by: Oliver Scherer <[email protected]>
…ndness, r=nikomatsakis Don't implement Fn* traits for #[target_feature] functions Closes #72012.
expand: Stop using nonterminals for passing tokens to attribute and derive macros Make one more step towards fully token-based expansion and fix issues described in #72545 (comment). Now `struct S;` is passed to `foo!(struct S;)` and `#[foo] struct S;` in the same way - as a token stream `struct S ;`, rather than a single non-terminal token `NtItem` which is then broken into parts later. The cost is making pretty-printing of token streams less pretty. Some of the pretty-printing regressions will be recovered by keeping jointness with each token, which we will need to do anyway. Unfortunately, this is not exactly the same thing as #73102. One more observable effect is how `$crate` is printed in the attribute input. Inside `NtItem` was printed as `crate` or `that_crate`, now as a part of a token stream it's printed as `$crate` (there are good reasons for these differences, see #62393 and related PRs). This may break old proc macros (custom derives) written before the main portion of the proc macro API (macros 1.2) was stabilized, those macros did `input.to_string()` and reparsed the result, now that result can contain `$crate` which cannot be reparsed. So, I think we should do this regardless, but we need to run crater first. r? @Aaron1011
Provide more information on duplicate lang item error. This gives some notes on the location of the files where the lang items were loaded from. Some duplicate lang item errors can be a little confusing, and this might help in diagnosing what has happened. Here's an example when hitting a bug with Cargo's build-std: ``` error: duplicate lang item in crate `core` (which `rustc_std_workspace_core` depends on): `try`. | = note: the lang item is first defined in crate `core` (which `z10` depends on) = note: first definition in `core` loaded from /Users/eric/Proj/rust/cargo/scratch/z10/target/target/debug/deps/libcore-a764da499c7385f4.rmeta = note: second definition in `core` loaded from /Users/eric/Proj/rust/cargo/scratch/z10/target/target/debug/deps/libcore-5b082675aea34986.rmeta ```
Handle `macro_rules!` tokens consistently across crates When we serialize a `macro_rules!` macro, we used a 'lowered' `TokenStream` for its body, which has all `Nonterminal`s expanded in-place via `nt_to_tokenstream`. This matters when an 'outer' `macro_rules!` macro expands to an 'inner' `macro_rules!` macro - the inner macro may use tokens captured from the 'outer' macro in its definition. This means that invoking a foreign `macro_rules!` macro may use a different body `TokenStream` than when the same `macro_rules!` macro is invoked in the same crate. This difference is observable by proc-macros invoked by a `macro_rules!` macro - a `None`-delimited group will be seen in the same-crate case (inserted when convering `Nonterminal`s to the `proc_macro` crate's structs), but no `None`-delimited group in the cross-crate case. To fix this inconsistency, we now insert `None`-delimited groups when 'lowering' a `Nonterminal` `macro_rules!` body, just as we do in `proc_macro_server`. Additionally, we no longer print extra spaces for `None`-delimited groups - as far as pretty-printing is concerned, they don't exist (only their contents do). This ensures that `Display` output of a `TokenStream` does not depend on which crate a `macro_rules!` macro was invoked from. This PR is necessary in order to patch the `solana-genesis-programs` for the upcoming hygiene serialization breakage (#72121 (comment)). The `solana-genesis-programs` crate will need to use a proc macro to re-span certain tokens in a nested `macro_rules!`, which requires us to consistently use a `None`-delimited group. See `src/test/ui/proc-macro/nested-macro-rules.rs` for an example of the kind of nested `macro_rules!` affected by this crate.
…tthewjasper Recover extra trailing angle brackets in struct definition This commit applies the existing 'extra angle bracket recovery' logic when parsing fields in struct definitions. This allows us to continue parsing the struct's fields, avoiding spurious 'missing field' errors in code that tries to use the struct.
Split and expand nonstandard-style lints unicode unit test. RFC 2457 requested that the `nonstandard_style` series of linted be adjusted to cover the non_ascii_identifier case. However when i read the code of those implementations, it seems they're already supporting non_ascii_identifiers. But the exact rules is a little different than what's proposed in RFC 2457. So I splitted and expanded the existing test case to try to exercise every branch in the code. I think it'll also be easier to examine the cases in these unit tests to see whether it's ok to just leave them as is, or some adjustments are needed. r? @Manishearth
Remove defunct `-Z print-region-graph`
…chievink Fix markdown rendering in librustc_lexer docs Use back-ticks instead of quotation marks in docs for the block comment variant of TokenKind. ## [Before](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/enum.TokenKind.html#variant.BlockComment) and after <img width="1103" alt="Screen Shot 2020-06-28 at 1 22 30 PM" src="https://user-images.githubusercontent.com/19642016/85957562-446a8380-b943-11ea-913a-442cf7744083.png"> <img width="1015" alt="Screen Shot 2020-06-28 at 1 28 29 PM" src="https://user-images.githubusercontent.com/19642016/85957566-4af8fb00-b943-11ea-8fef-a09c1d586772.png"> ## Question For visual consistency, should we use back-ticks throughout the docs for these enum variants?
Fix Zulip topic format Yet another instance of me making a mistake after copy-pasting :D r? @Dylan-DPC
Clean up E0712 explanation r? @Dylan-DPC
remove duplicate test for #61935 Apparently I somehow messed up the issue number in #67890 which caused us to add this test twice, both as https://github.com/rust-lang/rust/blob/master/src/test/ui/const-generics/issues/issue-61935.rs and https://github.com/rust-lang/rust/blob/master/src/test/ui/const-generics/lazy-normalization/issue-71922.rs #61935 is the actually fixed issue while #71922 is still not working, as it depends on lazy norm of repeat expressions
Add missing backtick in `ty_error_with_message`
`#[deny(unsafe_op_in_unsafe_fn)]` in libstd/fs.rs The `libstd/fs.rs` part of #73904 . Wraps the two calls to an unsafe fn `Initializer::nop()` in an `unsafe` block. Followed instructions in parent issue, ran `./x.py check src/libstd/` after adding the lint and two warnings were given. After adding these changes, those disappear.
Rewrite a few manual index loops with while-let
There were a few instances of this pattern:
```rust
while index < vec.len() {
let item = &vec[index];
// ...
}
```
These can be indexed at once:
```rust
while let Some(item) = vec.get(index) {
// ...
}
```
Particularly in `ObligationForest::process_obligations`, this mitigates
a codegen regression found with LLVM 11 (#73526).
Fix comment typo
Implement `slice_strip` feature Tracking issue: #73413
Deny unsafe ops in unsafe fns in libcore After `liballoc`, It's time for `libcore` :D I planned to do this bit by bit to avoid having a big chunk of diffs, so to make reviews easier, and to make the unsafe blocks narrower and take the time to document them properly. r? @nikomatsakis cc @RalfJung
…iser add spans to injected coverage counters, extract with CoverageData query This is the next iteration on the Rust Coverage implementation, and follows PR #73488 @tmandry @wesleywiser I came up with an approach for coverage spans, pushing them through the Call terminator as additional args so they can be extracted by the CoverageData query. I'm using an IndexVec to store them in CoverageData such that there can be only one per index (even if parts of the MIR get duplicated during optimization). If this approach works for you, I can quickly expand on this to build a separate IndexVec for counter expressions, using a separate call that will be ignored during code generation, but from which I can extract the counter expression values. Let me know your thoughts. Thanks! r? @tmandry Rust compiler MCP rust-lang/compiler-team#278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation
ast_pretty: Pass some token streams and trees by reference Salvaged from an intermediate version of #73345.
…ievink Add newline to rustc MultiSpan docs Also adds back-ticks when referring to the contents of this collection.
Compile rustdoc less often. Previously rustdoc was built 3 times with `x.py test`: 1. stage2 (using stage1 compiler) for compiletest tests (stage1-tools copied to stage2). 2. stage1 (using stage0 compiler) for std crate tests (stage0-tools copied to stage1). 3. stage2 test (using stage2 compiler) for rustdoc crate tests and error_index_generator (stage2-tools). This PR removes the majority of number 3, where it will instead use the stage1 compiler, which will share the artifacts from number 1. This matches the behavior of the libstd crate tests. I don't think it is entirely necessary to run the tests using stage2. At `-j2`, the last build step goes from about 300s to 70s on my machine. It's not a huge win, but shaving 4 minutes isn't bad. The other two builds would be pretty difficult (or undesired or impossible) to unify. It looks like std tests use stage1 very intentionally (see `force_use_stage1` and its history), and compiletests use the top stage very intentionally. Unfortunately the linkchecker builds all docs at stage2 (stage2-tools), which means a few build script artifacts are not shared. It's not really clear to me how to fix that (because it uses `default_doc`, there doesn't seem to be any control over the stages). --- For `x.py doc`, rustdoc was previously built three times (with compiler-docs): 1. stage2 (using stage1 compiler) for normal documentation output (stage1-tools copied to stage2). 2. stage1 (using stage0 compiler) for compiler-docs 3. stage2 (using stage2 compiler) for error_index_generator (stage2-tools) This PR combines these so that they consistently use the "top stage" rustdoc. I don't know why the compiler-docs was written to use stage minus one, but it seems better to be consistent across the doc steps. --- I've tried to test this with a variety of commands (`x.py doc`, `x.py test`, different `--stage` flags, `full-bootstrap`, setting `--target`, etc.) to try to make sure there aren't significant regressions here. It's tricky since there are so many variables, and this stuff is difficult for me to fully understand. Closes #70799 (I think)
Fix wasm32 being broken due to a NodeJS version bump Emscripten's SDK [recently bumped the version of NodeJS they shipped](emscripten-core/emsdk#529), but our Dockerfile for the wasm32 builder hardcoded the version number. This will cause consistent CI failures once the currently cached image is rebuilt (either due to a change or due to the cache expiring). This PR fixes the problem by finding the latest version of NodeJS in the Emscripten SDK and symlinking it to a "latest" directory, which is then added to the `PATH`.
Changes required for rustc/cargo to build for iOS targets cargo, rustc, clippy, rust-src, and rust-analysis successfully build for `aarch64-apple-ios` with these changes. NOTE: cargo required arm64-ios openssl/libcurl to be linked.  
Optimise fast path of checked_ops with `unlikely` This PR marks paths returning `None` in checked_ops as unlikely to improvde codegen. Fixes #73731
Rollup of 16 pull requests Successful merges: - #72569 (Remove legacy InnoSetup GUI installer) - #73306 (Don't implement Fn* traits for #[target_feature] functions) - #73345 (expand: Stop using nonterminals for passing tokens to attribute and derive macros) - #73449 (Provide more information on duplicate lang item error.) - #73569 (Handle `macro_rules!` tokens consistently across crates) - #73803 (Recover extra trailing angle brackets in struct definition) - #73839 (Split and expand nonstandard-style lints unicode unit test.) - #73841 (Remove defunct `-Z print-region-graph`) - #73848 (Fix markdown rendering in librustc_lexer docs) - #73865 (Fix Zulip topic format) - #73892 (Clean up E0712 explanation) - #73898 (remove duplicate test for #61935) - #73906 (Add missing backtick in `ty_error_with_message`) - #73909 (`#[deny(unsafe_op_in_unsafe_fn)]` in libstd/fs.rs) - #73910 (Rewrite a few manual index loops with while-let) - #73929 (Fix comment typo) Failed merges: r? @ghost
Rollup of 10 pull requests Successful merges: - #73414 (Implement `slice_strip` feature) - #73564 (linker: Create GNU_EH_FRAME header by default when producing ELFs) - #73622 (Deny unsafe ops in unsafe fns in libcore) - #73684 (add spans to injected coverage counters, extract with CoverageData query) - #73812 (ast_pretty: Pass some token streams and trees by reference) - #73853 (Add newline to rustc MultiSpan docs) - #73883 (Compile rustdoc less often.) - #73885 (Fix wasm32 being broken due to a NodeJS version bump) - #73903 (Changes required for rustc/cargo to build for iOS targets) - #73938 (Optimise fast path of checked_ops with `unlikely`) Failed merges: r? @ghost
richkadel
added a commit
that referenced
this pull request
Oct 5, 2020
This is a combination of 18 commits. Commit #2: Additional examples and some small improvements. Commit #3: fixed mir-opt non-mir extensions and spanview title elements Corrected a fairly recent assumption in runtest.rs that all MIR dump files end in .mir. (It was appending .mir to the graphviz .dot and spanview .html file names when generating blessed output files. That also left outdated files in the baseline alongside the files with the incorrect names, which I've now removed.) Updated spanview HTML title elements to match their content, replacing a hardcoded and incorrect name that was left in accidentally when originally submitted. Commit #4: added more test examples also improved Makefiles with support for non-zero exit status and to force validation of tests unless a specific test overrides it with a specific comment. Commit #5: Fixed rare issues after testing on real-world crate Commit #6: Addressed PR feedback, and removed temporary -Zexperimental-coverage -Zinstrument-coverage once again supports the latest capabilities of LLVM instrprof coverage instrumentation. Also fixed a bug in spanview. Commit #7: Fix closure handling, add tests for closures and inner items And cleaned up other tests for consistency, and to make it more clear where spans start/end by breaking up lines. Commit #8: renamed "typical" test results "expected" Now that the `llvm-cov show` tests are improved to normally expect matching actuals, and to allow individual tests to override that expectation. Commit #9: test coverage of inline generic struct function Commit #10: Addressed review feedback * Removed unnecessary Unreachable filter. * Replaced a match wildcard with remining variants. * Added more comments to help clarify the role of successors() in the CFG traversal Commit #11: refactoring based on feedback * refactored `fn coverage_spans()`. * changed the way I expand an empty coverage span to improve performance * fixed a typo that I had accidently left in, in visit.rs Commit #12: Optimized use of SourceMap and SourceFile Commit #13: Fixed a regression, and synched with upstream Some generated test file names changed due to some new change upstream. Commit #14: Stripping out crate disambiguators from demangled names These can vary depending on the test platform. Commit #15: Ignore llvm-cov show diff on test with generics, expand IO error message Tests with generics produce llvm-cov show results with demangled names that can include an unstable "crate disambiguator" (hex value). The value changes when run in the Rust CI Windows environment. I added a sed filter to strip them out (in a prior commit), but sed also appears to fail in the same environment. Until I can figure out a workaround, I'm just going to ignore this specific test result. I added a FIXME to follow up later, but it's not that critical. I also saw an error with Windows GNU, but the IO error did not specify a path for the directory or file that triggered the error. I updated the error messages to provide more info for next, time but also noticed some other tests with similar steps did not fail. Looks spurious. Commit #16: Modify rust-demangler to strip disambiguators by default Commit #17: Remove std::process::exit from coverage tests Due to Issue rust-lang#77553, programs that call std::process::exit() do not generate coverage results on Windows MSVC. Commit #18: fix: test file paths exceeding Windows max path len
richkadel
pushed a commit
that referenced
this pull request
Mar 19, 2021
HWAddressSanitizer support # Motivation Compared to regular ASan, HWASan has a [smaller overhead](https://source.android.com/devices/tech/debug/hwasan). The difference in practice is that HWASan'ed code is more usable, e.g. Android device compiled with HWASan can be used as a daily driver. # Example ``` fn main() { let xs = vec![0, 1, 2, 3]; let _y = unsafe { *xs.as_ptr().offset(4) }; } ``` ``` ==223==ERROR: HWAddressSanitizer: tag-mismatch on address 0xefdeffff0050 at pc 0xaaaad00b3468 READ of size 4 at 0xefdeffff0050 tags: e5/00 (ptr/mem) in thread T0 #0 0xaaaad00b3464 (/root/main+0x53464) #1 0xaaaad00b39b4 (/root/main+0x539b4) #2 0xaaaad00b3dd0 (/root/main+0x53dd0) #3 0xaaaad00b61dc (/root/main+0x561dc) #4 0xaaaad00c0574 (/root/main+0x60574) #5 0xaaaad00b6290 (/root/main+0x56290) #6 0xaaaad00b6170 (/root/main+0x56170) #7 0xaaaad00b3578 (/root/main+0x53578) #8 0xffff81345e70 (/lib64/libc.so.6+0x20e70) #9 0xaaaad0096310 (/root/main+0x36310) [0xefdeffff0040,0xefdeffff0060) is a small allocated heap chunk; size: 32 offset: 16 0xefdeffff0050 is located 0 bytes to the right of 16-byte region [0xefdeffff0040,0xefdeffff0050) allocated here: #0 0xaaaad009bcdc (/root/main+0x3bcdc) #1 0xaaaad00b1eb0 (/root/main+0x51eb0) #2 0xaaaad00b20d4 (/root/main+0x520d4) #3 0xaaaad00b2800 (/root/main+0x52800) #4 0xaaaad00b1cf4 (/root/main+0x51cf4) #5 0xaaaad00b33d4 (/root/main+0x533d4) #6 0xaaaad00b39b4 (/root/main+0x539b4) #7 0xaaaad00b61dc (/root/main+0x561dc) #8 0xaaaad00b3578 (/root/main+0x53578) #9 0xaaaad0096310 (/root/main+0x36310) Thread: T0 0xeffe00002000 stack: [0xffffc0590000,0xffffc0d90000) sz: 8388608 tls: [0xffff81521020,0xffff815217d0) Memory tags around the buggy address (one tag corresponds to 16 bytes): 0xfefcefffef80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xfefcefffef90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xfefcefffefa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xfefcefffefb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xfefcefffefc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xfefcefffefd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xfefcefffefe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xfefcefffeff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0xfefceffff000: a2 a2 05 00 e5 [00] 00 00 00 00 00 00 00 00 00 00 0xfefceffff010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xfefceffff020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xfefceffff030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xfefceffff040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xfefceffff050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xfefceffff060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xfefceffff070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xfefceffff080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Tags for short granules around the buggy address (one tag corresponds to 16 bytes): 0xfefcefffeff0: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. =>0xfefceffff000: .. .. c5 .. .. [..] .. .. .. .. .. .. .. .. .. .. 0xfefceffff010: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. See https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html#short-granules for a description of short granule tags Registers where the failure occurred (pc 0xaaaad00b3468): x0 e500efdeffff0050 x1 0000000000000004 x2 0000ffffc0d8f5a0 x3 0200efff00000000 x4 0000ffffc0d8f4c0 x5 000000000000004f x6 00000ffffc0d8f36 x7 0000efff00000000 x8 e500efdeffff0050 x9 0200efff00000000 x10 0000000000000000 x11 0200efff00000000 x12 0200effe000006b0 x13 0200effe000006b0 x14 0000000000000008 x15 00000000c00000cf x16 0000aaaad00a0afc x17 0000000000000003 x18 0000000000000001 x19 0000ffffc0d8f718 x20 ba00ffffc0d8f7a0 x21 0000aaaad00962e0 x22 0000000000000000 x23 0000000000000000 x24 0000000000000000 x25 0000000000000000 x26 0000000000000000 x27 0000000000000000 x28 0000000000000000 x29 0000ffffc0d8f650 x30 0000aaaad00b3468 ``` # Comments/Caveats * HWASan is only supported on arm64. * I'm not sure if I should add a feature gate or piggyback on the existing one for sanitizers. * HWASan requires `-C target-feature=+tagged-globals`. That flag should probably be set transparently to the user. Not sure how to go about that. # TODO * Need more tests. * Update documentation. * Fix symbolization. * Integrate with CI
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.
No description provided.