update from origin 2020-06-23 #6
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
We can never supply a meaningful implementation of this. Instead, the follow up commits will create two intrinsics that approximate comparisons: * `ptr_maybe_eq` * `ptr_maybe_ne` The fact that `ptr_maybe_eq(a, b)` is not necessarily the same value as `!ptr_maybe_ne(a, b)` is a symptom of this entire problem.
…iplett Document unsafety in slice/sort.rs Let me know if these documentations are accurate c: I don't think I am capable enough to document the safety of `partition_blocks`, however. Related issue #66219
`#[deny(unsafe_op_in_unsafe_fn)]` in liballoc This PR proposes to make use of the new `unsafe_op_in_unsafe_fn` lint, i.e. no longer consider the body of an unsafe function as an unsafe block and require explicit unsafe block to perform unsafe operations. This has been first (partly) suggested by @Mark-Simulacrum in #69245 (comment) Tracking issue for the feature: #71668. ~~Blocked on #71862.~~ r? @Mark-Simulacrum cc @nikomatsakis can you confirm that those changes are desirable? Should I restrict it to only BTree for the moment?
Add asm!() support for hexagon
…anewok save_analysis: improve handling of enum struct variant Fixes #61385
…tion, r=lcnr,varkor ty: projections in `transparent_newtype_field` Fixes #73249. This PR modifies `transparent_newtype_field` so that it handles projections with generic parameters, where `normalize_erasing_regions` would ICE.
Implement crate-level-only lints checking. This implements a crate_level_only flag on lints, and when it is true, it becomes an error when user tries to specify this flag upon nodes other than crate node. This also turns on this flag for all non_ascii_ident lints.
Note numeric literals that can never fit in an expected type re #72380 (comment) Given the toy code ```rust fn is_positive(n: usize) { n > -1_isize; } ``` We currently get a type mismatch error like the following: ``` error[E0308]: mismatched types --> src/main.rs:2:9 | 2 | n > -1_isize; | ^^^^^^^^ expected `usize`, found `isize` | help: you can convert an `isize` to `usize` and panic if the converted value wouldn't fit | 2 | n > (-1_isize).try_into().unwrap(); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``` But clearly, `-1` can never fit into a `usize`, so the suggestion will always panic. A more useful message would tell the user that the value can never fit in the expected type: ``` error[E0308]: mismatched types --> test.rs:2:9 | 2 | n > -1_isize; | ^^^^^^^^ expected `usize`, found `isize` | note: `-1_isize` can never fit into `usize` --> test.rs:2:9 | 2 | n > -1_isize; | ^^^^^^^^ ``` Which is what this commit implements. I only added this check for negative literals because - Currently we can only perform such a check for literals (constant value propagation is outside the scope of the typechecker at this point) - A lint error for out-of-range numeric literals is already emitted IMO it makes more sense to put this check in librustc_lint, but as far as I can tell the typecheck pass happens before the lint pass, so I've added it here. r? @estebank
Use `LocalDefId` for import IDs in trait map cc #73291 (comment)
asm: Allow multiple template string arguments; interpret them as newline-separated Allow the `asm!` macro to accept a series of template arguments, and interpret them as if they were concatenated with a '\n' between them. This allows writing an `asm!` where each line of assembly appears in a separate template string argument. This syntax makes it possible for rustfmt to reliably format and indent each line of assembly, without risking changes to the inside of a template string. It also avoids the complexity of having the user carefully format and indent a multi-line string (including where to put the surrounding quotes), and avoids the extra indentation and lines of a call to `concat!`. For example, rewriting the second example from the [blog post on the new inline assembly syntax](https://blog.rust-lang.org/inside-rust/2020/06/08/new-inline-asm.html) using multiple template strings: ```rust fn main() { let mut bits = [0u8; 64]; for value in 0..=1024u64 { let popcnt; unsafe { asm!( " popcnt {popcnt}, {v}", "2:", " blsi rax, {v}", " jz 1f", " xor {v}, rax", " tzcnt rax, rax", " stosb", " jmp 2b", "1:", v = inout(reg) value => _, popcnt = out(reg) popcnt, out("rax") _, // scratch inout("rdi") bits.as_mut_ptr() => _, ); } println!("bits of {}: {:?}", value, &bits[0..popcnt]); } } ``` Note that all the template strings must appear before all other arguments; you cannot, for instance, provide a series of template strings intermixed with the corresponding operands.
…trochenkov Only display other method receiver candidates if they actually apply Previously, we would suggest `Box<Self>` as a valid receiver, even if method resolution only succeeded due to an autoderef (e.g. to `&self`)
Add specialization of `ToString for char` Closes #73462
Refactor hir::Place For the following code ```rust let c = || bar(foo.x, foo.x) ``` We generate two different `hir::Place`s for both `foo.x`. Handling this adds overhead for analysis we need to do for RFC 2229. We also want to store type information at each Projection to support analysis as part of the RFC. This resembles what we have for `mir::Place` This commit modifies the Place as follows: - Rename to `PlaceWithHirId`, where there `hir_id` is that of the expressioin. - Move any other information that describes the access out to another struct now called `Place`. - Removed `Span`, it can be accessed using the [hir API](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/struct.Map.html#method.span) - Modify `Projection` to be a strucutre of its own, that currently only contains the `ProjectionKind`. Adding type information to projections wil be completed as part of rust-lang/project-rfc-2229#5 Closes rust-lang/project-rfc-2229#3
Replaced dummy values for hash and num_counters with computed values, and refactored InstrumentCoverage pass to simplify injecting more counters per function in upcoming versions. Improved usage documentation and error messaging.
This is to prevent the miscompilation in #73137 from reappearing. Only runs with `-Zvalidate-mir`.
Co-authored-by: Tyler Mandry <[email protected]>
Clean up E0689 explanation r? @Dylan-DPC
…atsakis Account for multiple impl/dyn Trait in return type when suggesting `'_` Make `impl` and `dyn` Trait lifetime suggestions a bit more resilient. Follow up to #72804. r? @nikomatsakis
Add second message for LiveDrop errors This is an attempt to fix #72907 by adding a second message to the `LiveDrop` diagnostics. Changing from this ``` error[E0493]: destructors cannot be evaluated at compile-time --> src/lib.rs:7:9 | 7 | let mut always_returned = None; | ^^^^^^^^^^^^^^^^^^^ constants cannot evaluate destructors error: aborting due to previous error ``` to this ``` error[E0493]: destructors cannot be evaluated at compile-time --> foo.rs:6:9 | 6 | let mut always_returned = None; | ^^^^^^^^^^^^^^^^^^^ constants cannot evaluate destructors ... 10 | always_returned = never_returned; | --------------- value is dropped here error: aborting due to previous error ``` r? @RalfJung @ecstatic-morse
Clarify --extern documentation. Fixes #64731, #73531. See also #64402 (comment)
Fix typos in doc comments Hello 🦀 , This commit fixes typos in the doc comments of 'librustc_mir/monomorphize/collector.rs' Thank you for reviewing this PR 👍
Rollup of 9 pull requests Successful merges: - #72271 (Improve compiler error message for wrong generic parameter order) - #72493 ( move leak-check to during coherence, candidate eval) - #73398 (A way forward for pointer equality in const eval) - #73472 (Clean up E0689 explanation) - #73496 (Account for multiple impl/dyn Trait in return type when suggesting `'_`) - #73515 (Add second message for LiveDrop errors) - #73567 (Clarify --extern documentation.) - #73572 (Fix typos in doc comments) - #73590 (bootstrap: no `config.toml` exists regression) Failed merges: r? @ghost
Thus we avoid propagation of a local the moment we encounter references to it.
Fix a crash when searching for an alias contained in the currently selected filter crate. Also remove alias search results for crates that should be filtered out. The test suite needed to be fixed to actually take into account the crate filtering and check that there are no results when none are expected.
This commit modernizes how rustc checks for whether the `atomics` feature is enabled for the wasm target. The `sess.target_features` set is consulted instead of fiddling around with dealing with various aspects of LLVM and that syntax.
rustdoc: Fix doc aliases with crate filtering Fix a crash when searching for an alias contained in the currently selected filter crate. Also remove alias search results for crates that should be filtered out. The test suite needed to be fixed to actually take into account the crate filtering and check that there are no results when none are expected. Needs to be backported to beta to fix the `std` docs. Fixes #73620 r? @GuillaumeGomez
Mention that BTreeMap::new() doesn't allocate I think it would be nice to mention this, so you don't have to dig through the src to look at the definition of new().
…ndry Check for assignments between non-conflicting generator saved locals This is to prevent future changes to the generator transform from reintroducing the problem that caused #73137. Namely, a store between two generator saved locals whose storage does not conflict. My ultimate goal is to introduce a modified version of #71956 that handles this case properly. r? @tmandry
code coverage foundation for hash and num_counters This PR is the next iteration after PR #73011 (which is still waiting on bors to merge). @wesleywiser - PTAL r? @tmandry (FYI, I'm also working on injecting the coverage maps, in another branch, while waiting for these to merge.) Thanks!
Fix -Z unpretty=everybody_loops
It turns out that this has not been working for who knows how long.
Previously:
```
pub fn h() { 1 + 2; }
```
After this change:
```
pub fn h() { loop { } }
```
This only affected the pass when run with the command line
pretty-printing option, so rustdoc was still replacing bodies with
`loop {}`.
…henkov Move remaining `NodeId` APIs from `Definitions` to `Resolver` Implements #73291 (comment) TL;DR: it moves all fields that are only needed during name resolution passes into the `Resolver` and keep the rest in `Definitions`. This effectively enforces that all references to `NodeId`s are gone once HIR lowering is completed. After this, the only remaining work for #50928 should be to adjust the dev guide. r? @petrochenkov
…static-morse Point at the call span when overflow occurs during monomorphization This improves the output for issue #72577, but there's still more work to be done. Currently, an overflow error during monomorphization results in an error that points at the function we were unable to monomorphize. However, we don't point at the call that caused the monomorphization to happen. In the overflow occurs in a large recursive function, it may be difficult to determine where the issue is. This commit tracks and `Span` information during collection of `MonoItem`s, which is used when emitting an overflow error. `MonoItem` itself is unchanged, so this only affects `src/librustc_mir/monomorphize/collector.rs`
The const propagator cannot trace references. Thus we avoid propagation of a local the moment we encounter references to it. fixes #73609 cc @RalfJung r? @wesleywiser
fix `intrinsics::needs_drop` docs
Provide context on E0308 involving fn items Fix #73487.
…davidtwco rustc: Modernize wasm checks for atomics This commit modernizes how rustc checks for whether the `atomics` feature is enabled for the wasm target. The `sess.target_features` set is consulted instead of fiddling around with dealing with various aspects of LLVM and that syntax.
Rollup of 11 pull requests Successful merges: - #72780 (Enforce doc alias check) - #72876 (Mention that BTreeMap::new() doesn't allocate) - #73244 (Check for assignments between non-conflicting generator saved locals) - #73488 (code coverage foundation for hash and num_counters) - #73523 (Fix -Z unpretty=everybody_loops) - #73587 (Move remaining `NodeId` APIs from `Definitions` to `Resolver`) - #73601 (Point at the call span when overflow occurs during monomorphization) - #73613 (The const propagator cannot trace references.) - #73614 (fix `intrinsics::needs_drop` docs) - #73630 (Provide context on E0308 involving fn items) - #73665 (rustc: Modernize wasm checks for atomics) Failed merges: r? @ghost
…etrochenkov Always capture tokens for `macro_rules!` arguments When we invoke a proc-macro, the `TokenStream` we pass to it may contain 'interpolated' AST fragments, represented by `rustc_ast::token::Nonterminal`. In order to correctly, pass a `Nonterminal` to a proc-macro, we need to have 'captured' its `TokenStream` at the time the AST was parsed. Currently, we perform this capturing when attributes are present on items and expressions, since we will end up using a `Nonterminal` to pass the item/expr to any proc-macro attributes it is annotated with. However, `Nonterminal`s are also introduced by the expansion of metavariables in `macro_rules!` macros. Since these metavariables may be passed to proc-macros, we need to have tokens available to avoid the need to pretty-print and reparse (see #43081). This PR unconditionally performs token capturing for AST items and expressions that are passed to a `macro_rules!` invocation. We cannot know in advance if captured item/expr will be passed to proc-macro, so this is needed to ensure that tokens will always be available when they are needed. This ensures that proc-macros will receive tokens with proper `Spans` (both location and hygiene) in more cases. Like all work on #43081, this will cause regressions in proc-macros that were relying on receiving tokens with dummy spans. In this case, Crater revealed only one regression: the [Pear](https://github.com/SergioBenitez/Pear) crate (a helper for [rocket](https://github.com/SergioBenitez/Rocket)), which was previously [fixed](SergioBenitez/Pear#25) as part of #73084. This regression manifests itself as the following error: ``` [INFO] [stdout] error: proc macro panicked [INFO] [stdout] --> /opt/rustwide/cargo-home/registry/src/github.com-1ecc6299db9ec823/rocket_http-0.4.5/src/parse/uri/parser.rs:119:34 [INFO] [stdout] | [INFO] [stdout] 119 | let path_and_query = pear_try!(path_and_query(is_pchar)); [INFO] [stdout] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [INFO] [stdout] | [INFO] [stdout] = help: message: called `Option::unwrap()` on a `None` value [INFO] [stdout] = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info) ``` It can be fixed by running `cargo update -p pear`, which updates your `Cargo.lock` to use the latest version of Pear (which includes a bugfix for the regression). Split out from #73084
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
Nov 29, 2020
Don't run `resolve_vars_if_possible` in `normalize_erasing_regions` Neither `@eddyb` nor I could figure out what this was for. I changed it to `assert_eq!(normalized_value, infcx.resolve_vars_if_possible(&normalized_value));` and it passed the UI test suite. <details><summary> Outdated, I figured out the issue - `needs_infer()` needs to come _after_ erasing the lifetimes </summary> Strangely, if I change it to `assert!(!normalized_value.needs_infer())` it panics almost immediately: ``` query stack during panic: #0 [normalize_generic_arg_after_erasing_regions] normalizing `<str::IsWhitespace as str::pattern::Pattern>::Searcher` #1 [needs_drop_raw] computing whether `str::iter::Split<str::IsWhitespace>` needs drop #2 [mir_built] building MIR for `str::<impl str>::split_whitespace` #3 [unsafety_check_result] unsafety-checking `str::<impl str>::split_whitespace` #4 [mir_const] processing MIR for `str::<impl str>::split_whitespace` #5 [mir_promoted] processing `str::<impl str>::split_whitespace` #6 [mir_borrowck] borrow-checking `str::<impl str>::split_whitespace` #7 [analysis] running analysis passes on this crate end of query stack ``` I'm not entirely sure what's going on - maybe the two disagree? </details> For context, this came up while reviewing rust-lang#77467 (cc `@lcnr).` Possibly this needs a crater run? r? `@nikomatsakis` cc `@matthewjasper`
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
richkadel
pushed a commit
that referenced
this pull request
Mar 19, 2021
New lint: option_manual_map fixes: #6 changelog: Added lint: `match_map`
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.