profile
viewpoint
Steve Klabnik steveklabnik Brooklyn http://words.steveklabnik.com/ All i'm trying to do is enjoy every day to the fullest with my Pokémon.

github/opensource.guide 6580

📚 Community guides for open source creators

rust-lang/mdBook 3082

Create book from markdown files. Like Gitbook but implemented in Rust

intermezzOS/kernel 1118

A hobby operating system, in Rust

d-unseductable/ruru 755

Native Ruby extensions written in Rust

ashleygwilliams/breakfast-repo 373

a collection of videos, recordings, and podcasts to accompany our morning coffee

jcasimir/locale_setter 122

A simple library to set request locale based on a hierarchy of factors

judofyr/timeless 120

A mixture of a blog, wiki and CMS, inspired by Christoffer Sawicki's Termos and James Adam's Vanilla.rb

nikomatsakis/office-hours 113

Help me help you!

assert-rs/dir-diff 33

Are the contents of two directories different?

rust-dev-tools/dev-tools-team 33

resources for the Rust dev-tools team

push eventrust-lang/blog.rust-lang.org

Steve Klabnik

commit sha 464d513034b3da639883e88bd1aafa66dad4e3a9

rebuild pages at 85c45c9

view details

push time in 2 days

issue commentrust-lang/rust

sparc64: passing structures with floats in registers should use floating point registers

Triage: no movement whatsoever on the clang bug

karcherm

comment created time in 3 days

issue commentrust-lang/rust

Clicking 'src' in rustdoc for a type defined by a macro should show invocation, not macro definition

Traige: https://docs.rs/hyper/0.13.2/hyper/header/constant.ACCEPT_CHARSET.html is the best place to reproduce this bug

TedDriggs

comment created time in 5 days

Pull request review commentrust-lang/rust

Improve documentation on iterators length

 /// ``` #[stable(feature = "rust1", since = "1.0.0")] pub trait ExactSizeIterator: Iterator {-    /// Returns the exact number of times the iterator will iterate.+    /// Returns the exact length of the iterator, which is the number of times+    /// the iterator will return `Some(T)` before returning `None`.

This is a little long for a summary sentence. I'm not sure of the best way to re-word it though. It's likely that some of this will have to go below.

LeSeulArtichaut

comment created time in 6 days

push eventrust-lang/blog.rust-lang.org

Steve Klabnik

commit sha 81876cf4352b267e7938dae15c894d04fcdd0c09

rebuild pages at 9239ff5

view details

push time in 7 days

push eventrust-lang/blog.rust-lang.org

Steve Klabnik

commit sha 36b4b8fa5427f1820dc4ac2de4dbd3fa71a739c0

rebuild pages at 41f9f1b

view details

push time in 8 days

issue commentrust-lang/rust

Combining inline and target_feature attributes with recursive functions causing incorrect results.

@jackmott did you ever get around to testing this again? :)

jackmott

comment created time in 9 days

push eventrust-lang/blog.rust-lang.org

Steve Klabnik

commit sha b102bd02acc903c0fa03dab618e3484359908a26

rebuild pages at af84fec

view details

push time in 10 days

issue closedrust-lang/book

better pdf support

generate PDF with syntax highlight and file book outline.

I tried to use WKHtmlToPdf to generate the book from the website and it is generating the outline and the book successfully . but is not generating the syntax highlight and using the website font.

any help with generating the same book from the website but with outlines ?

closed time in 11 days

nour-dev

issue commentrust-lang/book

better pdf support

This is a duplicate of https://github.com/rust-lang/book/issues/218

nour-dev

comment created time in 11 days

issue closedrust-lang/rust

mem::transmute on types of different size (but the type size is known)

Problem

When I try to compile this method, the compiler reports that mem::transmute is being called on types of different sizes. (Which doesn't make sense because T size should be known in this context).

pub fn partition2<T: Sized>(source: [T; 52]) -> [[T; 13]; 4] {
    use std::mem;
    unsafe { mem::transmute(source) }
}

Compiler Error

error[E0512]: transmute called with types of different sizes
 --> src/main.rs:9:14
  |
9 |     unsafe { mem::transmute(source) }
  |              ^^^^^^^^^^^^^^
  |
  = note: source type: [T; 52] (size can vary because of T)
  = note: target type: [[T; 13]; 4] (size can vary because of T)

Working Example

Replacing T with a struct and it compiles fine (also works with String):

pub struct Card {
    value: u8,
    suit: Suit
}

pub enum Suit {
    Spades,
    Clubs,
    Diamonds,
    Hearts,
}

pub fn partition(source: [Card; 52]) -> [[Card; 13]; 4] {
    use std::mem;
    unsafe { mem::transmute(source) }
}

Meta

rustc 1.24.0-nightly (23032d0af 2017-11-30)
binary: rustc
commit-hash: 23032d0afa2b0e0c60a9b2ae62709f846d90007c
commit-date: 2017-11-30
host: x86_64-apple-darwin
release: 1.24.0-nightly
LLVM version: 4.0

closed time in 11 days

Avarel

issue commentrust-lang/rust

mem::transmute on types of different size (but the type size is known)

Triage: two years later, I think we should close this. Maybe it can be done someday, as @scottmcm points out, but it's unclear when that, if ever, will happen.

Avarel

comment created time in 11 days

push eventsteveklabnik/cargo

bors

commit sha eebd1da3a89e9c7788d109b3e615e1e25dc2cfcd

Auto merge of #7048 - jeremystucki:into_url, r=Eh2406 Rename to_url → into_url I think it should be `into_url` as it consumes itself. [Relevant clippy lint](https://rust-lang.github.io/rust-clippy/master/index.html#wrong_self_convention)

view details

Dan Aloni

commit sha 29b7e90ba37f311baaf448894bbf04721bed5791

named-profiles: formatting fixes from 'cargo fmt'

view details

Eh2406

commit sha cb95f5ef7c7203213a82e7b29b6612c1ae4ca440

check is_public vs Kind more carefully

view details

bors

commit sha 37cb9bbe2428e8d591d42673ef5562ca3ca92c55

Auto merge of #7045 - Eh2406:resolver-test/debug-cleanup, r=alexcrichton Resolver test/debug cleanup This is several small things salvaged from abandoned PRs and implemented on top of #7011 In working on this I noted that the prop tests are very sensitive to whether backtrace are turned on. Maybe we should set that env to 0 for that builder?

view details

Lucas Molas

commit sha 9aa7a4dce5f47e49c4100ff18a9dc0dc5a47efc4

test(freshness): check that updating dependency mtime does not rebuild

view details

Lucas Molas

commit sha 78927e6b15396ce0d1bb4837437bd0c3d004c7c5

fix(fingerpring): do not touch intermediate artifacts

view details

Lucas Molas

commit sha 8343fb7396891251cedcb290909a99261719ac23

test(freshness): remove `simple_deps_cleaner_does_not_rebuild` Now that the `mtime` of intermediate artifacts is not updated there's no need for this test anymore (it now fails because without the `mtime`s it cannot perform the intended GC operation).

view details

Lucas Molas

commit sha 009876a88af659c10b022ec4c4956f77b983d531

fix(fingerprint): rustfmt

view details

bors

commit sha 797ea153bfe5f6f50dc5d5985f7d746a83aeb1ca

Auto merge of #7050 - schomatis:fix/fingerprint/dont-update-intermediate-artifacts-mtime, r=Eh2406 fix(fingerpring): do not touch intermediate artifacts Fixes https://github.com/rust-lang/cargo/issues/6972. The newly introduced [test](https://github.com/rust-lang/cargo/pull/7050/commits/9aa7a4dce5f47e49c4100ff18a9dc0dc5a47efc4) is [failing](https://travis-ci.com/rust-lang/cargo/jobs/209849725#L2569-L2580) as discussed in https://github.com/rust-lang/cargo/issues/6972#issuecomment-502241124 (replicating the issue). Removing the `touching of intermediate artifacts` as suggested fixes the issue, but makes the old test `simple_deps_cleaner_does_not_rebuild` fail. The `simple_deps_cleaner_does_not_rebuild` test is not needed anymore so it's removed. r? @Eh2406

view details

Nicolas Mattia

commit sha df4775954f356ff480c3e4f355dea2d00dccf546

Fix typo in comment

view details

bors

commit sha 142603ae222defed68b9daf5771bce85b005f84f

Auto merge of #7054 - nmattia:nm/fix-typo, r=Eh2406 Fix typo in comment

view details

Eric Huss

commit sha 7d7fe6797ad07f313706380d251796702272b150

Stabilize default-run

view details

bors

commit sha 973356143c6b16c8536f84b8fce8cf43ccf48c74

Auto merge of #7056 - ehuss:default-run-stabilize, r=alexcrichton Stabilize default-run This stabilizes the default-run feature. I've included some error message changes. If `default-run` specifies an unknown binary, it now tells you that the `default-run` field is incorrect and which manifest it is located in, instead of just saying "could not determine which binary to run". I also consolidated some of the suggestion code so it is not repeated all over. Closes #7032

view details

Hugo van der Wijst

commit sha 2c488c91d4838955fca33bbdf3b7568a67b54eb9

Fix overwriting binary .d file for dSYM target on apple targets.

view details

Lzu Tao

commit sha e3b286bae9d46ee2842f90bcd02d9ee82c18f180

_cargo: Make function style consistent

view details

Eric Huss

commit sha 247063c35b40a0827c84f495cc8bdab9020a7438

Update some fix comments.

view details

bors

commit sha 5277137d854f8a8b351b22f5d95aafe8fbe696f4

Auto merge of #7061 - ehuss:update-fix-comments, r=alexcrichton Update some fix comments. - Primary handling changed in #5824. - cargo_as_rustc_wrapper changed in #6759.

view details

Lzu Tao

commit sha 29e6278f43868991b250dd4283151a1407e0ceb2

_cargo: Fix some warnings caught by shellcheck

view details

Lzu Tao

commit sha 44f782c049ca1d7a10d972cb661b78fbc6dff876

_cargo: Explain how _cargo_cmds works

view details

bors

commit sha ecc41f48a95cc973d50ede9cfc1ccdef474c1553

Auto merge of #7060 - lzutao:zsh-complete-package, r=ehuss _cargo: Make function style consistent They are just white-space changes. I'm planning to bring back Zsh completion for `-p` (package) option, which was disabled in #1713. This PR is the first stepping stone towards that goal. A disadvantageous is that I am just starting to learn Zsh completion system. Guess how far can I go? r? @ehuss

view details

push time in 11 days

issue closedrust-lang/wg-cargo-std-aware

Usage of `--sysroot` may still be racy and/or allow false dependencies

I'm realizing now that after we've implemented --sysroot that we may still be susceptible races where you can depend on a sysroot crate without actually declaring that you depend on it. Let's say that https://github.com/rust-lang/wg-cargo-std-aware/issues/5 has already been implemented, and you say you only depend on core, I think you could also depend on alloc via the following:

  • First, you build your project. Something else depends on alloc, but your crate fails to build.
    • The alloc crate, however, did actually end up finish building by the time your crate received its error.
  • Next, you run cargo build again.
  • This time, very quickly, alloc is linked into the sysroot
  • Your crate, which has extern crate alloc, now "magically works"

I think the problem here is that we're giving, via --sysroot, crates access to anything in the sysroot. Cargo doesn't actually have any control over what can be loaded from the sysroot. While this will probably only rarely come up in practice, I think we may want to strive to have Cargo have a more intrusive understanding of what crates are where in the sysroot.

Assuming that #5 is implemented I think we'll have some sort of distinction between crates that have sysroot dependencies or not. For example your crate will either declare its sysroot dependencies explicitly, or you won't say anything (like all crates do today) and we'll have some default behavior (like assuming you can use up to proc_macro). That puts us in one of two buckets:

  • If dependencies are listed, we don't use --sysroot. We instead use --extern always. This should be fine since the feature isn't implemented yet! If you're building in -Zbuild-std mode Cargo has a path to pass, otherwise Cargo uses --extern std to activate the name resolution logic to work the same as if --extern name=path was passed.
  • If dependencies aren't listed, we instead use a new and invented --extern-sysroot flag to point to the compiled crates. This has the same name resolution logic that sysroot crates have today (wrt shadowing via macros and stuff like that).

The invented --extern-sysroot flag here would take the form --extern-sysroot name=path. In all cases Cargo would pass -L dependency=... for the sysroot, and the --extern flags would configure which crates can be loaded from the sysroot. The only reason for --extern-sysroot to exist is to match the name resolution behavior of sysroot crates today since there are subtle differences. Alternatively we could fix rustc so there are no differences!

closed time in 11 days

alexcrichton

issue closedrust-lang/wg-cargo-std-aware

Possibly add a way to disable sysroot on `rustc`

The current implementation uses --extern flags to tell rustc where the standard library dependencies are located. This runs into a few problems when a user attempts to use extern crate for a crate that was not included. For example, a no_std crate that has extern std, or an extern crate test when libtest is not built. These will attempt to load from the default sysroot which causes a huge number of inscrutable errors.

It may be nice to tell rustc to not look in the pre-built sysroot to avoid this problem (and will result in a nicer "crate not found" error). This can be done with --sysroot=nonexistent or an empty directory. Alternatively, we can add a new flag to rustc to disable the sysroot search.

This may have complications, since the sysroot is used for more than rlib dependencies. For example, it is also used for bundled things (like linkers? bundled crt objects?).

Beware this may affect things like clippy-driver, rustdoc, etc.

closed time in 11 days

ehuss

issue commentrust-lang/rust

std::sync::Once can block forever in forked process

Triage: it's unclear to me what would cause this ticket to be resolved.

joshlf

comment created time in 12 days

issue commentrust-lang/cargo

cargo new: create a README

I am not on the cargo team, so I cannot really make that call.

steveklabnik

comment created time in 13 days

issue commentrust-lang/rust

Type inference fails in light of generic type aliases with default parameter.

Triage: this still fails to compile

glandium

comment created time in 14 days

issue closedrust-lang/rust

rustc allows crates compiled against different versions of a parent crate to be linked

I'm not sure if this is intentional, but it's certainly problematic. If you have four crates A, B, C, D with the following dependency tree:

        +---+
        | A |
        +---+
       /  |  \
      /   |   \
   +---+  |    |
   | B |  |    |
   +---+  |    |
        \ |    |
         \|    |
        +---+  |
        | C |  |
        +---+  |
             \ |
              \|
             +---+
             | D |
             +---|

then rustc allows B, which was compiled against an older version of A, to be linked with C and D, which were compiled against a newer version of A.

closed time in 14 days

mahkoh

issue commentrust-lang/rust

rustc allows crates compiled against different versions of a parent crate to be linked

Triage: given no comments by others since 2016, and the very specific details needed to trigger this, and so much changing over the last years, I'm going to close this one.

mahkoh

comment created time in 14 days

issue commentrust-lang/rust

incremental: hash items' source tokens to generate DefId's.

Triage: no idea what the status of this issue is or if it's useful.

eddyb

comment created time in 14 days

issue commentrust-lang/rust

1.15.1 armhf run-make/relocation-model failed, "relocation [..] against `a local symbol' can not be used [..]; recompile with -fPIC"

Triage: has anyone seen this error since 2018? Any way to reproduce?

infinity0

comment created time in 14 days

issue closedrust-lang/rust

`invalid-module-declaration.rs` test regression

As part of #53196, compile-fail tests were migrated to ui tests. In doing this, it was discovered that error patterns were not being applied to ui tests (#52531). invalid-module-declaration.rs is a test that regressed due to this and that regression was not noticed.

The error patterns previously on invalid-module-declaration.rs expected the following errors:

// error-pattern: cannot declare a new module at this location
// error-pattern: maybe move this module

In particular, these check for duplicate module declaration errors - which should arise as the auxiliary folder contains modules that have the same name as those being defined within the test code. However, these errors had not been occuring, and a lack of error pattern assertions meant this wasn't noticed.

At some point in a previous commit these did work, as evidenced by old .stderr files for this test. In #53196, the error pattern annotations were removed in order to get it passing so that PR could land.

closed time in 14 days

davidtwco

issue commentrust-lang/rust

`invalid-module-declaration.rs` test regression

It seems this issue is 100% irrelevant now; this test no longer has these declarations, and seems to be working as expected. Closing!

davidtwco

comment created time in 14 days

issue closedsteveklabnik/history-of-rust

The Repository URL is 404

The Repository URL (steveklabnik.com's) is 404. Screen Shot 2020-02-03 at 10 06 41

Now it is http://steveklabnik.github.io/history-of-rust/ right?

closed time in 14 days

gfx

issue commentsteveklabnik/history-of-rust

The Repository URL is 404

That is true, I've fixed it now, thank you!

gfx

comment created time in 14 days

push eventrust-lang/blog.rust-lang.org

Steve Klabnik

commit sha 84c4a5d5c1cdf0298ce4b2edfc5cd1b69e5e9b61

rebuild pages at 15088ef

view details

push time in 14 days

push eventrust-lang/blog.rust-lang.org

Steve Klabnik

commit sha 301f6fe435ab1f69dbc2465d0a3375b261cbb123

rebuild pages at eba3987

view details

push time in 15 days

push eventrust-lang/blog.rust-lang.org

Steve Klabnik

commit sha fabbce142e9b378bb20434b2664823761c3618cc

rebuild pages at 01d4c93

view details

push time in 16 days

push eventrust-lang/blog.rust-lang.org

Steve Klabnik

commit sha 1df80aab38eb7ecf2880e46f28f9df7c823163c4

rebuild pages at a041b9d

view details

push time in 16 days

pull request commentrust-lang/rust

Instrument C / C++ in MemorySanitizer example

@bors: r+ rollup

thanks!

tmiasko

comment created time in 18 days

startedmcclure/bitbucket-backup

started time in 20 days

issue commentrust-lang/book

traits need to be taught earlier

Hey Sarah!

So, I think this suggestion is overall good, the problem is that it ends up being a very different book. It might be a better book, but the book kinda has multiple responsibilities:

  1. It is official documentation
  2. It is to teach you the language

There's always been a tension between these two things; for example, it has to be more comprehensive than maybe I'd like, because of responsibility number 1. It has to also leave some details out, because of number 2. These two things are just at odds.

We also decided that the book would attempt to build you up from nearly nothing, as much as possible, and to minimize forward references. At this point, over the last few years I've probably spent 20 or 30 hours fiddling with concept maps and what order the TOC needs to go in. This is the third iteration of that effort.

Also, on a more practical level, we just aren't going to reorganize the book to this level, regardless of what an improvement it might be. I wrote the first version of the book myself, and then carol and i threw it out entirely to write this version. It's also had one or two re-architectings. At this point, at about four years of working with this particular text, I've spent enough of my life re-organizing it. I also have way less time, given that it's not my job anymore...

Anyway, so that's some detail on why we can't do this. I would love to see more books exploring how to teach people how to program in Rust; "Programming Rust", for example, is a very different book than TRPL, and I think it's got a lot of pros too.

ultrasaurus

comment created time in 22 days

issue closedrust-lang/rust

Poor debug info in optimized code

At the moment debugging optimized code is pretty tricky. Even with full debug info enabled, most/all of the locals and parameters are <optimized out>. (Linux + gdb)

I believe that DWARF can include info to regenerate the logical value of a variable that has been removed by optimization. Is this something llvm needs to support, or rustc, or both?

In general how can this be improved?

cc @tromey @Mark-Simulacrum

closed time in 22 days

jsgf

issue commentrust-lang/rust

Poor debug info in optimized code

Triage: while this bug does contain one specific case, it's also very general. We have a bunch of bugs open related to debuginfo not being sufficient. I'm going to make a judgement call and give this one a close. Please file follow-up issues for specific things that can be improved, if issues aren't open already. Thanks!

jsgf

comment created time in 22 days

push eventrust-lang/blog.rust-lang.org

Steve Klabnik

commit sha cf29728a387c5eea0baf0ff56c042c2bf02fc40b

rebuild pages at 8ccbc94

view details

push time in 22 days

Pull request review commentrust-lang/rust

Add documentation to compiler intrinsics

 extern "rust-intrinsic" {     /// [`AtomicBool::fetch_xor`](../../std/sync/atomic/struct.AtomicBool.html#method.fetch_xor).     pub fn atomic_xor_relaxed<T>(dst: *mut T, src: T) -> T; +    /// Maximum with the current value using a sized comparison.+    /// The stabilized version of this intrinsic is available on the

there needs to be an empty /// between the summary sentence and the start of the rest of the docs, like this:

/// Maximum with the current value using a sized comparison.
///
/// The stabilized...
LeSeulArtichaut

comment created time in 23 days

issue commentrust-lang/rust

Cyclic dependency bug processing RPIT `impl Trait`

Triage: given

Okay, weirdly this is only happening when I have RUST_LOG="rustc_typeck::astconv=debug".

and how much the compiler has changed since nov of 2018 (even though that module still exists), and with no other comments, I am gonna guess that this may not reproduce, and even if it did, wouldn't affect users. So I'm gonna give it a close. @alexreg if this still reproduces for you today, please feel free to re-open.

alexreg

comment created time in 23 days

issue commentrust-lang/mdBook

Code block using the "async" keyword causes compilation failure

I believe this is because it's testing with rust 2015, not 2018?

cfsamson

comment created time in 23 days

push eventrust-lang/book

SuperSamus

commit sha 0889e73d627eb1ef6e6b9750f69c5e769bdc51bb

Update ch19-01-unsafe-rust.md Fixes #2042.

view details

SuperSamus

commit sha 05f8008f5d17f2a94de219971ff447408653eaa1

Update ch19-01-unsafe-rust.md

view details

SuperSamus

commit sha 92809452ff50e57ff589610a5a199cb7ec511d5d

Merge branch 'master' into patch-1

view details

SuperSamus

commit sha f58d93901423b40cdd701838bece345aa3c79256

Use ptr.add instad of offset

view details

Steve Klabnik

commit sha f4c7cfcd7a9853b2738ba66f362de04a06e68683

Merge pull request #2201 from SuperSamus/patch-1 Listing 19-6: use ptr.add instead of ptr.offset

view details

push time in 23 days

PR merged rust-lang/book

Listing 19-6: use ptr.add instead of ptr.offset

Fixes #2042.

+4 -4

3 comments

2 changed files

SuperSamus

pr closed time in 23 days

issue closedrust-lang/book

Listing 19-6: use ptr.add instead of ptr.offset

In Chapter 19.1 (Unsafe Rust), the line from listing 19-6 slice::from_raw_parts_mut(ptr.offset(mid as isize), len - mid)) should use ptr.add instead (beacause it asks for an usize, avoiding the conversion), just like the official implementation does. Also, Clippy complains:

use of offset with a usize casted to an isize

note: #[warn(clippy::ptr_offset_with_cast)] on by default help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#ptr_offset_with_cast help: try: ptr.add(mid)clippy(clippy::ptr_offset_with_cast)

closed time in 23 days

SuperSamus

issue commentrust-lang/book

traits need to be taught earlier

(I still want to write a longer response here, but this week has been getting away from me, maybe tomorrow morning. The end result is still the same, though, thanks for all the triage, Carol ❤️ )

ultrasaurus

comment created time in 23 days

push eventrust-lang/blog.rust-lang.org

Steve Klabnik

commit sha 8d9e1e1d21bcc287e71e3b118688497d03b71aa8

rebuild pages at 769d0ad

view details

push time in 23 days

issue commentrust-lang/rust

Remove the !Send and !Sync impls for proc_macro::LineColumn

This code now lives in .\src\libproc_macro\lib.rs, but still has the impls.

dtolnay

comment created time in 23 days

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

Justify text in paragraphs

I... am really not sure. This isn't the worst thing to do, but in my understanding, isn't considered best practice either. But I'm not 100% sure.

pietroalbini

comment created time in 23 days

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

Rust 1.41.0 announcement

Release blog posts used to have a whole Cargo section, which is now apparently relegated to a link to its changelog.

pietroalbini

comment created time in 23 days

pull request commentrust-lang/book

Listing 19-6: use ptr.add instead of ptr.offset

... and now there's a merge conflict, ha! Sorry :/

SuperSamus

comment created time in 23 days

pull request commentrust-lang/rust

Document remaining undocumented `From` implementations for IPs

It's all good, thank you!

@bors: r+ rollup

LeSeulArtichaut

comment created time in 24 days

pull request commentrust-lang/rust

Document `From` implementation for NonZero nums

Thanks!

@bors: r+ rollup

LeSeulArtichaut

comment created time in 24 days

pull request commentrust-lang/rust

Document remaining undocumented `From` implementations for IPs

Thanks!

@bors: r+ rollup

LeSeulArtichaut

comment created time in 24 days

push eventrust-lang/blog.rust-lang.org

Steve Klabnik

commit sha 67ec1388e9939f954444b69a00995437ed01483a

rebuild pages at b06f8d5

view details

push time in 25 days

issue commentrust-lang/rust

Incremental compilation regression with num-bignum

Triage: I do not get any warnings while trying to do an incremental compilation with cargo bench

Flakebi

comment created time in 25 days

issue closedrust-lang/rust

NLL gives weird/incorrect errors when enumerating parallel iterator

I wrote the following, incorrect, code on the Playground for playing around with NLL

#![feature(nll)]
extern crate rayon; // 1.0.1

use rayon::prelude::*;

fn map(m: &mut Vec<Vec<usize>>, f: fn(&usize, &usize) -> (usize, usize)) -> Vec<Vec<usize>> {
    let mut out: Vec<Vec<usize>> = Vec::new();
    m.par_iter().enumerate().for_each(|(i, v1)| {
        v1.par_iter().enumerate().for_each(|(j, v2)| {
            let c = f(&i, &j);
            out[c.0][c.1] = *v2;
        })
    });
    out
}

fn main() {}

This spits out the following, very unhelpful, error message

error[E0596]: cannot borrow immutable item `out` as mutable
  --> src/main.rs:9:44
   |
9  |           v1.par_iter().enumerate().for_each(|(j, v2)| {
   |  ____________________________________________^
10 | |             let c = f(&i, &j);
11 | |             out[c.0][c.1] = *v2;
12 | |         })
   | |_________^ cannot borrow as mutable

Disabling NLL, however, gives me a much more comprehensible error regarding the incorrect borrow

error[E0387]: cannot borrow data mutably in a captured outer variable in an `Fn` closure
 --> src/main.rs:9:44
  |
9 |         v1.par_iter().enumerate().for_each(|(j, v2)| {
  |                                            ^^^^^^^^^
  |
help: consider changing this to accept closures that implement `FnMut`
 --> src/main.rs:8:39
  |
8 |       m.par_iter().enumerate().for_each(|(i, v1)| {
  |  _______________________________________^
9 | |         v1.par_iter().enumerate().for_each(|(j, v2)| {
10| |             let c = f(&i, &j);
11| |             out[c.0][c.1] = *v2;
12| |         })
13| |     });
  | |_____^

Here's a link to the Playground

closed time in a month

lovesegfault

issue commentrust-lang/rust

NLL gives weird/incorrect errors when enumerating parallel iterator

Now that nll is the only borrowcheck, this error message has improved, or rather, not regressed :)

error[E0596]: cannot borrow `out` as mutable, as it is a captured variable in a `Fn` closure
  --> src/main.rs:10:13
   |
10 |             out[c.0][c.1] = *v2;
   |             ^^^ cannot borrow as mutable
   |
help: consider changing this to accept closures that implement `FnMut`
  --> src/main.rs:8:44
   |
8  |           v1.par_iter().enumerate().for_each(|(j, v2)| {
   |  ____________________________________________^
9  | |             let c = f(&i, &j);
10 | |             out[c.0][c.1] = *v2;
11 | |         })
   | |_________^

error[E0596]: cannot borrow `out` as mutable, as it is a captured variable in a `Fn` closure
  --> src/main.rs:8:44
   |
8  |         v1.par_iter().enumerate().for_each(|(j, v2)| {
   |                                            ^^^^^^^^^ cannot borrow as mutable
9  |             let c = f(&i, &j);
10 |             out[c.0][c.1] = *v2;
   |             --- mutable borrow occurs due to use of `out` in closure
   |
help: consider changing this to accept closures that implement `FnMut`
  --> src/main.rs:7:39
   |
7  |       m.par_iter().enumerate().for_each(|(i, v1)| {
   |  _______________________________________^
8  | |         v1.par_iter().enumerate().for_each(|(j, v2)| {
9  | |             let c = f(&i, &j);
10 | |             out[c.0][c.1] = *v2;
11 | |         })
12 | |     });
   | |_____^

error: aborting due to 2 previous errors

Closing!

lovesegfault

comment created time in a month

Pull request review commentrust-lang/book

Extract code and output; script formatting and updating them

+#!/bin/bash++set -eu++# Build the book before making any changes for comparison of the output.+echo 'Building book into `tmp/book-before` before updating...'+mdbook build -d tmp/book-before++# TODO: Rustfmt all listings here

oh whoops lol!

carols10cents

comment created time in a month

issue commentrust-lang/rust

Detect loops that cannot be automatically vectorized

Triage: no change

thedrow

comment created time in a month

Pull request review commentrust-lang/book

Extract code and output; script formatting and updating them

+#!/bin/bash++set -eu++# Build the book before making any changes for comparison of the output.+echo 'Building book into `tmp/book-before` before updating...'+mdbook build -d tmp/book-before++# TODO: Rustfmt all listings here

now that the stuff was rustfmt'd in the later commits, this could be done, right?

carols10cents

comment created time in a month

Pull request review commentrust-lang/book

Extract code and output; script formatting and updating them

+We have some weird comments pointing out borrowing scopes that we don't want to change;+unfortunately I haven't found a way to skip them with rustfmt that works so for now we're going to+manually skip those listings. See: https://github.com/rust-lang/rustfmt/issues/4028

ah this is very interesting... this seems good to be honest.

carols10cents

comment created time in a month

Pull request review commentrust-lang/book

Extract code and output; script formatting and updating them

+# Administrative Tasks++This documentation is for Carol and Steve and anyone else managing the repo to remember how to do+occasional maintenance tasks.++## Update the `rustc` version

😍

carols10cents

comment created time in a month

push eventrust-lang/blog.rust-lang.org

Steve Klabnik

commit sha cfb4a85ab8a28a110b6b1157e0f2b51ef8d7c9b9

rebuild pages at 275d195

view details

push time in a month

push eventrust-lang/blog.rust-lang.org

Steve Klabnik

commit sha 9a29a6c33f659fdeab4309808028861a9f2e9bb1

rebuild pages at e6c5689

view details

push time in a month

push eventrust-lang/blog.rust-lang.org

Steve Klabnik

commit sha 853bebe1a29933c4c6e5440436630db27a7debac

rebuild pages at b65bdc5

view details

push time in a month

push eventrust-lang/blog.rust-lang.org

Steve Klabnik

commit sha d8d27c76d54dbb4edc7f1132b17a1df70bfdab1e

rebuild pages at 29b16a2

view details

push time in a month

push eventrust-lang/blog.rust-lang.org

Steve Klabnik

commit sha 9dda1f4d1a4197fdd1b19fc451d6aa07fb1ff435

rebuild pages at 544037d

view details

push time in a month

pull request commentrust-lang/rust

Updating str.chars docs to mention crates.io.

(For slightly more context, negative statements in docs tend to go out of date quickly; if we did add this functionality, this comment would very likely get out of date. Additionally, we don't generally pick favorites, and so mentioning crates.io by name is also unusual.)

sdegutis

comment created time in a month

pull request commentrust-lang/rust

Updating str.chars docs to mention crates.io.

We generally don't write docs like this; I will let @rust-lang/libs decide if they want this or not, however.

sdegutis

comment created time in a month

push eventrust-lang/blog.rust-lang.org

Steve Klabnik

commit sha e25a4feb866e571c6ea811262ce5ed5086d7c805

rebuild pages at b2d7cdf

view details

push time in a month

push eventrust-lang/blog.rust-lang.org

Steve Klabnik

commit sha 55837c0c5c921644797545f465be1b3eddc3b757

rebuild pages at 3605e0f

view details

push time in a month

issue closedrust-lang/rust

Zero-overhead exception

I would suggest to add Zero-Overhead Exception in Rust

Consider the following code:

union SomeFunctionMultipleError {
    err0: Error1,
    err1: Error2,
}

struct SomeFunctionFnError {
    index: u32,
    errors: SomeFunctionMultipleError,
}

fn some_function(i: i32) -> Result<i32, SomeFunctionFnError> {
    if i == 0 {
        Ok(2)
    } else if i == 1 {
        Err(SomeFunctionFnError{ index: 0, errors: SomeFunctionMultipleError {err1: Error1 {id0: 0, id1: 0, id3: 0}}})
    } else {
        Err(SomeFunctionFnError{ index: 0, errors: SomeFunctionMultipleError {err1: Error2 {id0: 0, id1: 0, id3: 0}}})
    }
}

union OtherFunctionMultipleError {
    err0: Error1,
    err1: Error2,
    err2: Error3,
}

struct OtherFunctionFnError {
    id: u32,
    errors: OtherFunctionMultipleError,
}

fn other_function(i: i32) -> Result<i32, OtherFunctionFnError> {
    if i == 0 {
        Ok(2)
    } else if i == 1 {
        Err(OtherFunctionFnError{id: 0, errors: OtherFunctionMultipleError {err0: Error1 {id0: 0, id1: 0, id3: 0}}})
    } else if i == 2 {
        Err(OtherFunctionFnError{id: 0, errors: OtherFunctionMultipleError {err0: Error2 {id0: 0, id1: 0, id3: 0}}})
    } else {
        Err(OtherFunctionFnError {id: 0, errors: OtherFunctionMultipleError {err0: Error3 {id0: 0, id1: 0}}})
    }
}

This is the code that could be generated by Zero-Overhead exceptions in Rust with following syntax feature:

fn some_function(i: i32) -> i32 throws Error1, Error2 {
    if i == 0 {
        2
    } else if i == 1 {
        Error1 {id0: 0, id1: 0, id3: 0}.throw
    } else {
        Error2 {id0: 0, id1: 0, id3: 0}.throw
    }
}

fn other_function(i: i32) -> i32 throws Error1, Error2, Error3 {
    if i == 0 {
        2
    } else if i == 1 {
        Error1 {id0: 0, id1: 0, id3: 0}.throw
    } else if i == 2 {
        Error2 {id0: 0, id1: 0, id3: 0}.throw
    } else {
        Error3 {id0: 0, id1: 0, id3: 0}.throw
    }
}

or even these errors could be deduced by compiler implicitly:

fn some_function(i: i32) -> i32 throws { // Implicitly throws Error1, Error2
    if i == 0 {
        2
    } else if i == 1 {
        Error1 {id0: 0, id1: 0, id3: 0}.throw
    } else {
        Error2 {id0: 0, id1: 0, id3: 0}.throw
    }
}

fn other_function(i: i32) -> i32 throws { // Implicitly throws Error1
    if i == 0 {
        2
    } else {
        Error1{id0: 0, id1: 0}.throw
    }
}

This nothing else syntactic sugar !! Behavior is the same !! C++ has the same proposal already http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r2.pdf

It is possible to implement and it is nothing else than syntactic sugar !!

closed time in a month

redradist

issue commentrust-lang/rust

Zero-overhead exception

Language changes must go through our RFC process, please pursue this over there. https://github.com/rust-lang/rfcs

Thanks!

redradist

comment created time in a month

issue commentsemver/semver

Optional minor and patch versions

Today, the maintainer's list is longer, and they are mostly the representatives of package tooling owners. I think they've had it for about a year now?

It's been a while, it's true. I have not had as much time as I would like to really push things forward, so things are moving slowly, and I think that's okay for such a broad spec. I also completely understand the desire to talk about things before they're implemented, and I think that's totally fine. Just don't have the bandwidth for the discussion right this second.

zafarkhaja

comment created time in a month

issue commentrust-lang/rust

Move HashMap to alloc::collections

Triage: not aware of any real movement here.

WildCryptoFox

comment created time in a month

PR opened cloudflare/quiche

fix markdown in qlog README

This is breaking the rendering of the README on crates.io :)

+2 -2

0 comment

1 changed file

pr created time in a month

push eventsteveklabnik/quiche

Steve Klabnik

commit sha 72f6b8a19221568b06b665a04a4c48514c3e56cc

fix markdown in qlog README

view details

push time in a month

fork steveklabnik/quiche

🥧 Savoury implementation of the QUIC transport protocol and HTTP/3

https://docs.quic.tech/quiche/

fork in a month

pull request commentcloudflare/workers-docs

Add async to KV delete

So, one reason why I like the more elaborate version is that doing this is actually really important: if you don't, you may actually lose the delete.

If this is the way you want it, it's certainly an improvement over what's there, but I would personally tend towards the verbose.

victoriabernard92

comment created time in a month

Pull request review commentcloudflare/wrangler

[dev] fix windows builds and timeouts

+use std::time::Duration;++use chrome_devtools as protocol;++use console::style;++use futures::{future, pin_mut, StreamExt};+use futures_util::sink::SinkExt;++use tokio::time;+use tokio_tungstenite::connect_async;+use tungstenite::protocol::Message;++use url::Url;++const KEEP_ALIVE_INTERVAL: u64 = 10;++pub async fn listen(session_id: String) -> Result<(), failure::Error> {+    let socket_url = format!("wss://rawhttp.cloudflareworkers.com/inspect/{}", session_id);+    let socket_url = Url::parse(&socket_url)?;++    let (ws_stream, _) = connect_async(socket_url)+        .await+        .expect("Failed to connect to devtools instance");++    let (mut write, read) = ws_stream.split();++    let enable_runtime = protocol::runtime::SendMethod::Enable(1.into());+    let enable_runtime = serde_json::to_string(&enable_runtime)?;+    let enable_runtime = Message::Text(enable_runtime.into());+    write.send(enable_runtime).await?;++    let (keep_alive_tx, keep_alive_rx) = futures::channel::mpsc::unbounded();+    tokio::spawn(keep_alive(keep_alive_tx));+    let keep_alive_to_ws = keep_alive_rx.map(Ok).forward(write);++    let print_ws_messages = {+        read.for_each(|message| async {+            let message = message.unwrap().into_text().unwrap();+            log::info!("{}", message);+            let message: Result<protocol::Runtime, failure::Error> = serde_json::from_str(&message)+                .map_err(|e| failure::format_err!("this event could not be parsed:\n{}", e));+            if let Ok(protocol::Runtime::Event(event)) = message {+                match event {+                    protocol::runtime::Event::ConsoleAPICalled(event) => {+                        match event.r#type.as_str() {+                            "log" => println!("{}", style(event).green()),+                            "error" => println!("{}", style(event).red()),+                            _ => println!("{}", style(event).yellow()),+                        }+                    }+                    protocol::runtime::Event::ExceptionThrown(event) => {+                        println!("{}", style(event).bold().red())+                    }+                    _ => (),+                }+            }+        })+    };+    pin_mut!(keep_alive_to_ws, print_ws_messages);+    future::select(keep_alive_to_ws, print_ws_messages).await;+    Ok(())+}++async fn keep_alive(tx: futures::channel::mpsc::UnboundedSender<Message>) {

(loop has the type !, but since ! coerces to any other type, it coerces to the return type of () here, which is why this code works the way it does)

EverlastingBugstopper

comment created time in a month

Pull request review commentcloudflare/wrangler

[dev] fix windows builds and timeouts

+use std::time::Duration;++use chrome_devtools as protocol;++use console::style;++use futures::{future, pin_mut, StreamExt};+use futures_util::sink::SinkExt;++use tokio::time;+use tokio_tungstenite::connect_async;+use tungstenite::protocol::Message;++use url::Url;++const KEEP_ALIVE_INTERVAL: u64 = 10;++pub async fn listen(session_id: String) -> Result<(), failure::Error> {+    let socket_url = format!("wss://rawhttp.cloudflareworkers.com/inspect/{}", session_id);+    let socket_url = Url::parse(&socket_url)?;++    let (ws_stream, _) = connect_async(socket_url)+        .await+        .expect("Failed to connect to devtools instance");++    let (mut write, read) = ws_stream.split();++    let enable_runtime = protocol::runtime::SendMethod::Enable(1.into());+    let enable_runtime = serde_json::to_string(&enable_runtime)?;+    let enable_runtime = Message::Text(enable_runtime.into());+    write.send(enable_runtime).await?;++    let (keep_alive_tx, keep_alive_rx) = futures::channel::mpsc::unbounded();+    tokio::spawn(keep_alive(keep_alive_tx));+    let keep_alive_to_ws = keep_alive_rx.map(Ok).forward(write);++    let print_ws_messages = {+        read.for_each(|message| async {+            let message = message.unwrap().into_text().unwrap();+            log::info!("{}", message);+            let message: Result<protocol::Runtime, failure::Error> = serde_json::from_str(&message)+                .map_err(|e| failure::format_err!("this event could not be parsed:\n{}", e));+            if let Ok(protocol::Runtime::Event(event)) = message {+                match event {+                    protocol::runtime::Event::ConsoleAPICalled(event) => {+                        match event.r#type.as_str() {+                            "log" => println!("{}", style(event).green()),+                            "error" => println!("{}", style(event).red()),+                            _ => println!("{}", style(event).yellow()),+                        }+                    }+                    protocol::runtime::Event::ExceptionThrown(event) => {+                        println!("{}", style(event).bold().red())+                    }+                    _ => (),+                }+            }+        })+    };+    pin_mut!(keep_alive_to_ws, print_ws_messages);+    future::select(keep_alive_to_ws, print_ws_messages).await;+    Ok(())+}++async fn keep_alive(tx: futures::channel::mpsc::UnboundedSender<Message>) {

https://doc.rust-lang.org/stable/book/ch19-04-advanced-types.html#the-never-type-that-never-returns

EverlastingBugstopper

comment created time in a month

Pull request review commentcloudflare/wrangler

[dev] fix windows builds and timeouts

 pub fn dev(     let session_id = get_session_id()?;     let preview_id = get_preview_id(target, user, &server_config, &session_id)?; -    // create a new thread to listen for devtools messages-    thread::spawn(move || socket::listen(session_id));--    // spawn tokio runtime on the main thread to handle incoming HTTP requests     let mut runtime = TokioRuntime::new()?;-    runtime.block_on(serve(server_config, preview_id))?;++    let devtools_listener = socket::listen(session_id);+    let server = serve(server_config, preview_id);++    let runners = futures::future::join(devtools_listener, server);++    runtime.block_on(async {+        let (_, _) = runners.await;
pub fn block_on<F: Future>(&mut self, future: F) -> F::Output

should return that Result back out of block_on, I think.

EverlastingBugstopper

comment created time in a month

Pull request review commentcloudflare/wrangler

[dev] fix windows builds and timeouts

 pub fn dev(     let session_id = get_session_id()?;     let preview_id = get_preview_id(target, user, &server_config, &session_id)?; -    // create a new thread to listen for devtools messages-    thread::spawn(move || socket::listen(session_id));--    // spawn tokio runtime on the main thread to handle incoming HTTP requests     let mut runtime = TokioRuntime::new()?;-    runtime.block_on(serve(server_config, preview_id))?;++    let devtools_listener = socket::listen(session_id);+    let server = serve(server_config, preview_id);++    let runners = futures::future::join(devtools_listener, server);

🎊

EverlastingBugstopper

comment created time in a month

Pull request review commentcloudflare/wrangler

[dev] fix windows builds and timeouts

 pub fn dev(     let session_id = get_session_id()?;     let preview_id = get_preview_id(target, user, &server_config, &session_id)?; -    // create a new thread to listen for devtools messages-    thread::spawn(move || socket::listen(session_id));--    // spawn tokio runtime on the main thread to handle incoming HTTP requests     let mut runtime = TokioRuntime::new()?;-    runtime.block_on(serve(server_config, preview_id))?;++    let devtools_listener = socket::listen(session_id);+    let server = serve(server_config, preview_id);++    let runners = futures::future::join(devtools_listener, server);++    runtime.block_on(async {+        let (_, _) = runners.await;

any reason to not

let _ =

instead?

EverlastingBugstopper

comment created time in a month

Pull request review commentcloudflare/wrangler

[dev] fix windows builds and timeouts

+use std::time::Duration;++use chrome_devtools as protocol;++use console::style;++use futures::{future, pin_mut, StreamExt};+use futures_util::sink::SinkExt;++use tokio::time;+use tokio_tungstenite::connect_async;+use tungstenite::protocol::Message;++use url::Url;++const KEEP_ALIVE_INTERVAL: u64 = 10;++pub async fn listen(session_id: String) -> Result<(), failure::Error> {+    let socket_url = format!("wss://rawhttp.cloudflareworkers.com/inspect/{}", session_id);+    let socket_url = Url::parse(&socket_url)?;++    let (ws_stream, _) = connect_async(socket_url)+        .await+        .expect("Failed to connect to devtools instance");++    let (mut write, read) = ws_stream.split();++    let enable_runtime = protocol::runtime::SendMethod::Enable(1.into());+    let enable_runtime = serde_json::to_string(&enable_runtime)?;+    let enable_runtime = Message::Text(enable_runtime.into());+    write.send(enable_runtime).await?;++    let (keep_alive_tx, keep_alive_rx) = futures::channel::mpsc::unbounded();+    tokio::spawn(keep_alive(keep_alive_tx));+    let keep_alive_to_ws = keep_alive_rx.map(Ok).forward(write);++    let print_ws_messages = {+        read.for_each(|message| async {+            let message = message.unwrap().into_text().unwrap();+            log::info!("{}", message);+            let message: Result<protocol::Runtime, failure::Error> = serde_json::from_str(&message)+                .map_err(|e| failure::format_err!("this event could not be parsed:\n{}", e));+            if let Ok(protocol::Runtime::Event(event)) = message {+                match event {+                    protocol::runtime::Event::ConsoleAPICalled(event) => {+                        match event.r#type.as_str() {+                            "log" => println!("{}", style(event).green()),+                            "error" => println!("{}", style(event).red()),+                            _ => println!("{}", style(event).yellow()),+                        }+                    }+                    protocol::runtime::Event::ExceptionThrown(event) => {+                        println!("{}", style(event).bold().red())+                    }+                    _ => (),+                }+            }+        })+    };+    pin_mut!(keep_alive_to_ws, print_ws_messages);+    future::select(keep_alive_to_ws, print_ws_messages).await;+    Ok(())+}++async fn keep_alive(tx: futures::channel::mpsc::UnboundedSender<Message>) {+    let duration = Duration::from_millis(1000 * KEEP_ALIVE_INTERVAL);+    let mut interval = time::interval(duration);++    let mut id = 2;

i am interested why this is 2. not because it's wrong, but it feels unusual! Might deserve a comment

EverlastingBugstopper

comment created time in a month

Pull request review commentcloudflare/wrangler

[dev] fix windows builds and timeouts

+use std::time::Duration;++use chrome_devtools as protocol;++use console::style;++use futures::{future, pin_mut, StreamExt};+use futures_util::sink::SinkExt;++use tokio::time;+use tokio_tungstenite::connect_async;+use tungstenite::protocol::Message;++use url::Url;++const KEEP_ALIVE_INTERVAL: u64 = 10;++pub async fn listen(session_id: String) -> Result<(), failure::Error> {+    let socket_url = format!("wss://rawhttp.cloudflareworkers.com/inspect/{}", session_id);+    let socket_url = Url::parse(&socket_url)?;++    let (ws_stream, _) = connect_async(socket_url)+        .await+        .expect("Failed to connect to devtools instance");++    let (mut write, read) = ws_stream.split();++    let enable_runtime = protocol::runtime::SendMethod::Enable(1.into());+    let enable_runtime = serde_json::to_string(&enable_runtime)?;+    let enable_runtime = Message::Text(enable_runtime.into());+    write.send(enable_runtime).await?;++    let (keep_alive_tx, keep_alive_rx) = futures::channel::mpsc::unbounded();+    tokio::spawn(keep_alive(keep_alive_tx));+    let keep_alive_to_ws = keep_alive_rx.map(Ok).forward(write);++    let print_ws_messages = {+        read.for_each(|message| async {+            let message = message.unwrap().into_text().unwrap();+            log::info!("{}", message);+            let message: Result<protocol::Runtime, failure::Error> = serde_json::from_str(&message)+                .map_err(|e| failure::format_err!("this event could not be parsed:\n{}", e));+            if let Ok(protocol::Runtime::Event(event)) = message {+                match event {+                    protocol::runtime::Event::ConsoleAPICalled(event) => {+                        match event.r#type.as_str() {+                            "log" => println!("{}", style(event).green()),+                            "error" => println!("{}", style(event).red()),+                            _ => println!("{}", style(event).yellow()),+                        }+                    }+                    protocol::runtime::Event::ExceptionThrown(event) => {+                        println!("{}", style(event).bold().red())+                    }+                    _ => (),+                }+            }+        })+    };+    pin_mut!(keep_alive_to_ws, print_ws_messages);+    future::select(keep_alive_to_ws, print_ws_messages).await;+    Ok(())+}++async fn keep_alive(tx: futures::channel::mpsc::UnboundedSender<Message>) {

might be worth giving this a return type of !

EverlastingBugstopper

comment created time in a month

Pull request review commentcloudflare/wrangler

[dev] fix windows builds and timeouts

 pub fn dev(     let session_id = get_session_id()?;     let preview_id = get_preview_id(target, user, &server_config, &session_id)?; -    // create a new thread to listen for devtools messages-    thread::spawn(move || socket::listen(session_id));--    // spawn tokio runtime on the main thread to handle incoming HTTP requests     let mut runtime = TokioRuntime::new()?;-    runtime.block_on(serve(server_config, preview_id))?;++    let devtools_listener = socket::listen(session_id);+    let server = serve(server_config, preview_id);++    let runners = futures::future::join(devtools_listener, server);++    runtime.block_on(async {+        let (_, _) = runners.await;

also, are you sure that ignoring all failures is what you want here?

EverlastingBugstopper

comment created time in a month

push eventrust-lang/blog.rust-lang.org

Steve Klabnik

commit sha cc69b04e80b05bcd8edecd1becb566d4c7b7ce01

rebuild pages at d18243c

view details

push time in a month

pull request commentrust-lang/rust

Add GitHub issue templates

I like this idea! I think an ICE one would be great. Tracking issue feels kinda weird to me, given that only certain people open them at certain times, but I'm not horribly opposed.

XAMPPRocky

comment created time in a month

pull request commentrust-lang/reference

Add section on semver derived from rust-lang/rfcs#1105

I'm of two minds about this; it's interesting because you're 100% right that this isn't really the language, but it is also the rules for how this specification can change. It's kind of like, meta information. That doesn't mean that I think closing is a bad idea, mind you...

guswynn

comment created time in a month

issue commentrust-lang/rust

Suggest adding undeclared lifetime parameters to struct

Triage: this error is the same today.

cramertj

comment created time in a month

issue commentrust-lang/rust

Display impl for u128 and i128 is slow

Triage: this appears to have gotten even more extreme over time:

running 2 tests
test itoa   ... bench:         216 ns/iter (+/- 28)
test stdlib ... bench:       1,377 ns/iter (+/- 123)

The reproduction involves cargo features and so cannot be done on the playground, details below.

<details>

Cargo.toml:

[package]
name = "itoatest"
version = "0.1.0"
authors = ["Steve Klabnik <steve@steveklabnik.com>"]
edition = "2018"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies.itoa]
version = "*"
features = ["std", "i128"]

in benches/bench.rs:

#![feature(test)]
extern crate test;
extern crate itoa;

use test::Bencher;

#[bench]
fn stdlib(b: &mut Bencher) {
    b.iter(|| {
        let s = format!("{}", u128::max_value());
        std::hint::black_box(s);
    });
}

#[bench]
fn itoa(b: &mut Bencher) {

    b.iter(|| {
        let mut s = String::new();
        itoa::fmt(&mut s, u128::max_value()).unwrap();
        std::hint::black_box(s);
    });
}

</details>

dtolnay

comment created time in a month

issue commentrust-lang/rust

Missing optimization around __rust_alloc and unknown functions if panic=unwind

Triage: this optimization still does not happen.

RalfJung

comment created time in a month

issue commentrust-lang/rust

macro_rules macros should not be serialized through strings in crate metadata.

Triage: it's not clear to me where this lives in the compiler to see if it's something that has been fixed or not; does anyone know where to look? That would help future folks reading this ticket.

eddyb

comment created time in a month

Pull request review commentcloudflare/wrangler

wip: dont reinstall same binary versions

 pub fn install_artifact( }  fn tool_exists(tool_name: &str) -> Result<Option<Download>, failure::Error> {-    if let Ok(path) = which(tool_name) {+    if let Ok(Some((path, version))) = get_latest_installation(tool_name) {         let no_parent_msg = format!("{} There is no path parent", emoji::WARN);         log::debug!("found global {} binary at: {}", tool_name, path.display());-        if !tool_needs_update(tool_name, &path)? {-            return Ok(Some(Download::at(path.parent().expect(&no_parent_msg))));+        if !tool_needs_update(tool_name, version)? {+            Ok(Some(Download::at(path.parent().expect(&no_parent_msg))))+        } else {+            Ok(None)         }+    } else {+        Ok(None)     }--    Ok(None) } -fn tool_needs_update(tool_name: &str, path: &Path) -> Result<bool, failure::Error> {-    let no_version_msg = format!("failed to find version for {}", tool_name);--    let tool_version_output = Command::new(path.as_os_str())-        .arg("--version")-        .output()-        .expect(&no_version_msg);--    if !tool_version_output.status.success() {-        let error = String::from_utf8_lossy(&tool_version_output.stderr);-        log::debug!("could not find version for {}\n{}", tool_name, error);-        return Ok(true);+fn get_latest_installation(tool_name: &str) -> Result<Option<(PathBuf, Version)>, failure::Error> {+    let mut result: Option<(PathBuf, Version)> = None;+    for entry in fs::read_dir(&CACHE.destination)? {+        let entry = entry?;+        let filename = entry.file_name().into_string();+        if let Ok(filename) = filename {+            if filename.starts_with(tool_name) {+                let version = filename+                    .split(&format!("{}-v", tool_name))+                    .collect::<Vec<&str>>()[1];+                let version = Version::parse(version);+                if let Ok(version) = version {+                    let install = Some((entry.path(), version));+                    // if let Some((_, latest_version)) = result {+                    //     if version > latest_version {+                    //         result = install;+                    //     }+                    // } else {+                    //     result = install;+                    // }

try

83 |                     if let Some((_, latest_version)) = &result {

EverlastingBugstopper

comment created time in a month

issue closedrust-lang/rust

totally confused at rules of lifetime with invariance/covarince

Maybe there is not a proper place to ask such a question; But I failed to get an explanation for the following code; I don't know the exactly rule of lifetime, but it looks totally unpredictable.

fn main() {
    //test::test();
    fuck::fuck();
}

mod fuck {
    #![allow(unused_mut)]
    #![allow(unused_imports)]
    #![allow(unused_variables)]
    use std::mem;
    use std::ptr;
    use std::ptr::NonNull;
    use std::alloc::alloc;
    use std::alloc::Layout;
    use std::alloc::dealloc;

    pub trait IsAllocator2 {
        fn alloc<T> () -> *mut T;
        unsafe fn free<T> (_: *mut T);
    }

    pub enum Allocator2 {
    }

    impl IsAllocator2 for Allocator2 {
        fn alloc<T> () -> *mut T {
            let ptr = unsafe {
                alloc(Layout::new::<T>()) as *mut T
            };
            ptr
        }

        unsafe fn free<T> (ptr:*mut T) {
            dealloc(ptr as *mut u8, Layout::new::<T>());
        }
    }

    impl<T> Box<T> {
        pub fn get (&'_ self) -> &'_ T {
            unsafe {
                & *self.ptr
            }
        }

        pub fn new (value: T) -> Self {
            let non_null = Allocator2::alloc();
            unsafe { ptr::write(non_null, value); }
            Self { 
            ptr: non_null,
            }
        }
    }

    pub struct Box<T> {
        ptr: *const T,
    }

    pub fn fuck() {
        let s0 = String::from("Hello, World!");
        let mut p: Box<Option<&String>> = Box::new(Some(&s0)); // p.ptr ==> *const Option<&'s0 String>
        // let mut p: Box<Option<&String>> = Box::new(None);   // p.ptr ==> *const Option<&'static String>
        
        unsafe { 
            let s = String::from("Hello, World!");

            // not pass
            let addr: *mut Option<&'static String> = p.ptr as *mut Option<&'static String>; // requires that `s` is borrowed for `'static` in [Box::new(Some(&s0)), Box::new(None)]
            // pass
            let addr: *mut Option<&String> = p.ptr as *mut Option<&String>;
            // pass
            let addr: *const Option<&'static String> = p.ptr as *const Option<&'static String>; // requires `s0` is borrowed for `'static` in [Box::new(None)]
            // pass
            let addr = p.ptr; 

            let addr = addr as *mut Option<&String>;
            ptr::write(addr, Some(&s));
            println!("{:?}", p.ptr);
        }
        dbg!(p.get());
    }
}

(Playground)

closed time in a month

zylthinking

issue commentrust-lang/rust

totally confused at rules of lifetime with invariance/covarince

In general, https://users.rust-lang.org/ is the right place to ask questions, please ask over there! Thanks!

zylthinking

comment created time in a month

push eventrust-lang/blog.rust-lang.org

Steve Klabnik

commit sha 82166385610c6705aad4b76cc19715cb48544646

rebuild pages at 416b10a

view details

push time in a month

issue closedrust-lang/www.rust-lang.org

Reddit and stackoverflow

Why on the official page <www.rust-lang.org/community> there is no mention of <www.reddit.com/r/rust/> and <stackoverflow.com/tags/rust/info> ?

closed time in a month

LucianoBestia

issue commentrust-lang/www.rust-lang.org

Reddit and stackoverflow

We only link to things that are run by us, and neither of these things are.

LucianoBestia

comment created time in a month

issue closedrust-lang/rust

Make unsafe safer without limiting unsafe

https://users.rust-lang.org/t/what-if-there-was-an-option-to-have-a-garbage-collector-for-unsafe-rust-code/36923?u=smushytaco

Read that whole discuss for all the details, a summary of idea is to have an always optional tracing garbage collector that can be used for unsafe blocks of code so you can make unsafe code safer without limiting unsafe. Rust is a language that revolves around safety so something like this would be a step in the right direction.

closed time in a month

realSmushyTaco
more