profile
viewpoint
scottmcm Pacific Northwest, USA This is a personal account. My actions and opinions are my own, and are not taken on behalf of my employer.

scottmcm/rev_slice 3

A simple alternative to negative indexing on rust slices

scottmcm/pawn-rs 1

An unchecked borrow-like operation for Cells.

scottmcm/rust 1

A safe, concurrent, practical language.

scottmcm/compiler-builtins 0

Porting `compiler-rt` intrinsics to Rust

scottmcm/edition-guide 0

A guide to changes between various editions of Rust

scottmcm/jpeg-decoder 0

JPEG decoder written in Rust

scottmcm/miri 0

An interpreter for Rust's mid-level intermediate representation

scottmcm/multipart 0

A backend-agnostic extension for file uploads in HTTP libraries for Rust

pull request commentrust-lang/rust

Remove "unnecessary `unsafe` block in `unsafe` fn" lint

@rfcbot reviewed

I'm not certain that it's always the best choice to require an unsafe block to call unsafe functions from an unsafe function, but the plan is still linting, so I'm good with the proposed plan.

(I do also think the swap-the-warnings plan sounds interesting.)

LeSeulArtichaut

comment created time in 15 hours

pull request commentrust-lang/rust

Permit attributes on 'if' expressions

@rfcbot reviewed

I don't have a complaint about this situation in particular, but do wonder about philosophy around attributes here. @Centril mentioned in the meeting that it's expressions in certain context that can allow attributes; I'd like a page in the reference or something about why particular things can or cannot have attributes. For example, the following currently doesn't work:

let x = #[cfg(true)] 4 #[cfg(not(true))] 5;

But in some sense there isn't a reason that it couldn't be made to work, since either way is a valid expression for the RHS of the binding.

So I'd just like a definition somewhere about why it's the right thing to do on an if expression, but not on a literal expression. (Sorry if it already exists somewhere, but I didn't see an answer in the OP, in the RFC proposal comment, or in skimming the thread.)

Aaron1011

comment created time in 15 hours

issue openedrust-lang/rust-clippy

New lint: inspect-then-for_each on iterators should be simplified

Inspired by the change made in https://github.com/rust-lang/rust/pull/69022/files#diff-d1ff3aad2daeb77432493d91c41b722bL147

When an inspect is followed by for_each, that's the same as just doing the thing in the inspect at the beginning of the closure in the for_each.

It's possible that this should only be suggested when a brace-bodied closure is already being passed to for_each, like

    .inspect(|x| do_something(x, 2))
    .for_each(|x| {
        do_more(x);
        update_something(x);
    });

which can just be

    .for_each(|x| {
        do_something(x, 2);
        do_more(x);
        update_something(x);
    });

But not for something like .inspect(foo).for_each(bar), where it's not obvious that the closure is better. (It's not bad, but not an obvious improvement.)

created time in 8 days

pull request commentrust-lang/rust

mem::zeroed/uninit: panic on types that do not permit zero-initialization

Thanks for the awesome regression list, @RalfJung! Helping people spot UB sounds great.

@rfcbot reviewed

RalfJung

comment created time in 8 days

issue commentrust-lang/rust

Add `with_exact_size` and `with_size_hint` to `Iterator`

size_hint is pretty situational, and it turns out that it's half-unused anyway. And while .with_exact_size(n) is of course safe, it's also really easy to get into a garbage-in-garbage-out situation with because an iterator doesn't need to work if the size_hint is wrong -- which is easy to happen if you do something like "the predicate in my filter is almost always true so I'll just hint that it's the same size as the input". Additionally, SizeHint<I> cannot propagate TrustedLen, so something like (0..100).with_exact_size(100) looks like you're being helpful but actually makes things worse.

So I've been more and more thinking that what's really needed is a different iterator API that's allowed to be wrong, but where being wrong just over- or under-allocates, rather than permitting incorrect behaviour. Then things like ResultShunt can say "you should allocate enough for everything", even though it might return fewer things if there's an Err. And if it's just one number, it could just be usize::saturating_added for Chain or whatever, rather than the current more-complicated dance. It has a useful default implementation of self.size_hint().0 as well, so we could move collect to using it immediately without regressing third-party iterators.

(I also still like .collect_into(Vec::with_capacity(100)), or similar, from https://github.com/rust-lang/rust/issues/45840.)

LukasKalbertodt

comment created time in 8 days

pull request commentrust-lang/rust

Rename asm! to llvm_asm!

Giving a more-explicit name to something not planned to be stabilized sounds like a :+1: to me.

Amanieu

comment created time in 8 days

pull request commentrust-lang/rust

Make integer exponentiation methods unstably const

I have no horse in this race; I added it because I was asked to do so by @kennytm in https://github.com/rust-lang/rust/pull/45754#issuecomment-341884683

AFAIK that's just a matter of "use fewer #[rustc*] things where possible, so if it's not possible in this case and T-compiler is fine with it, I'm fine with it.

ecstatic-morse

comment created time in 8 days

issue commentrust-lang/rust

PartialEq implementation for RangeInclusive is unsound

And there's an open PR to redesign the Step trait, which will break all that code anyway.

xfix

comment created time in 24 days

pull request commentrust-lang/blog.rust-lang.org

Justify text in paragraphs

Thanks for the demo, @pietroalbini!

Unfortunately the first paragraph I looked at ended up with more hyphens than I'd personally wish to see (though I can see why the layout engine would have picked them): image

pietroalbini

comment created time in a month

issue openedbelluzj/fantasque-sans

Please add a version without ligatures

One of the reasons I liked this font was the lack of them.

You've mentioned you would in https://github.com/belluzj/fantasque-sans/issues/64#issuecomment-555420273; I just wanted an issue to follow to track it. (And hopefully for others to 👍.)

created time in a month

pull request commentrust-lang/rfcs

Deprecate stdlib modules dedicated to numeric constants and move those constants to associated consts

What happens in the docs when something is future-deprecated? If the flag in the docs pointing to the suggested version is there regardless, maybe we mark them as deprecated in 2.0 so no warnings happen?

bstrie

comment created time in a month

pull request commentrust-lang/rust

permit negative impls for non-auto traits

I'm happy to see this. Previous discussion:

https://internals.rust-lang.org/t/pondering-negative-trait-promises/8265?u=scottmcm

@rfcbot reviewed

nikomatsakis

comment created time in a month

issue commentrust-lang/rust

ICE with mir-opt-level=2: store_with_flags: invalid ScalarPair layout

cc @Centril

Before (beta):

    bb3: {
        StorageLive(_4);                 // bb3[0]: scope 1 at ./example.rs:13:18: 13:19
        _4 = ((_1 as Foo).0: u8);        // bb3[1]: scope 1 at ./example.rs:13:18: 13:19
        StorageLive(_5);                 // bb3[2]: scope 3 at ./example.rs:13:33: 13:34
        _5 = _4;                         // bb3[3]: scope 3 at ./example.rs:13:33: 13:34
        ((_2 as Foo).0: u8) = move _5;   // bb3[4]: scope 3 at ./example.rs:13:24: 13:35
        discriminant(_2) = 0;            // bb3[5]: scope 3 at ./example.rs:13:24: 13:35
        StorageDead(_5);                 // bb3[6]: scope 3 at ./example.rs:13:34: 13:35
        StorageDead(_4);                 // bb3[7]: scope 1 at ./example.rs:13:35: 13:36
        goto -> bb4;                     // bb3[8]: scope 1 at ./example.rs:12:18: 15:6
    }

After (nightly):

    bb3: {
        _2 = move _1;                    // bb3[0]: scope 1 at ./example.rs:13:18: 13:19
        goto -> bb4;                     // bb3[1]: scope 1 at ./example.rs:12:18: 15:6
    }

Where the types are

    let _1: Src as UserTypeProjection { base: UserType(0), projs: [] }; // in scope 0 at ./example.rs:11:9: 11:10
    let mut _2: Dst;                     // in scope 0 at ./example.rs:12:18: 15:6
bytwise

comment created time in 3 months

issue openedrust-lang/rust

[MIR-opt] trivial matches aren't optimized out at mir-opt-level=1

I got excited by and went to try out SimplifyArmIdentity+SimplifyBranchSame from https://github.com/rust-lang/rust/pull/66282, but was surprised that the first thing I attempted didn't actually get optimized away as I'd expected.

pub fn demo(x: Result<u32, i32>) -> Result<u32, i32> {
    match x {
        Ok(v) => Ok(v),
        Err(e) => Err(e),
    }
}

Repro: https://rust.godbolt.org/z/bxFAsP

It does, however, optimize away in MIR with -Z mir-opt-level=2.

(Note that this is the simple case without ?, where there are no function calls involved so inlining should be irrelevant.)

Seems like there's a gap here? cc @Centril @oli-obk @wesleywiser

Some guesses from the discord conversation where centril asked me to open this issue: the Storage{Live|Dead} presence, extra copies because [ui]32, const prop hiding something, ...

created time in 3 months

pull request commentrust-lang/rust

Add core::{f32,f64}::consts::TAU.

Confirm that these numeric values are accurate. I did not do any validation other than eyeballing the numbers.

Because of floating point, I would expect 2.0 * PI to be perfectly accurate for this at all times, since it's just an exponent adjustment. Should it just be implemented that way to avoid the question?

m-ou-se

comment created time in 3 months

pull request commentrust-lang/rust

Change unused_labels from allow to warn

This is just a lint, though, @BartMassey, so cap-lints should mean that it's not a problem.

I think it's fine to just have it go in; it'll be weeks before it affects stable and it's trivial to fix on their side. (Not to mention that if it's waiting on an FCP that gives them at least 10 days before it affects nightly.)

BartMassey

comment created time in 3 months

issue commentrust-lang/rust

Rust shouldn't warn about snake case in patterns

@jumbatm We definitely want to warn on the struct definition. My understanding is that we don't want to warn on the binding when you didn't actually write the binding ("for field puns"). So we don't warn on Foo { iHateSnakes } but would warn on Foo { iHateSnakes: iHateSnakes } (and definitely on Foo { i_hate_snakes: iHateSnakes }).

Timmmm

comment created time in 3 months

pull request commentrust-lang/rust

Add a total ordering method for floating-point

@icefoxen Please do!

scottmcm

comment created time in 3 months

pull request commentrust-lang/rust

Add `ExactSizeIterator` impl for `iter::Chain`

This affects far more than just what's mentioned here. There are a bunch of implementations that rely on DEI+ESI to be able to correctly propagate DEI (because of things like rposition) that this would also break, such as https://doc.rust-lang.org/std/iter/struct.Zip.html#impl-DoubleEndedIterator

Also, this PR doesn't maintain the requirement from the ESI docs that

the implementation of size_hint must return the exact size of the iterator.

So I'm skeptical. It sounds like the actual proposed change here is essentially to change ESI's requirements to those of TrustedLen, just without the unsafe part and with a len method that does .size_hint().1.unwrap()?

I feel like there's a big difference between methods that can panic because they need to iterate (because anything can be .map(|_| panic!())) and methods that look like accessors but which can panic.

LukasKalbertodt

comment created time in 3 months

pull request commentrust-lang/rust

Change unused_labels from allow to warn

Definitely sounds like a good thing to have, and should clearly be warn-by-default like the others.

Should it be deny-by-default temporarily for the crater check run?

BartMassey

comment created time in 3 months

issue commentrust-lang/rust

discussion/tracking issue for `#[must_use]` functions in the standard library

No need for a clippy lint; it already exists in rustc: https://doc.rust-lang.org/rustc/lints/listing/allowed-by-default.html#unused-results

zackmdavis

comment created time in 3 months

issue commentrust-lang/rust

Rust shouldn't warn about snake case in patterns

Direct repro link: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=f1197162b57e77fff49f0e9536aa6366

Current warning:

warning: variable `iHateSnakes` should have a snake case name
  --> src/main.rs:10:26
   |
10 |         Animal::Spider { iHateSnakes } => dbg!(iHateSnakes),
   |                          ^^^^^^^^^^^ help: convert the identifier to snake case: `i_hate_snakes`
   |
   = note: `#[warn(non_snake_case)]` on by default

Seems like a diagnostics fix to change the help to

help: convert the identifier to snake case: `iHateSnakes: i_hate_snakes`
Timmmm

comment created time in 3 months

pull request commentrust-lang/rust

proposal for BTreeMap/Set min/max, #62924

These seems plausible and the implementations look fine. I think it's ok for them to get checked in, and then libs can decide later if they're worth stabilizing or should be removed.

@bors r+

ssomers

comment created time in 4 months

pull request commentrust-lang/rust

Return early from a MIR `Visitor`

There's a long-standing issue that destructing-and-rebuilding a Result isn't a nop: https://rust.godbolt.org/z/map4wQ. That's the core problem behind runtime cost of ?, IIRC.

I'm not sure if there's a tweak to the desugaring or Try trait that we could do to improve it.

ecstatic-morse

comment created time in 4 months

issue commentrust-lang/rust

Tracking issue for RFC 2203, "Constants in array repeat expressions"

I'm concerned about semver implications here. It seems like it would be bad if adding Copy to the type returned from foo could change what happens in things like [foo(); 4].

Centril

comment created time in 4 months

pull request commentrust-lang/rfcs

RFC: Add method Result::into_ok

I think it might be better to call it something that doesn't start with unwrap.

I'm torn on this one, @remram44. I agree with you, but .unwrap_or(0) and friends have already set a precedent that the word unwrap by itself doesn't mean "can panic".

mzabaluev

comment created time in 4 months

issue commentrust-lang/rust-clippy

New lint: `*const T as *mut T` is Undefined Behavior

I think this would be better phrased as a lint for casting something when there's a method that just gives you what you want. The cast here isn't UB, but I agree that you shouldn't be doing .as_ptr() as *mut T -- but nor should you be doing .as_mut_ptr() as *const T.

Shnatsel

comment created time in 4 months

issue commentrust-lang/rust

Warn that `*const T as *mut T` is Undefined Behavior

Note that it's not UB to do this cast. This cast can be a contributing factor to code that's unsound (like https://blog.rust-lang.org/2017/02/09/Rust-1.15.1.html), but it's important not to say that the cast by itself is UB.

Shnatsel

comment created time in 4 months

pull request commentrust-lang/rust

Stabilize `!` in Rust 1.41.0

@withoutboats the problem is things like the following, that seem like they ought to work, but don't

pub fn demo() -> impl std::error::Error {
    unimplemented!()
}

(Since there's impl Error for ! but not for ().)

@cramertj Post history says I signed-off 3 weeks ago. Is there some metadata somewhere I need to poke?

Centril

comment created time in 4 months

pull request commentrust-lang/rfcs

Propose implicit named arguments for formatting macros

I like the restriction to simple idents here. With struct field init shorthand I often just make local variables for everything; I could easily see myself doing the same for formatting.

@rfcbot reviewed

davidhewitt

comment created time in 4 months

Pull request review commentrust-lang/rust

Add future incompatibility lint for `array.into_iter()`

+// run-pass++// If this test fails for you, you might have moved the definition of+// `core::iter::IntoIterator`. If so, please adjust the path in+// `src/librustc_lint/array_into_iter.rs`.++fn main() {+    // Expressions that should trigger the lint+    let array = [1, 2];+    array.into_iter();+    (&array).into_iter();++    [1, 2].into_iter();+    (&[1, 2]).into_iter();

It's not obvious to me that this one is desirable to lint on. Would it be feasible to detect the auto-ref (like in 13) and only trigger the lint when it was involved? (AFAICT this one wouldn't actually be broken by the IntoIterator for arrays.)

That said, I'm fine with linting on this, because it's strange code anyway and I'd rather people change it.

LukasKalbertodt

comment created time in 4 months

pull request commentrust-lang/rust

Add future incompatibility lint for `array.into_iter()`

(My way was a hack; a real lint is a much better plan.)

I think a lint here is definitely valuable. Could even run it on slices as well, since in theory we might want to be able to use unsized locals to have IntoIterator on non-ref [T] some day. And I've not seen anyone argue that .into_iter() is ever better than .iter() in these situations.

LukasKalbertodt

comment created time in 4 months

pull request commentrust-lang/rust

Add `IntoIterator` impl for arrays by value (`for [T; N]`)

I had an idea to use the unstable_name_collisions lint to warn here, but I was only able to get it to work with slices, not arrays:

https://github.com/rust-lang/rust/compare/master...scottmcm:into_iter-warning-via-unstable_name_collisions

I figured I'd post here in case it inspires anyone to pick it up. (I even tried adding a new slice lang item to put the inherent method there, but was unsuccessful.)

LukasKalbertodt

comment created time in 4 months

create barnchscottmcm/rust

branch : into_iter-warning-via-unstable_name_collisions

created branch time in 4 months

pull request commentrust-lang/rust

Stabilize `!` in Rust 1.40.0

An example from discord of why changing the fallback is sometimes important for consistency:

Centril

comment created time in 4 months

push eventscottmcm/rust

Ralf Jung

commit sha a2b2362ce7000bc4e82006979bb34dfc86a9f396

do not reference LLVM for our concurrency memory model

view details

Guanqun Lu

commit sha 63cb2fa1973e1fcff335f858f77496ba2c8d252c

compress the function, remove the assert check.

view details

Ralf Jung

commit sha f36355070e1bb4323a5db7bcb1297d3ed7951992

it's C++20

view details

Mark Rousskov

commit sha fabba8f76491698ea93ee5b71791709075d155ba

Revert "Auto merge of #64823 - cuviper:min-std, r=Mark-Simulacrum" This reverts commit 000d90b11f7be70ffb7812680f7abc6deb52ec88, reversing changes made to 898f36c83cc28d7921a1d7b3605323dc5cfcf533.

view details

Ralf Jung

commit sha 9a0b9c69600946c8c665705df2cec9ed7ce63d71

remove old branch of unwind logic

view details

Ralf Jung

commit sha d6ab45d264d8f6d664838360595d2175e44ef9c2

fix link targets

view details

bors

commit sha 1721c9685b1ee69f1e17b3a8b09145b10fdfbe4a

Auto merge of #65328 - lzutao:bump-rls-rustfmt, r=Xanewok Update rls and rustfmt cc @Xanewok Fixes #65084 Fixes #65085 Suppressed #65311

view details

Ralf Jung

commit sha a1a8f33abbf5ee00e6918246f4525c6e4458225f

update test for nounwind on FFI imports

view details

Ralf Jung

commit sha 63af27f9ea81a71eb4ea9fb076228993f923cebb

also (properly) test nounwind on function definitions

view details

Ralf Jung

commit sha 79c623f1462646da2c480b6b1c662aa9cf8afee7

some typography

view details

Ralf Jung

commit sha a0106527c65310adb642ac4e407622a8eff3f364

fix #[unwind(abort)] for Rust ABIs

view details

Ralf Jung

commit sha df9335120b2bc2ad4c5f619b3173f20958dcd406

test unwind(abort) with Rust ABI

view details

Ralf Jung

commit sha 09d7be39fadf00e0b179bfaef86679fc489e796f

make tests more robust

view details

Adam Perry

commit sha 19f26fafdd6e27847a155a2ba8854c8d4ff61597

Remove the fn pointer #[track_caller] test. The ICE stderr isn't normalizing correctly on some builders.

view details

bors

commit sha 80b861bed17ba2ce001911f78a5316f56466642f

Auto merge of #64873 - popzxc:prettify-test-time, r=wesleywiser Enhance report-time option ## Short overview This PR is a follow-up to a previously closed #64714 PR. ## Changes introduced by this PR * `libtest` now retrieves the type of the test within `TestDesc` (available types are: `UnitTest`, `IntegrationTest`, `DocTest`, `Unknown`). * `--report-time` subcommand of the `libtest` now supports colored output (disabled by default). * Colorized output depends on the threshold values. Default values (proposed by @wesleywiser): - For unit-tests: 50ms warn/100ms critical, - For integration-tests: 500ms warn/1000ms critical, - For doctests: same as for integration tests, - For unknown tests: `TEST_WARN_TIMEOUT_S` warn/ `TEST_WARN_TIMEOUT_S * 2` critical (it will only applied single-threaded mode, because otherwise test will be interrupted after reaching `TEST_WARN_TIMEOUT_S`). - These values can be overrided by setting environment variables (since those thresholds are somewhat constant for every project, it's more flexible to use environment variables than command line arguments). * New optional flag `--ensure-test-time` for `libtest`. With this flag applied, exectuion time limit excesss will cause test failure. ## What have not been done There was a comment that it would be nice to have an entry in the Cargo book about it. However, changes introduced by this PR (and #64663 in which `report-time` flag was added) aren't related directly to `cargo`, it's more about `libtest` itself. I'm considering that [The Unstable Book](https://doc.rust-lang.org/unstable-book/) is more appropriate place, but not sure if I'm right (and if so, how exactly it should be described). As one possible option, this PR may be merged without denoting it in the documentation, and in the next PR adding support of this feature to the `cargo` itself, I'll add a note in the Cargo book. ## Scope of this PR Logical scope of this PR is `libtest` only. However, to get test types, I had to modify also `libsyntax_ext` and `librustdoc` for them to provide information about test type. ## Rationale Rationale for colored output was submitted in #64714 Providing the information about kind of test was also proposed in #64714, and as an additional benefit this information may be useful for the tools using `libtest` (e.g. `cargo`). Adding flag to treat time limits excess seems logical to me, so projects that do care about test execution time won't have to invent a wheel. ## Backward compatibility All the changes are completely backward compatible. ## Demo ![rustc_enhanced_time](https://user-images.githubusercontent.com/12111581/65818381-c04f6800-e219-11e9-9875-322463abe24f.gif) r? @wesleywiser

view details

Igor Matuszewski

commit sha 429fc9d7b714feebeb78893f9b92b7bdab3b8b93

Test an assoc. type in struct member def inside fn

view details

Igor Matuszewski

commit sha 7b3cd1b674eb7aa7da8fe00192404e4c9f254ad8

Use empty typeck tables when nesting on items without those

view details

Igor Matuszewski

commit sha eefc1697c5d3ba52c2af46994ed158e4457171b8

Nest typeck tables when processing struct member types

view details

bors

commit sha 3da6836cc9fd654fa204fe7e113973f7b5b3e5f6

Auto merge of #65099 - pnkfelix:issue-63154-needed-more-normalize, r=nagisa MIR typeck needed more normalize Add some missing normalization calls (@nagisa [was right](https://github.com/rust-lang/rust/issues/63154#issuecomment-517305589)). Fix #63154

view details

Mazdak Farrokhzad

commit sha 9f09387f53792740edcb5dd0eea49ab02d3fe891

syntax: simplify maybe_annotate_with_ascription

view details

push time in 4 months

issue commentrust-lang/rust

Tracking issue for `#![feature(maybe_uninit_ref)]`

@rfcbot reviewed

I like the functionality, and I'm happy with whatever names people agree on for things here.

Centril

comment created time in 4 months

startedrust-secure-code/safety-dance

started time in 4 months

issue openedrust-lang/crater

Consider making "Cannot allocate memory (os error 12)" spurious

For example, in https://crater-reports.s3.amazonaws.com/pr-65819/index.html, the one "fixed" crate previously failed to build due to

error: failed to write /opt/rustwide/target/debug/deps/rmetayDXmBQ/rust.metadata.bin: Cannot allocate memory (os error 12)

https://crater-reports.s3.amazonaws.com/pr-65819/master%2323f890f10202a71168c6424da0cdf94135d3c40c/reg/oxcc-nucleo-f767zi-0.1.1/log.txt

created time in 4 months

issue commentmackwic/colored

Update crates.io?

@mackwic It would also be nice to get a new version out that includes #67 because that fixes the error that just showed up in crater:

[INFO] [stderr] error[E0308]: mismatched types
[INFO] [stderr]   --> src/style.rs:76:23
[INFO] [stderr]    |
[INFO] [stderr] 76 |             .filter(|&&(ref mask, _)| (0 != (u & mask)))
[INFO] [stderr]    |                       ^^^^^^^^^^^^^^ expected tuple, found reference
[INFO] [stderr]    |
[INFO] [stderr]    = note: expected type `(u8, style::Styles)`
[INFO] [stderr]               found type `&_`
[INFO] [stderr] 
[INFO] [stderr] error[E0308]: mismatched types
[INFO] [stderr]   --> src/style.rs:77:19
[INFO] [stderr]    |
[INFO] [stderr] 77 |             .map(|&(_, value)| value)
[INFO] [stderr]    |                   ^^^^^^^^^^^ expected tuple, found reference
[INFO] [stderr]    |
[INFO] [stderr]    = note: expected type `(u8, style::Styles)`
[INFO] [stderr]               found type `&_`

https://crater-reports.s3.amazonaws.com/pr-65819/try%23b34fa46cc6fa5d46c6adcb041ebd28c7f7a374f3/reg/colored-1.8.0/log.txt

jsgf

comment created time in 4 months

pull request commentkaksmet/jpeg-decoder

fix clippy::into_iter_on_array error in decoder

CI failure doesn't look like the fault of this change:

failed to parse manifest at /home/travis/.cargo/registry/src/github.com-1ecc6299db9ec823/cfg-if-0.1.10/Cargo.toml

scottmcm

comment created time in 4 months

PullRequestEvent

PR closed kaksmet/jpeg-decoder

fix clippy::into_iter_on_array error in decoder

Rust is trying to add IntoIterator for arrays, which would break this. So might as well do it the way that's forward-compatible and also shorter.

+1 -1

0 comment

1 changed file

scottmcm

pr closed time in 4 months

PR opened kaksmet/jpeg-decoder

fix clippy::into_iter_on_array error in decoder

Rust is trying to add IntoIterator for arrays, which would break this. So might as well do it the way that's forward-compatible and also shorter.

+1 -1

0 comment

1 changed file

pr created time in 4 months

push eventscottmcm/jpeg-decoder

Scott McMurray

commit sha fc0c96206dd8dbc3fc4d0b9a2dddae96188290f0

fix clippy::into_iter_on_array error in decoder

view details

push time in 4 months

push eventscottmcm/jpeg-decoder

Scott McMurray

commit sha b1fecbfcd458577a9e620d8bb3d1163044d9d3ba

fix clippy::into_iter_on_array error in decoder

view details

push time in 4 months

pull request commentrust-lang/rust

Add `IntoIterator` impl for arrays by value (`for [T; N]`)

Lots of regressions, though as a positive clippy is catching at least the first one I saw multiple times (such as https://crater-reports.s3.amazonaws.com/pr-65819/try%23b34fa46cc6fa5d46c6adcb041ebd28c7f7a374f3/reg/cargo-bundle-0.4.0/log.txt):

error: this .into_iter() call is equivalent to .iter() and will not move the array
   --> src\decoder.rs:235:47
    |
235 |                     for (i, &table) in tables.into_iter().enumerate() {
    |                                               ^^^^^^^^^ help: call directly: `iter`
    |
    = note: `#[deny(clippy::into_iter_on_array)]` on by default
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#into_iter_on_array

https://github.com/kaksmet/jpeg-decoder/blob/c8e25252/src/decoder.rs#L235

LukasKalbertodt

comment created time in 4 months

fork scottmcm/jpeg-decoder

JPEG decoder written in Rust

fork in 4 months

issue commentrust-lang/rust

Tracking issue for clamp RFC

On one-sided clamping

Because clamping is inclusive on both sides, one can always just specify the min/max on the left/right to get the one-side-only clamping behaviour. I think that's perfectly acceptable, and arguably better than .clamp((Bound::Unbounded, Inclusive(3.2))) where there isn't a Range* type that fits anyway:

x.clamp(i32::MIN, 10);
x.clamp(-f32::INFINITY, 10.0);

There's no perf loss, as LLVM is trivially abe to optimize the dead side away: https://rust.godbolt.org/z/l_uBLO

Xaeroxe

comment created time in 4 months

pull request commentrust-lang/rust

syntax: ABI-oblivious grammar

(showing up because of team ping) :+1: to having "C" vs "D" be a semantic error not a syntax one.

Centril

comment created time in 4 months

issue commentrust-lang/rfcs

Add impl TryFrom<T> for E where E is a C-like #[repr(T)] enum

I've certainly seen people ask often how to do this in chat, so it does seem like a plausible place to do something.

On the other hand, just TryFrom seems weird here. If that exists, I'd also expect a derive for impl From<MyEnum> for u32 here, for example. But that one being derive(From) feels wrong.

So overall I wonder if it's better to just leave this kind of thing to https://docs.rs/enum_derive/0.1.7/enum_derive/ and friends...

canndrew

comment created time in 4 months

pull request commentrust-lang/rust

Add `IntoIterator` impl for arrays by value (`for [T; N]`)

Well, if the queue's empty let's get a check run to find things to go fix.

@bors try

LukasKalbertodt

comment created time in 4 months

issue commentrust-lang/rust

Proposal: add `reject` function to std::iter::Iterator

If anyone wants this, I suggest they just make a PR. This is a small thing that just needs some libs teams eyes on it to see what they think. (I'm personally not a fan of this, and would rather invert whatever's in the closure, but it's not up to me.)

olegnn

comment created time in 4 months

pull request commentrust-lang/rust

Add by-value iterator for arrays

Huzzah! Kudos to everyone working on const generics for getting this to work :heart:

@bors r+

LukasKalbertodt

comment created time in 4 months

issue commentrust-lang/rfcs

Range types for integers (or refinement types?)

Ideally, I'd be able to do let x: int<1, 12> = 7; and it would just work without having to call .into()

Note that this is also true for other things like BigInteger, so to me that argues for a "custom literals" feature, not for "range integers need to be in core".

steveklabnik

comment created time in 4 months

pull request commentrust-lang/rust

More Clippy fixes for alloc, core and std

Thanks, @mati865!

@bors r+ rollup

mati865

comment created time in 4 months

pull request commentrust-lang/rust

Add {String,Vec}::into_raw_parts

Personally I like this -- I always have the same sort of wonders as the things that Ralf was commenting about when I do this, and getting things back in the same order as from_raw_parts is a nice push in the right direction to not accidentally put them back weirdly.

shepmaster

comment created time in 4 months

issue commentrust-lang/rust

Tracking issue for slice_partition_at_index

This isn't C++'s partition, but rather nth_element (https://en.cppreference.com/w/cpp/algorithm/nth_element), right?

If so I think it's an excellent thing to have in the library, especially since the complicated parts of the implementation are things that sort_unstable already needs, to the maintenance cost is low.

(Interestingly, not that this method is actually an answer to an exercise in the book.)

Mokosha

comment created time in 4 months

issue commentrust-lang/rfcs

Safe memset for slices

One curious thing I saw when this came up in Discord: the simple loop will turn into memset for 0_u8 and 0_u16, but not for (0_u8, 0_u16).

I assume that's because the padding is undef, not 0? It makes me wonder if the optimization can be improved to be ok with zero there, or if it implies there's something that would be worth having as a safe API in core to avoid the edge case.

sethjackson

comment created time in 4 months

issue commentrust-lang/rust

Tracking issue for clamp RFC

+1, this went through a full RFC and I don't think there's anything material that's come up since then. For example, NaN handling came up in detail on IRLO and in the RFC discussion.

Xaeroxe

comment created time in 4 months

issue commentrust-lang/rust

Consider using new LLVM intrinsic for i32::saturating_add etc.

That's awesome, @nikic; Thanks!

I particularly like the other forms of it you did; I hadn't even thought about usub.sat.

rkruppe

comment created time in 4 months

pull request commentrust-lang/rust

proposal for BTreeMap/Set min/max, #62924

Hmm, get vs get_key_value definitely makes this awkward to decide.

Slightly crazy idea: first_entry() -> Option<OccupiedEntry<K, V>>. Then you can even use remove_entry() on it to remove the first pair without needing to copy the key to be able to use it to lookup the item again in order to remove it. (Though it has the obvious downside of needing &mut.)

ssomers

comment created time in 4 months

pull request commentrust-lang/rust

Redesign the std::iter::Step trait

This means that this PR now has the observable effect of changing RangeFrom's behavior when overflowing (which is explicitly called out as unspecified and able to change)

While that's allowed to be changed, I'd request that this PR not change any observable behaviour on stable in order to reduce the sign-offs it needs to go through. I'm willing to sign-off on a Step redesign, but I think changing visible behaviour ought to be decided more officially by someone on libs. (That statement is a procedural one, not me taking a stance on whether the change is good.)

CAD97

comment created time in 4 months

Pull request review commentrust-lang/rust

More Clippy fixes for alloc, core and std

 impl<T> Option<T> {     #[inline]     #[stable(feature = "option_entry", since = "1.20.0")]     pub fn get_or_insert_with<F: FnOnce() -> T>(&mut self, f: F) -> &mut T {-        match *self {-            None => *self = Some(f()),-            _ => (),+        if let None = *self {+            *self = Some(f())

nit: can you put a semicolon after the assignment? I think of an elseless if as a statement, not a unit expression.

mati865

comment created time in 4 months

Pull request review commentrust-lang/rust

More Clippy fixes for alloc, core and std

 pub fn park() {     }     loop {         m = thread.inner.cvar.wait(m).unwrap();-        match thread.inner.state.compare_exchange(NOTIFIED, EMPTY, SeqCst, SeqCst) {-            Ok(_) => return, // got a notification-            Err(_) => {} // spurious wakeup, go back to sleep++        // Return notification or do nothing on spurious notifications+        if let Ok(_) = thread.inner.state.compare_exchange(NOTIFIED, EMPTY, SeqCst, SeqCst) {+            return;

How about keeping the if, but still having the two comments? Maybe keep "got a notification" before the return, and move "spurious wakeup, go back to sleep" to the end of the block?

mati865

comment created time in 4 months

issue commentrust-lang/rust

why havn't implemented Error trait for std::option::NoneError ?

I agree about the error message. I think one thing we missed in the Try trait design discussion was what the errors for mixing should look like -- right now you get the note about NoneError, but with the other possible design you would have explicitly gotten something about Result: Try<Option>.

ZhangHanDong

comment created time in 4 months

issue commentrust-lang/rust

Request: A way to collect a `String` from an `impl Iterator<item=u8>`

and then separately trying to convert that into a String (allocation 2)

With https://doc.rust-lang.org/std/string/struct.String.html#method.from_utf8 that's not a separate allocation, though?

Lokathor

comment created time in 4 months

issue commentrust-lang/rust

array impls <= 32 1.39 regression

cc PR https://github.com/rust-lang/rust/pull/62435

[INFO] [stderr]   the trait `std::array::LengthAtMost32` is not implemented for `[i8; 128]`
[INFO] [stderr]   |
[INFO] [stderr]   = note: required because of the requirements on the impl of `std::fmt::Debug` for `[i8; 128]`
[INFO] [stderr]   = note: required because of the requirements on the impl of `std::fmt::Debug` for `&[i8; 128]`
[INFO] [stderr]   = note: required for the cast to the object type `dyn std::fmt::Debug`

I guess this used to unsize to a slice?

Mark-Simulacrum

comment created time in 4 months

issue openedrust-lang/rust

[Edition vNext] Consider deprecating weird nesting of items

For example, do we really want mods inside random function? Similarly, IIRC https://youtu.be/LIYkT3p5gTs mentioned that it's unfortunate for incremental that we allow impls of random things inside functions.

Though at the same time, it's nice to allow all sorts of things for how ?eval bots work on Discord and IRC -- just put all the code inside a block that's passed to println! and it just works.

created time in 4 months

issue openedrust-lang/rust

Tracking issue for vNext edition prelude

There were plans to do this for the 2018 edition, but it never happened (https://github.com/rust-lang/rust/issues/51418, https://github.com/rust-lang/rust/pull/51434)

Things to consider:

  • [ ] TryFrom/TryInto
  • [ ] ???

created time in 4 months

pull request commentrust-lang/rust

Add `core::macros::matches!( $expr, $pat ) -> bool`

Is there an easy way to get data on matches! vs assert_matches!? The latter feels like it doesn't have the problems that centril mentions, as we have assert_eq!(x, y) despite assert!(x == y) existing.

(And, anecdotally, the times I see it mentioned in chat are most often for "I'm trying to test something, but I can't use == Ok(3) because the error type isn't PartialEq" or similar.)

SimonSapin

comment created time in 4 months

pull request commentrust-lang/rust

Stabilize `!` in Rust 1.40.0

despite having a “Redefine core::convert::Infallible as !” commit in this PR

That's a very important point. I think it's essential (https://github.com/rust-lang/rust/pull/49039) that that change happen an concert with stabilizing !, since it's definitely not possible to do in a later release.

Centril

comment created time in 4 months

issue commentbelluzj/fantasque-sans

Differing heights of capitals in VS (due to hinting?)

Yup, looks like the TTF is more consistent here: image

scottmcm

comment created time in 5 months

issue openedbelluzj/fantasque-sans

Differing heights of capitals in VS (due to hinting?)

My VS is currently rendering THING as follows, with the HN seeming shorter than the TIG: image

NN-rescaled of the above, to show that it's 3 pixels different (out of 19): image

Zooming in that stops happening, so I guess it's something about hinting? image

Really minor overall, but it jumped out at me for some reason.

(OTF version 1.7.2, Windows 10)

created time in 5 months

pull request commentrust-lang/rust

Inline `{min,max}_value` even in debug builds

The godbolt example says to me to just stop using max_value(), not to add an attribute.

See also https://github.com/rust-lang/rfcs/pull/2700

lzutao

comment created time in 5 months

issue commentrust-lang/rust

A single method to rotate slices or vecs

You can rotate left or right with either method. s.rotate_left(mid) and s.rotate_right(s.len() - mid) do the same thing. Similarly, s.rotate_right(k) and s.rotate_left(s.len() - k) do the same thing.

If you want to rotate by a signed number, you can rotate by n.rem_euclid(s.len()) as usize.

STPR

comment created time in 5 months

Pull request review commentrust-lang/rust

[WIP] Implement ordered iterators on BinaryHeap as per #59278

 impl<T> ExactSizeIterator for Drain<'_, T> { #[stable(feature = "fused", since = "1.26.0")] impl<T> FusedIterator for Drain<'_, T> {} +/// A draining iterator over the elements of a `BinaryHeap`.+///+/// This `struct` is created by the [`drain_ordered`] method on [`BinaryHeap`]. See its+/// documentation for more.+///+/// [`drain_ordered`]: struct.BinaryHeap.html#method.drain_ordered+/// [`BinaryHeap`]: struct.BinaryHeap.html+#[unstable(feature = "binary_heap_drain_ordered", issue = "59278")]+#[derive(Debug)]+pub struct DrainOrdered<'a, T> {+    inner: &'a mut BinaryHeap<T>,+}++#[unstable(feature = "binary_heap_drain_ordered", issue = "59278")]+impl<'a, T> Drop for DrainOrdered<'a, T> {+    /// Removes heap elements in arbitrary order for efficiency.

That has complexity side-effects I'd consider surprising, though -- I'd hope that .drain().take(k) is O(k lg n), but if they have to drop in order, it'd be O(n lg n).

The BinaryHeap itself drops in arbitrary order, so I don't think it's crazy for drain to also do so. If someone really wants to drop in sorted order, then can always .for_each(drop).

sekineh

comment created time in 5 months

Pull request review commentrust-lang/rust

Implement Clone::clone_from for VecDeque

 impl<T: Clone> Clone for VecDeque<T> {     fn clone(&self) -> VecDeque<T> {         self.iter().cloned().collect()     }++    fn clone_from(&mut self, other: &Self) {+        self.truncate(other.len());++        let mut iter_other = other.iter();+        for (elem, elem_other) in self.iter_mut().zip(&mut iter_other) {+            elem.clone_from(elem_other);+        }

Good point, @bluss. I guess there's an opportunity for improvement in Vec too:

https://github.com/rust-lang/rust/blob/master/src/liballoc/vec.rs#L2027-L2038

(Doesn't need to be this PR, of course.)

crgl

comment created time in 5 months

Pull request review commentrust-lang/rust

Implement Clone::clone_from for VecDeque

 impl<T: Clone> Clone for VecDeque<T> {     fn clone(&self) -> VecDeque<T> {         self.iter().cloned().collect()     }++    fn clone_from(&mut self, other: &Self) {+        self.truncate(other.len());++        let mut iter_other = other.iter();+        for (elem, elem_other) in self.iter_mut().zip(&mut iter_other) {+            elem.clone_from(elem_other);+        }

Instead of zip and such here, could this just be truncate, reserve_exact, the extend on the two parts from other.as_slices()? Or maybe take advantage of an empty VecDeque being O(1) convertible to Vec, and re-use the extend_from_slice optimizations? It would be nice for the memcpy specializations to happen here...

crgl

comment created time in 5 months

issue commentrust-lang/rfcs

Arrays should impl the bitwise operations

If we were to have map and zip and such over arrays in the standard library, would that be sufficient for this? Then you could let z = x.zip_with(y, BitXor::bitxor);, and similar.

canndrew

comment created time in 5 months

pull request commentrust-lang/rust

convert \r\n -> \n in include_str! macro

As a follow-up question: Is there any linting that people would expect here? For example, there could be a lint for inconsistent newlines in include_str!, or clippy ones for any CRLF in them, or...

(Commenting separately from my previous "official" one, since this is just me wondering.)

matklad

comment created time in 5 months

pull request commentrust-lang/rust

convert \r\n -> \n in include_str! macro

Thank you to everyone who commented during the Final Comment Period here. The FCP exists exactly for situations like this, to bring attention to changes and give time for everyone to bring up additional data and concerns that may not have been raised before.

We discussed this in the lang team meeting today, and decided that in light of the situations raised the breakage is more than we're willing to take, so we will not go forward with the change.

@rfcbot fcp cancel

If anyone is interested in this still happening, or otherwise enabling the "does the same thing despite git checkout platform" scenario, one could open an RFC to do this over an edition boundary, add a new macro, do something in the library, or a variety of other possibilities.

matklad

comment created time in 5 months

issue closedrust-lang/rust

BinaryHeap-from-Vec should document that it's non-allocating and O(n)

https://doc.rust-lang.org/beta/std/collections/struct.BinaryHeap.html#impl-From%3CVec%3CT%3E%3E

From the code, this seems to be an allocation-reusing O(n) make_heap, which is a very useful operation, so it would be nice for it to be documented as being such.

closed time in 5 months

scottmcm

issue commentrust-lang/rust

BinaryHeap-from-Vec should document that it's non-allocating and O(n)

Agreed, @sekineh; thanks for commenting!

scottmcm

comment created time in 5 months

issue commentrust-lang/rust

`BinaryHeap` owned iterators should yield items in heap order

Both owning and borrowing versions are useful. I can't return a version that borrows from a local variable, but I can return the version that moves it.

That said, I agree that drop(foo.drain_ordered()); should result in an empty foo. But that can be accomplished by just clearing in the iterator's drop (assuming it's safe so doesn't need to amplify).

jonhoo

comment created time in 5 months

pull request commentrust-lang/rust

use try_fold instead of try_for_each to reduce compile time

I'm happy with this as-is (we can explore other things like https://github.com/rust-lang/rust/pull/64885#discussion_r330256420 in a follow-up PR), so

@bors r+

andjo403

comment created time in 5 months

delete branch scottmcm/rust

delete branch : no-slice-tryfold-unroll

delete time in 5 months

Pull request review commentrust-lang/rust

[WIP] use try_fold instead of try_for_each to reduce compile time

 pub trait Iterator {         Self: Sized, F: FnMut(Self::Item) -> bool     {         #[inline]-        fn check<T>(mut f: impl FnMut(T) -> bool) -> impl FnMut(T) -> LoopState<(), ()> {-            move |x| {+        fn check<T>(mut f: impl FnMut(T) -> bool) -> impl FnMut((), T) -> LoopState<(), ()> {+            move |(), x| {                 if f(x) { LoopState::Continue(()) }                 else { LoopState::Break(()) }             }         }--        self.try_for_each(check(f)) == LoopState::Continue(())+        self.try_fold((), check(f)) == LoopState::Continue(())

I would hope it has no effect, since LoopState<(),()> is an i1 in LLVM...

...and it is in -O, but very different in debug: https://rust.godbolt.org/z/LKOpZ7

Looks like the PartialEq::eq that gets generated is pretty bad, and it's still bad removing then generics: https://rust.godbolt.org/z/o6Nuaw Could there be a "this is a field-less enum so just compare the discriminants" path in the derive? It looks, unfortunately, like as u8 == 1 is the shortest way to do these checks. And we're avoiding the derives in other places too, like

https://github.com/rust-lang/rust/blob/702b45e409495a41afcccbe87a251a692b0cefab/src/libcore/cmp.rs#L632-L638

andjo403

comment created time in 5 months

pull request commentrust-lang/rust

Simplify some `Iterator` methods.

this PR changes documented stable behavior

@andjo403 Note that the try_fold method cannot yet be implemented on stable (because Try) is unstable, so there may still be still options available.

nnethercote

comment created time in 5 months

pull request commentrust-lang/rust

Remove manual unrolling from slice::Iter(Mut)::try_fold

@bluss do you still have r+ here, or do I need to find a different reviewer for this?

scottmcm

comment created time in 5 months

issue commentrust-lang/rust

VecDeque constant time reverse?

"changing the direction of traversal" is called Iterator::rev; I believe an extra flag that would always need to be checked on every operation would be unacceptable as an always-there feature in VecDeque.

For "add an api to VecDeque that Vec has", you can probably just open a PR and get feedback from there from libs. (Though of course reverse is technically on slices, not Vec.)

lopopolo

comment created time in 5 months

pull request commentrust-lang/rust

Support repr(simd) on ADTs containing a single array field

@gnzlbg Now that the FCP's done, can you rebase please?

gnzlbg

comment created time in 5 months

push eventscottmcm/uax

Scott McMurray

commit sha 042a3ef060c42137c833fc944ce477c98dabd910

Move tables to a tables module

view details

Scott McMurray

commit sha f215c3132d2e11069f5916af8edddf0989d235c1

Generate enums for all enumerated properties

view details

Scott McMurray

commit sha 6c4c5a40f5c62ed2e2fe62d32281f838d69099e1

Switch the generated tables to using the new enums

view details

Scott McMurray

commit sha b618da768fa2004e937d51a241be00863bf57b72

Add table for the script property

view details

Scott McMurray

commit sha 8b5ce102e286702e8093554d9907ad8725434cdc

Generate a table for blocks

view details

Scott McMurray

commit sha e6d4cb53196e5387bccd8defd3fdef2d6d287403

Add table for Indic_Positional_Category

view details

Scott McMurray

commit sha 3909789a29748c633a1ba12e8d59f6eeb4e6a53f

Add table for Indic_Syllabic_Category

view details

Scott McMurray

commit sha 6fe4f606a47371f595544aeb2405d691dfbb22b1

Don't need to track the property values anymore

view details

Scott McMurray

commit sha 7a82b89312c0f3bfa5cde1a59b761a40ac0dfa5a

Move the range merging logic to a separate class

view details

push time in 5 months

pull request commentrust-lang/rust

Make the semantics of Vec::truncate(N) consistent with slices.

Marking needs-fcp per https://github.com/rust-lang/rust/pull/64432#issuecomment-531539574

gnzlbg

comment created time in 5 months

issue commenttaiki-e/pin-project

#![feature(overlapping_marker_traits)] breaks the guarantee for Unpin provided by pin-project

The gate for the new behavior is https://doc.rust-lang.org/nightly/unstable-book/language-features/marker-trait-attr.html -- it was implemented in parallel without removing the old feature.

taiki-e

comment created time in 5 months

issue commentrust-lang/rust

Tracking issue for allowing overlapping implementations for marker trait

@Vurich note that the opt-in is the new direction (FCP), so there isn't any reverting needed.

So I think there's a PR opportunity here of removing overlapping_marker_traits (the new one is marker_trait_attr), if anyone's interested in making one.

nikomatsakis

comment created time in 5 months

issue commentrust-lang/rust

Request: add an impl for `f32::try_from(i32)`

There's a bunch of disagreement on what the expected semantics of this implementation would be. See discussion in https://github.com/rust-lang/rfcs/pull/2484

Lokathor

comment created time in 5 months

pull request commentrust-lang/rust

Remove manual unrolling from slice::Iter(Mut)::try_fold

New perf link (thank you, Mark-Simulacrum!) with self-profile results for both sides: https://perf.rust-lang.org/compare.html?start=b4ba2a3953ea9ec28f01c314be315d46673bd782&end=8be3622ad74755484fd9b9e401d0ee96837be244

It looks like nearly all of the speedup for clap-rs-debug run clean is ~2.5s in LLVM_emit_obj (and ~0.3s in LLVM_make_bitcode). Any idea why this would be so much better there? I'd hypothesized that the closure might be getting inlined 5x even in debug, but based on a quick experiment (https://rust.godbolt.org/z/HmYVvd) that doesn't seem to happen. Since this PR still ends up using try_fold (unlike #64572), it doesn't feel like it should have had a major enough impact on the amount of code that's getting sent to LLVM to account for the size of the win.

scottmcm

comment created time in 5 months

pull request commentrust-lang/rust

Remove manual unrolling from slice::Iter(Mut)::try_fold

Oh, interesting. script-servo-opt is new, right? I can't find it in the previous perf comparison...

scottmcm

comment created time in 5 months

pull request commentrust-lang/rust

Remove manual unrolling from slice::Iter(Mut)::try_fold

@bors try @rust-timer queue

(I'm curious to see the new self-profile results, and want to make sure that removing the overrides still keeps the gain here -- it might mean more work to eliminate !s.)

scottmcm

comment created time in 5 months

more