Remove modes from libstd and libcore at least, enable deprecated mode warning by default #3323
Comments
ghost
assigned 
|
Some other components of this bug:
|
|
why not have main's optional arguments be |
|
One benefit of a sys::get_argv is that it reduces the "public static void main(String[] args)" factor. |
|
I prefer to keep the main argv signature, mostly because sometimes it's useful to call main manually, and not having an argv in the signature means involving global runtime state. For example, the jit is currently tested by building crates and calling main. |
|
I agree with @brson. We were discussing this the other day and I remembered how much I dislike how Python does it. I always end up making a |
|
Current status: |
|
Still warnings from (in |
|
I'm closing this because we've done all we're going to do for 0.4; the ones I mentioned in my previous comment have been muted. |
Fix the bugs of `manual_memcpy`, simplify the suggestion and refactor it While I’m working on the long procrastinated work to expand `manual_memcpy`(rust-lang#1670), I found a few minor bugs and probably unidiomatic or old coding style. There is a brief explanation of changes to the behaviour this PR will make below. And, I have a questoin: do I need to add tests for the first and second fixed bugs? I thought it might be too rare cases to include the tests for those. I added for the last one though. * Bug fix * It negates resulted offsets (`src/dst_offset`) when `offset` is subtraction by 0. This PR will remove any subtraction by 0 as a part of minification. ```rust for i in 0..5 { dst[i - 0] = src[i]; } ``` ```diff warning: it looks like you're manually copying between slices --> src/main.rs:2:14 | LL | for i in 0..5 { - | ^^^^ help: try replacing the loop by: `dst[..-5].clone_from_slice(&src[..5])` + | ^^^^ help: try replacing the loop by: `dst[..5].clone_from_slice(&src[..5])` | ``` * It prints `RangeTo` or `RangeFull` when both of `end` and `offset` are 0, which have different meaning. This PR will print 0. I could reject the cases `end` is 0, but I thought I won’t catch other cases `reverse_range_loop` will trigger, and it’s over to catch every such cases. ```rust for i in 0..0 { dst[i] = src[i]; } ``` ```diff warning: it looks like you're manually copying between slices --> src/main.rs:2:14 | LL | for i in 0..0 { - | ^^^^ help: try replacing the loop by: `dst.clone_from_slice(&src[..])` + | ^^^^ help: try replacing the loop by: `dst[..0].clone_from_slice(&src[..0])` | ``` * it prints four dots when `end` is `None`. This PR will ignore any `for` loops without `end` because a `for` loop that takes `RangeFrom` as its argument and contains indexing without the statements or the expressions that end loops such as `break` will definitely panic, and `manual_memcpy` should ignore the loops with such control flow. ```rust fn manual_copy(src: &[u32], dst: &mut [u32]) { for i in 0.. { dst[i] = src[i]; } } ``` ```diff -warning: it looks like you're manually copying between slices - --> src/main.rs:2:14 - | -LL | for i in 0.. { - | ^^^ help: try replacing the loop by: `dst[....].clone_from_slice(&src[....])` - | ``` * Simplification of the suggestion * It prints 0 when `start` or `end` and `offset` are same (from rust-lang#3323). This PR will use `RangeTo` changelog: fixed the bugs of `manual_memcpy` and also simplify the suggestion.
silence testing on the failure repo until it's fixed
This PR fixes inadvertently exposing some of the unstable Kani intrinsics. By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.
No description provided.
The text was updated successfully, but these errors were encountered: