profile
viewpoint

orium/rpds 534

Rust Persistent Data Structures

orium/archery 65

Abstract over the atomicity of reference-counting pointers in rust

KeonDSou/checkout 0

An app to model a supermarket checkout

orium/arewewebyet 0

Are we web yet? A simple reckoning of Rust’s readiness for Web-related things.

orium/awesome-rust 0

A curated list of Rust code and resources.

orium/blaze 0

Blazing fast NIO microframework and Http Parser

orium/cargo 0

The Rust package manager

orium/cargo-deadlinks 0

Cargo subcommand for checking your documentation for broken links

orium/cargo-outdated 0

A cargo subcommand for displaying when Rust dependencies are out of date

orium/cargo-src 0

Semantic code navigation for Rust

startedpest-parser/pest

started time in 18 days

issue openedrust-lang/rust

Type system accepts wrong expression type on a statement that is unreachable

Hi everyone. There seems to be bug where an expression with type ! that is made into a "statement" by adding a ; will behave like it has type ! instead of ():

The following code typechecks correctly, even though the function body has type () and the return type is u32:

fn foo() -> u32 {
    panic!();
}

If you replace the body with panic!(); () you correctly get a type error.

Note that this is still sound, since the expression will never finish evaluation.

This happens in stable (1.46.0) as well as nightly 1.49.0-nightly (2020-10-05 a1dfd24).

created time in 19 days

issue openedrust-lang/rust

Type inference seems to pick up the wrong trait bound

Hi. I apologize if this is a dup (I tried to search, but is it not easy to distill this into words to search for). If it's not a dup please update the title to something more meaningful.

When trying to compile (in play)

pub trait Distribution<T> {}

impl Distribution<u16> for () {}

fn gen<K>() -> K
where
    (): Distribution<K> {
    todo!()
}

fn foo<T>() -> u16
where
    (): Distribution<T>,
{
    gen()
}

I get the error:

error[E0308]: mismatched types
  --> src/lib.rs:15:5
   |
11 | fn foo<T>() -> u16
   |        -       --- expected `u16` because of return type
   |        |
   |        this type parameter
...
15 |     gen()
   |     ^^^^^ expected `u16`, found type parameter `T`
   |
   = note:        expected type `u16`
           found type parameter `T`

It it should be able to determine that the hole in gen::<_>() is u16 because that's the return type of foo(). Instead the compiler thinks the hole must be T, which is not true (in fact, if you change the call to gen() to gen::<u16>() the code compiles).

This happens in stable (1.46.0) as well as nightly 1.49.0-nightly (2020-10-05 a1dfd2490a6cb456b92e).

created time in 20 days

issue commentcloudflare/wrangler

Segmentation fault after wrangler executes its command

@codenoid I think the

thread '<unnamed>' panicked at 'Client::new(): reqwest::Error { kind: Builder, source: Normal(ErrorStack([])) }', /home/ken/.cargo/registry/src/github.com-1ecc6299db9ec823/reqwest-0.10.8/src/blocking/client.rs:575:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

is caused by the same issue, so the upstream fix in rust-openssl should fix that as well.

orium

comment created time in 25 days

startedtokio-rs/tracing

started time in 25 days

startedalangibson/awesome-crdt

started time in a month

issue commentrust-lang/rust

Compiler panic with generic-typed nested closures

I was able to minify it a bit further:

fn t7p<A,B>(g: impl Fn(A) -> B) -> impl Fn(A) -> B {
    g
}

fn unify<A,B,C>(f: impl Fn(A) -> B, g: impl Fn(A) -> C) {}

fn unify2<A,B,C>(f:impl Fn(B) -> C, g: impl Fn(A) -> B) {}

fn main() {
    let f = |(_, _)| {  };
    let g = |(a, _)| { a };

    unify2(f, g);

    let t = |env| { |a| { |b| { t7p(g)(((env, a), b)) }}};

    unify(t, t7p(g));
}
bturner-bw

comment created time in a month

startedidris-lang/Idris2

started time in a month

startedsfackler/rust-openssl

started time in a month

startedcharliesome/doslinux

started time in a month

startedwine-staging/wine-staging

started time in a month

startedmingrammer/diagrams

started time in a month

push eventorium/rust

Surya Midatala

commit sha 621cbaafffd057e346049a1a0e9367444ff25d8d

Use crate::mod to disambiguate links

view details

Joshua Nelson

commit sha 9b89d8a7a2bd432613ec5d401a2f4eacc629e1a6

Fix link to `f32` Co-authored-by: Oliver Middleton <olliemail27@gmail.com>

view details

Joshua Nelson

commit sha 25c034c52e90969d53aba3351a204c6ae3473a0c

Use allow(unused_imports) instead of cfg(doc) for imports used only for intra-doc links

view details

Surya Midatala

commit sha 7569cf98f93949880aae66fe843c90490f0f5120

Merge conflict fix: disambiguate f32 -> prim@f32 and u32 -> prim@u32

view details

bors

commit sha 1f2dd3b56aec4d8f97eb0b0552c166ef549d3316

Auto merge of #75903 - jyn514:lint-refactor, r=GuillaumeGomez Warn about unknown or renamed lints in rustdoc Fixes https://github.com/rust-lang/rust/issues/75884. This is best reviewed one commit at a time. r? @GuillaumeGomez Originally I tried to do a much broader refactoring that got rid of `init_lints` altogether. My reasoning is that now the lints aren't being run anymore (after https://github.com/rust-lang/rust/pull/73566), there's no need to ignore them explicitly. But it seems there are still some lints that aren't affected by setting `lint_mod` to a no-op: ``` deny(pub_use_of_private_extern_crate) deny(const_err) warn(unused_imports) ``` (there are possibly more, these are just the ones that failed in the rustdoc test suite). Some of these seem like we really should be warning about, but that's a much larger change and I don't propose to make it here. So for the time being, this just adds the `unknown_lints` and `renamed_or_removed_lints` passes to the list of lints rustdoc warns about.

view details

bors

commit sha 64c4bb0d2bac5f7810d7d0fa6ad846417b3ca60a

Auto merge of #5966 - 1c3t3a:1c3t3a-dev-5819-fix, r=Manishearth Corrects the float_equality_without_abs lint Fixes an issue in the `float_equality_without_abs` lint. The lint suggestion was configured in a way that it lints the whole error and not just the subtraction part. In the current configuration the lint would suggest to change the expression in a wrong way, e.g. ```rust let _ = (a - b) < f32::EPSILON; // before let _ = (a - b).abs(); // after ``` This was dicovered by @flip1995. (See discussion of PR #5952). Also the suggestion is now formatted via `utils::sugg`. changelog: none

view details

bors

commit sha 48717b6f3ce661d2a0d64f7bdfdfb5fd3484ee5b

Auto merge of #75912 - scottmcm:manuallydrop-vs-forget, r=Mark-Simulacrum Suggest `mem::forget` if `mem::ManuallyDrop::new` isn't used I think this communicates the intent more idiomatically, and is shorter anyway. Inspired because [it came up on URLO](https://users.rust-lang.org/t/validity-of-memory-area-after-std-forget/47730/7?u=scottmcm), and it turns out that std had done it too in one spot: ![image](https://user-images.githubusercontent.com/18526288/91203819-e19f2980-e6f2-11ea-9112-835f3b22ce05.png)

view details

Joshua Nelson

commit sha 29399fad5f961f0e235d28ed2f4c68e7a1ae5062

Fix swapped stability attributes This fixes a regression introduced in https://github.com/rust-lang/rust/pull/74855.

view details

Arkadiusz Piekarz

commit sha aa40c028fcb20a47fb214fea2899ff9a8ae88840

Unstable Book: add links to tracking issues for FFI features

view details

bors

commit sha 2d8a3b9181f41d3af9b9f016c5d73b2553e344bf

Auto merge of #75944 - jumbatm:issue-75924-clashing-extern-decl-ice, r=spastorino Fix ICE on unwrap of unknown layout in ClashingExternDeclarations. Fixes #75924.

view details

Mark Rousskov

commit sha c8b240241a94a3a5badcbdcbe1b642a0dd440119

Avoid function-scoping global variables In 2e6f2e885506ee4, we added a main function to the publish_toolstate.py script. Unfortunately, we missed that the Python program implicitly declares global variables in that code, which means that adding a function changes variable scoping and breaks other code. This commit avoids introducing that function and adds a warning to future editors of the code.

view details

Camelid

commit sha 294c1160bb693a77ad2683321b9196352bd837dc

Improve docs for the `const` keyword

view details

Josh Triplett

commit sha 30b7dac745b1555cd96f41977f7d24435cbe7fa2

Set ninja=true by default Ninja substantially improves LLVM build time. On a 96-way system, using Make took 248s, and using Ninja took 161s, a 35% improvement. We already require a variety of tools to build Rust. If someone wants to build without Ninja (for instance, to minimize the set of packages required to bootstrap a new target), they can easily set `ninja=false` in `config.toml`. Our defaults should help people build Rust (and LLVM) faster, to speed up development.

view details

Josh Triplett

commit sha 181ce0e013453fcbe2cc493a37ea77d7cfe6b990

Disable ninja on macOS CI Should be re-enabled when we have a recipe for installing ninja on macOS.

view details

Josh Triplett

commit sha 6149dffff959c0c338ef319b4cea2f49560041e7

Install ninja on CI builders Windows CI builds already install ninja. Install it in all the Docker-based builds as well.

view details

Josh Triplett

commit sha bb39f3555c14275472386ffca637071e22714521

Provide a better diagnostic if ninja isn't installed Let people know that they can set ninja=false if they don't want to install ninja.

view details

rail

commit sha edc05da57d4ad5ab19b5ca64e80e359e487ab2d0

Fix the wrong use of `snippet_with_applicability` This includes a workaround of the issue #5822, the cause of this little mistake.

view details

bors

commit sha 45a83e97ccc70a99794346eb60c11e209c67ecba

Auto merge of #75898 - lcnr:variant-def-recovered, r=petrochenkov VariantDef: move `recovered` into `VariantFlags`

view details

bors

commit sha e45c59e922c4450b8ab136eac38a37000fca9254

Auto merge of #5968 - rail-rain:fix_use_snippet_with_applicability, r=flip1995 Fix the wrong use of `snippet_with_applicability` For the context, please see https://github.com/rust-lang/rust-clippy/issues/5822#issuecomment-680749728 and https://github.com/rust-lang/rust-clippy/issues/5822#issuecomment-680783381. --- changelog: none

view details

Dylan DPC

commit sha 2eec2ecbdec1cae9b749e079a376540d9cc5e304

Rollup merge of #74730 - androm3da:fix_libstd_hexlinux_01, r=dtolnay Hexagon libstd: update type defs

view details

push time in a month

startedmarmelo/streaming-pt

started time in a month

startedgrpc/grpc

started time in 2 months

issue commentcloudflare/wrangler

Segmentation fault after wrangler executes its command

I think I don't have it anymore, but IIRC it only had a dependency on reqwest and nothing else. It is normal for some systems not to be able to reproduce this very easily. It's a non-deterministic race condition based on thread scheduling and timing.

In any case the issue is fixed upstream (https://github.com/sfackler/rust-openssl/issues/1293) and once we get a new release of rust-openssl (which is a transitive dependency of reqwest) with this fix we should be good.

orium

comment created time in 2 months

release orium/archery

v0.4.0

released time in 2 months

pull request commentsfackler/rust-openssl

Make openssl not cleanup at exit, which could lead to race conditions.

@sfackler Can you take a look when you have time? :)

orium

comment created time in 3 months

issue commentmozilla/sccache

allow more easily setting the sccache local size limit

I don't think it is documented, but you can:

$ cat ~/.config/sccache/config
[cache.disk]
dir = "/home/orium/.cache/sccache"
size = 32212254720
wanderview

comment created time in 3 months

push eventorium/rust-openssl

Diogo Sousa

commit sha 2602f49243670c7d3ee92071e2e6e4ef0c43b67b

Make openssl not cleanup at exit, which can lead to race conditions on openssl >= 1.1.1b. Fixes #1293.

view details

push time in 3 months

push eventorium/rust-openssl

Diogo Sousa

commit sha bf3fedc9f3808be893b362f4b665d99e9a0805e2

Make openssl not cleanup at exit, which can lead to race conditions on openssl >= 1.1.1. Fixes #1293.

view details

push time in 3 months

push eventorium/rust-openssl

Diogo Sousa

commit sha ed8626720b921cddb1c95a7ca88a019797bbdfab

Make openssl not cleanup at exit, which can lead to race conditions on openssl >= 1.1.1. Fixes #1293.

view details

push time in 3 months

push eventorium/rust-openssl

Diogo Sousa

commit sha 7f8a970cba2653e5861ed644c026cb186539a688

Make openssl not cleanup at exit, which can lead to race conditions. Fixes #1293.

view details

push time in 3 months

create barnchorium/rust-openssl

branch : fix-1293-openssl-no-atexit

created branch time in 3 months

fork orium/rust-openssl

OpenSSL bindings for Rust

fork in 3 months

fork orium/wrangler

🤠 wrangle your cloudflare workers

https://workers.cloudflare.com

fork in 3 months

issue commentsfackler/rust-openssl

Segfault when using X509Store and not waiting for threads to finish

@sfackler Can this issue be solved by simply OPENSSL_INIT_NO_ATEXIT like @misos1 suggested?

misos1

comment created time in 3 months

issue commentcloudflare/wrangler

Segmentation fault after wrangler executes its command

I could minify the bug to this:

fn main() {
    std::thread::spawn(move || {
        reqwest::blocking::Client::new()
            .get("https://crates.io/api/v1/crates/wrangler")
            .send().unwrap();
    });

    // Just so we write some memory to trigger the bug.
    let mut v = Vec::new();
    for i in 0..100000 {
        v.push(i);
    }
}

Still get the segmentation fault almost all the time. It looks like it might be cause by https://github.com/sfackler/rust-openssl/issues/1293.

Ref https://github.com/rustwasm/wasm-pack/issues/823

orium

comment created time in 3 months

issue commentcloudflare/wrangler

Segmentation fault after wrangler executes its command

It seems the issue goes away if I have a ~/.wrangler/version.toml...

orium

comment created time in 3 months

issue commentcloudflare/wrangler

Segmentation fault after wrangler executes its command

are you able to reproduce this issue if you build with the command cargo build --release --features vendored-openssl or cargo install --features vendored-openssl?

Still have a segmentation fault.

orium

comment created time in 3 months

issue openedcloudflare/wrangler

Segmentation fault after wrangler executes its command

🐛 Bug Report

wrangler crashes with a segmentation fault after running what it needs to run. This apparently only happens with release build and not with debug builds. Reproducible with wrangler version 1.10.3 as well as master (as of b601101); also reproducible with both rustc 1.45.0 (5c1f21c3b 2020-07-13) as well as rustc 1.46.0-nightly (346aec9b0 2020-07-11).

Environment

  • operating system: Arch linux: Linux 5.7.8-arch1-1 #1 SMP PREEMPT Thu, 09 Jul 2020 16:34:01 +0000 x86_64 GNU/Linux
  • output of rustc -V: I've tried multiple version, but now rustc 1.45.0 (5c1f21c3b 2020-07-13)
  • output of node -v: not installed
  • output of wrangler -V: repoducible in 1.10.3 and master (as of b601101)
  • contents of wrangler.toml: empty

Steps to reproduce

You can either cargo install wrangler from crates.io, or in master (as of b601101):

$ cargo build --release
⋮
$ ./target/release/wrangler
The Wrangler Team <wrangler@cloudflare.com>

USAGE:
    wrangler [SUBCOMMAND]

FLAGS:
    -h, --help       Prints help information
    -V, --version    Prints version information

SUBCOMMANDS:
    kv:namespace     Interact with your Workers KV Namespaces
    kv:key           Individually manage Workers KV key-value pairs
    kv:bulk          Interact with multiple Workers KV key-value pairs at once
    route            List or delete worker routes.
    secret           Generate a secret that can be referenced in the worker script
    generate         Generate a new worker project
    init             Create a wrangler.toml for an existing project
    build            Build your worker
    preview          Preview your code temporarily on cloudflareworkers.com
    dev              Start a local server for developing your worker
    publish          Publish your worker to the orange cloud
    config           Set up wrangler with your Cloudflare account
    subdomain        Configure your workers.dev subdomain
    whoami           Retrieve your user info and test your auth config
    tail             Aggregate logs from production worker
    help            Prints this message or the help of the given subcommand(s)
zsh: segmentation fault (core dumped)  ./target/release/wrangler

Running inside lldb:

$ lldb ./target/release/wrangler
(lldb) target create "./target/release/wrangler"
Current executable set to '/home/orium/programming/cloudflare/wrangler/target/release/wrangler' (x86_64).
(lldb) r
Process 550702 launched: '/home/orium/programming/cloudflare/wrangler/target/release/wrangler' (x86_64)
 wrangler 1.10.3
The Wrangler Team <wrangler@cloudflare.com>

USAGE:
    wrangler [SUBCOMMAND]

FLAGS:
    -h, --help       Prints help information
    -V, --version    Prints version information

SUBCOMMANDS:
    kv:namespace     Interact with your Workers KV Namespaces
    kv:key           Individually manage Workers KV key-value pairs
    kv:bulk          Interact with multiple Workers KV key-value pairs at once
    route            List or delete worker routes.
    secret           Generate a secret that can be referenced in the worker script
    generate         Generate a new worker project
    init             Create a wrangler.toml for an existing project
    build            Build your worker
    preview          Preview your code temporarily on cloudflareworkers.com
    dev              Start a local server for developing your worker
    publish          Publish your worker to the orange cloud
    config           Set up wrangler with your Cloudflare account
    subdomain        Configure your workers.dev subdomain
    whoami           Retrieve your user info and test your auth config
    tail             Aggregate logs from production worker
    help            Prints this message or the help of the given subcommand(s)
Process 550702 stopped
* thread #3, name = 'reqwest-interna', stop reason = signal SIGSEGV: invalid address (fault address: 0x18)
    frame #0: 0x00007ffff79bb8e6 libpthread.so.0`__pthread_rwlock_wrlock + 22
libpthread.so.0`__pthread_rwlock_wrlock:
->  0x7ffff79bb8e6 <+22>: movl   0x18(%rdi), %edx
    0x7ffff79bb8e9 <+25>: movl   %fs:0x2d0, %eax
    0x7ffff79bb8f1 <+33>: cmpl   %eax, %edx
    0x7ffff79bb8f3 <+35>: je     0x7ffff79bb960            ; <+144>
(lldb) bt
* thread #3, name = 'reqwest-interna', stop reason = signal SIGSEGV: invalid address (fault address: 0x18)
  * frame #0: 0x00007ffff79bb8e6 libpthread.so.0`__pthread_rwlock_wrlock + 22
    frame #1: 0x00007ffff7bbd02a libcrypto.so.1.1`CRYPTO_THREAD_write_lock + 10
    frame #2: 0x00007ffff7b50ef0 libcrypto.so.1.1`OPENSSL_init_crypto + 800
    frame #3: 0x00007ffff7ce61f2 libssl.so.1.1`OPENSSL_init_ssl + 50
    frame #4: 0x0000555555d4ab8b wrangler`std::sync::once::Once::call_inner::hcff3709ae0293da4 at once.rs:416:21
    frame #5: 0x0000555555be6ac0 wrangler`openssl_sys::init::hb7d4ee155f3460e3 + 64
    frame #6: 0x0000555555be64a3 wrangler`openssl::ssl::connector::ctx::h1740157059bc9ac1 + 19
    frame #7: 0x0000555555be6564 wrangler`openssl::ssl::connector::SslConnector::builder::hbfe4bf78845fde53 + 20
    frame #8: 0x0000555555be241c wrangler`native_tls::imp::TlsConnector::new::h15c5ba45815bd72a + 60
    frame #9: 0x0000555555be2b65 wrangler`native_tls::TlsConnectorBuilder::build::ha2b64693ad06c741 + 21
    frame #10: 0x0000555555b091f4 wrangler`reqwest::connect::Connector::new_default_tls::h602c88545d6f5fda + 52
    frame #11: 0x0000555555ba6427 wrangler`reqwest::async_impl::client::ClientBuilder::build::hb12da7537dfe3e0a + 1223
    frame #12: 0x0000555555b3f008 wrangler`_$LT$core..future..from_generator..GenFuture$LT$T$GT$$u20$as$u20$core..future..future..Future$GT$::poll::hb8ed2143500ac64b + 88
    frame #13: 0x0000555555b5ea2f wrangler`tokio::macros::scoped_tls::ScopedKey$LT$T$GT$::set::ha65e6a297784a429 + 287
    frame #14: 0x0000555555b8622d wrangler`tokio::runtime::basic_scheduler::BasicScheduler$LT$P$GT$::block_on::hb3a58c78048f2d8b + 285
    frame #15: 0x0000555555b147ca wrangler`tokio::runtime::context::enter::h5e9f6f9d15b6ebb6 + 186
    frame #16: 0x0000555555b9276b wrangler`std::sys_common::backtrace::__rust_begin_short_backtrace::h5d994d9dea05c497 + 1371
    frame #17: 0x0000555555b02505 wrangler`core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::h4e89c2fa4cd2a1a3 + 101
    frame #18: 0x0000555555d5842a wrangler`std::sys::unix::thread::Thread::new::thread_start::h3b6d8a0cd87a87c6 [inlined] _$LT$alloc..boxed..Box$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$A$GT$$GT$::call_once::hcf205bcf9b46c587 at boxed.rs:1076:9
    frame #19: 0x0000555555d58424 wrangler`std::sys::unix::thread::Thread::new::thread_start::h3b6d8a0cd87a87c6 [inlined] _$LT$alloc..boxed..Box$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$A$GT$$GT$::call_once::h2d53e2246128f5d8 at boxed.rs:1076
    frame #20: 0x0000555555d5841b wrangler`std::sys::unix::thread::Thread::new::thread_start::h3b6d8a0cd87a87c6 at thread.rs:87
    frame #21: 0x00007ffff79b6422 libpthread.so.0`start_thread + 226
    frame #22: 0x00007ffff7e41bf3 libc.so.6`__clone + 67

Also worth saying that valgrind doesn't see any memory corruption.

created time in 3 months

more