profile
viewpoint

pnkfelix/boxdraw-rs 2

Library for drawing ASCII art rectangles

Manishearth/rust 1

a safe, concurrent, practical language

pnkfelix/BinFiles 1

Little scripts that my ConfigFiles and DotFiles sometimes reference. Meant to be alias of ~/bin/

pnkfelix/ack 0

A replacement for grep for programmers

pnkfelix/ack2 0

ack 2.0

pnkfelix/add3 0

A demo project for illustrating dependency handling in Cargo

pnkfelix/add6 0

Toy crate that depends on past version of add3 crate.

pnkfelix/agents 0

Agent based simulation

issue commentrust-lang/rust

Undefined reference to `getauxval` in function `init_have_lse_atomics` when compiling to nightly `aarch64-unknown-linux-musl`

@XAMPPRocky can you confirm if this is fixed in 1.57 (and also current nightly)?

XAMPPRocky

comment created time in 6 hours

pull request commentrust-lang/rust

Disable LLVM newPM by default

nominating for discussion two weeks from today (2021-12-16), in order to evaluate whether to land by 2021-12-23, or if the problem was addressed by more targetted fix in meantime.

nagisa

comment created time in 6 hours

issue commentrust-lang/rust

Huge compile-time regression in beta/nightly

As a workaround, we have disabled NewPM by default on 1.57 release.

Can someone confirm if this compile-time regression is indeed resolved on 1.57?

bnjbvr

comment created time in 6 hours

issue closedrust-lang/rust

Implied bounds by associated types as function parameters are inconsistent in an unsound way.

Taking a simple trait

trait Trait {
    type Type;
}

impl<T> Trait for T {
    type Type = ();
}

the type <&'a &'b () as Trait>::Type as a function argument gives rise to a 'a: 'b bound, as can be demonstrated by e.g.

fn f<'a, 'b>(s: &'b str, _: <&'a &'b () as Trait>::Type) -> &'a str {
    s
}

However, this bound is apparently not really enforced. I suppose the compiler “simplifies” such a function to f<'a, 'b>(s: &'b str, _: ()) -> &'a str for the caller? So

fn main() {
    let x = String::from("Hello World!");
    let y = f(&x, ());
    drop(x);
    println!("{}", y);
}

compiles fine and produces UB. (playground)

Another implication of the same kind of issue is that a function like

type Type<T> = <T as Trait>::Type;

fn g<'a>(_: Type<&'a ()>) -> &'a str {
    ""
}

fails to compile with a weird error message.

   Compiling playground v0.0.1 (/playground)
error[E0581]: return type references lifetime `'a`, which is not constrained by the fn input types
  --> src/lib.rs:11:30
   |
11 | fn g<'a>(_: Type<&'a ()>) -> &'a str {
   |                              ^^^^^^^

For more information about this error, try `rustc --explain E0581`.

The error code 581 only talks about fn-pointer types (playground)

@rustbot label T-compiler, A-lifetimes, A-typesystem, A-traits, A-associated-items, I-unsound

Originally discovered in a discussion on URLO.

closed time in 6 hours

steffahn

issue commentrust-lang/rust

Implied bounds by associated types as function parameters are inconsistent in an unsound way.

Addressed by PR #91243 and PR #91361, fixed in 1.57 release. Closing.

steffahn

comment created time in 6 hours

issue closedrust-lang/rust

Unsound drop due to imperfect lifetime checks

Looks like it's possible to impl Drop for a stricter lifetime than the one used in the type:

struct Wrapper<'a, T>(&'a T)
where
    T: 'a;

impl<'a, T> Drop for Wrapper<'a, T>
where
    T: 'static, // ayy ayy
{
    fn drop(&mut self) {
      //
    }
}

... which allows to essentially transmute from T: 'a to T: 'static, leading to unsoundness:

use std::{
    fmt::Debug,
    thread::{sleep, spawn},
    time::Duration,
};

struct Wrapper<'a, T>(&'a T)
where
    T: Clone + Debug + Send + 'a;

impl<'a, T> Drop for Wrapper<'a, T>
where
    T: Clone + Debug + Send + 'static,
{
    fn drop(&mut self) {
        let value = self.0.to_owned();

        spawn(move || {
            // Wait for `main()` to finish dropping `self.0`
            sleep(Duration::from_millis(100));

            // Use-after-free 
            println!("value: {:?}", value);
        });
    }
}

#[derive(Clone, Copy, Debug)]
struct StringWrapper<'a>(&'a String);

fn main() {
    let _ = Wrapper(&StringWrapper(&String::from("Hello!")));

    // Wait for the thread to complete
    sleep(Duration::from_secs(1));
}

On my machine, it prints:

value: StringWrapper("SU�Y\u{5}\u{0}")

closed time in 6 hours

Patryk27

issue commentrust-lang/rust

Unsound drop due to imperfect lifetime checks

we ended up backporting #90840 itself to the 1.57 release. So this is now closed.

Patryk27

comment created time in 6 hours

issue commentrust-lang/rust

Miscompilation where binding only some fields leaks the others

FYI This is addressed by PR #90788, which will be part of the Rust 1.58 release (stable in six weeks).

mk12

comment created time in 6 hours

issue openedWhiley/WhileyCompiler

wdk 0.5.3 README example malfunctions

The README for wdk 0.5.3 (and perhaps earlier) has a "Run" section that says the following:

With the `PATH` setup correctly, you should be able to run the `wy` tool
to compile Whiley programs as follows:

    % cd examples
    % wy compile hello-world.whiley

When I tried to follow these instructions, I encountered a few problems.

First: The instructions say to go into an examples/ directory. But, perhaps due to a typo, there is no such directory. There is an example/ directory.

Second: Once in the example/ directory, running wy compile hello-world.whiley produces the following result:

wdk-v0.5.3/example % wy compile hello-world.whiley
Internal failure: Index 0 out of bounds for length 0

To be fair, the example/ directory does not have any file named hello-world.whiley. There is a source file example/src/main.whiley...

Third: Even if one does attempt wy compile src/main.whiley from that example/ directory, you still get the same Internal failure.

(Was the README written for a different source code repository or something?)

created time in 18 hours

PR closed rust-lang/rust

variant of PR 87770 with limited scope for backport. T-compiler S-waiting-on-review

This version does not attempt to resolve the problem that is illustrated by src/test/ui/const-generics/generic_const_exprs/drop_impl.rs (a problem that relies on nightly features to demonstrate anyway).

My thinking is that this is a better choice for backporting to stable and beta.

Fix #90838 (which was closed by accident by #90840, which only landed on nightly, so far).

+30 -19

7 comments

4 changed files

pnkfelix

pr closed time in 8 days

pull request commentrust-lang/rust

variant of PR 87770 with limited scope for backport.

(Closing; We'll backport #90840 instead of this.)

pnkfelix

comment created time in 8 days

pull request commentrust-lang/rust

variant of PR 87770 with limited scope for backport.

This implementation looks good to me, but I don't know if its strictly better than #90840 for backport.

Does the new test you added also pass on master? We probably want that test added regardless.

The test is taken from #90840. So it already is on master.

pnkfelix

comment created time in 8 days

push eventrust-lang/rustc-perf

Felix S. Klock II

commit sha 410efd1f7b1b1831741496bf12abca673482b6fd

performance triage for this week.

view details

Felix S Klock II

commit sha 767094cd1c2f153c20ad96cc24dc0af8d1405edd

Merge pull request #1110 from pnkfelix/triage-2021-11-23 performance triage for this week.

view details

push time in 9 days

PR opened rust-lang/this-week-in-rust

add performance triage report for this week

the PR technically hasn't landed yet but I believe it will and I believe I predicted the file name correctly.

The aforementioned PR: https://github.com/rust-lang/rustc-perf/pull/1110

+7 -14

0 comment

1 changed file

pr created time in 9 days

push eventpnkfelix/this-week-in-rust

Felix S Klock II

commit sha d1f5486e9f2b0c7c0d25cc64ae1b3e7c3e23992e

add performance triage report for this week

view details

push time in 9 days

PR closed rust-lang/rustc-perf

a (new, tiny) triage driving script

I got tired of extracting PARENT commit by hand, so I finally decided to make this script.

(What? do I hear people saying "rewrite it in rust" ? LOL)

+72 -0

2 comments

2 changed files

pnkfelix

pr closed time in 9 days

pull request commentrust-lang/rustc-perf

a (new, tiny) triage driving script

(maybe someone else will be inspired to write this in Rust. I don't feel like porting it but I totally get that it doesn't cover the Windows case.)

pnkfelix

comment created time in 9 days

PR opened rust-lang/rustc-perf

performance triage for this week.
+124 -0

0 comment

1 changed file

pr created time in 9 days

create barnchpnkfelix/rustc-perf

branch : triage-2021-11-23

created branch time in 9 days

issue openedrust-lang/rustc-perf

perf triage classification of PR 89611 was "probably changed"; why not definite?

Looking at the performance report linked here:

Benchmark & Profile Scenario % Change Significance Factor ?
encoding opt full -0.80%? 2.21x
encoding opt incr-full -0.72%? 2.36x
coercions check incr-patched: println -0.64% 4.82x
helloworld debug incr-full -0.53%? 2.07x
helloworld debug incr-unchanged -0.52% 4.79x
coercions check incr-unchanged -0.51% 7.92x
helloworld debug full -0.45%? 1.83x
coercions opt incr-unchanged -0.43% 5.67x
ripgrep opt incr-unchanged -0.42% 2.73x
cranelift-codegen opt incr-unchanged 0.38%? 1.81x
coercions debug incr-unchanged -0.36% 3.87x
issue-58319 debug incr-unchanged -0.34% 2.09x
token-stream-stress debug full -0.31% 1.74x
token-stream-stress debug incr-unchanged -0.31% 2.25x
coercions doc full -0.25% 2.89x
unicode_normalization check incr-unchanged -0.24% 3.79x
coercions check full -0.24% 3.79x
issue-58319 debug incr-full -0.24% 2.00x
tuple-stress debug incr-unchanged -0.24% 1.94x
helloworld opt incr-patched: println -0.21% 2.55x
helloworld opt incr-unchanged -0.20% 2.19x
coercions check incr-full -0.20% 5.63x

why isn't this classified as a definite improvement in the performance triage script?

Yes, a lot of them have question marks on them (though I'm not sure the performance triage script includes the question marks in its weighting at this point, based on what I saw elsewhere), but even if you remove the question mark cases, you're still left with e.g.

Benchmark & Profile Scenario % Change Significance Factor ?
coercions check incr-patched: println -0.64% 4.82x
helloworld debug incr-unchanged -0.52% 4.79x
coercions check incr-unchanged -0.51% 7.92x

which seems like it should have been enough for being classified as a performance win, not a "probably" ?

created time in 9 days

pull request commentrust-lang/rust

Manually outline error on incremental_verify_ich

Visiting for weekly performance triage.

  • The driving force for this change was to reduce the critical path in bootstrap time, so the most important thing to look at is the bootstrap timing data. Specifically: while there is a big mix of ups and downs on the percentages column, the crate that tak
    es the longest to compile (rustc_query_impl, the laggard at over 80 seconds of compilation time).
  • This PR brings the compilation time of rustc_query_impl from 87.1 seconds down to 85.6 seconds, a -1.8% improvement.
  • That is consistent with the predicted effect of the PR, and justifies the isolated impact on instruction counts.

@rustbot label: +perf-regression-triaged

Mark-Simulacrum

comment created time in 9 days

pull request commentrust-lang/rust

Point at source of trait bound obligations in more places

Visiting for weekly performance triage.

Many other PR's over the past week have observed a similar delta to incr-unchanged builds of inflate, so I am dismissing that change as spurious. (The current hypothesis is that it is due to https://github.com/rust-lang/rustc-perf/issues/1105.)

Other than that, there were a broad set of small regressions. Putting aside the ones tagged with ? ("noisy"), there are 19 benchmarks that regressed by 0.10% to 0.42%. This seems like an acceptable cost.

@rustbot label: +perf-regression-triaged

estebank

comment created time in 9 days

pull request commentrust-lang/rust

Update stdarch

Visited for weekly performance triage.

The only benchmark that regressed is "html5ever debug" ("incr-patched: println" and "incr-unchanged"), and only by a relatively small amount. This seems acceptable to me, compared to the effort involved in figuring out how this change could be related to that effect.

@rustbot label: +perf-regression-triaged

ehuss

comment created time in 9 days

pull request commentrust-lang/rust

Rollup of 8 pull requests

Moving perf-regression label to PR #90750

@rustbot label: +perf-regression-triaged

JohnTitor

comment created time in 9 days

pull request commentrust-lang/rust

rustdoc: Replace where-bounded Clean impl with simple function

@rustbot label: +perf-regression

camelid

comment created time in 9 days

pull request commentrust-lang/rust

rustdoc: Replace where-bounded Clean impl with simple function

This PR has been tagged as being the root cause of the performance regression flagged here.

camelid

comment created time in 9 days

pull request commentrust-lang/rust

std: Get the standard library compiling for wasm64

Visiting for performance triage.

There were a lot of various changes in this PR, such as updates to dependencies (compiler_builtins and dlmalloc). We probably shoud have done a pre-merge rust-timer run on this PR.

The flagged regressions of magnitude greater than 0.5% are isolated to "issue-88862 check" and "style-servo check". The improvements tended to outweigh the regressions. For the most part almost all significant performance effects are isolated to check builds.

@rustbot label +perf-regression-triaged

alexcrichton

comment created time in 9 days

issue commentrust-lang/rust

DWARF info for `static` vars in lib crates has stopped being produced reliably in LTO builds

It looks to me like the problem still reoccurs on the current nightly:

% rustup override set nightly-2021-11-22
info: using existing install for 'nightly-2021-11-22-x86_64-unknown-linux-gnu'
info: override toolchain for '/media/pnkfelix/Rust/rust-90357/objdir-dbgopt/rustc-dwarf-regression-repro' set to 'nightly-2021-11-22-x86_64-unknown-linux-gnu'

  nightly-2021-11-22-x86_64-unknown-linux-gnu unchanged - rustc 1.58.0-nightly (65f3f8b22 2021-11-21)

% rustup show active-toolchain
nightly-2021-11-22-x86_64-unknown-linux-gnu (directory override for '/media/pnkfelix/Rust/rust-90357/objdir-dbgopt/rustc-dwarf-regression-repro')
% rustc --version
rustc 1.58.0-nightly (65f3f8b22 2021-11-21)
% cargo clean
% cargo build --release --verbose
   Compiling nodwarfrepro v0.1.0 (/media/pnkfelix/Rust/rust-90357/objdir-dbgopt/rustc-dwarf-regression-repro)
     Running `rustc --crate-name nodwarfrepro --edition=2018 src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C linker-plugin-lto -C debuginfo=2 -C metadata=f2ccefc4246296b8 -C extra-filename=-f2ccefc4246296b8 --out-dir /media/pnkfelix/Rust/rust-90357/objdir-dbgopt/rustc-dwarf-regression-repro/target/release/deps -L dependency=/media/pnkfelix/Rust/rust-90357/objdir-dbgopt/rustc-dwarf-regression-repro/target/release/deps`
     Running `rustc --crate-name nodwarfrepro --edition=2018 src/main.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type bin --emit=dep-info,link -C opt-level=3 -C lto -C debuginfo=2 -C metadata=f4b2592c51b39d90 -C extra-filename=-f4b2592c51b39d90 --out-dir /media/pnkfelix/Rust/rust-90357/objdir-dbgopt/rustc-dwarf-regression-repro/target/release/deps -L dependency=/media/pnkfelix/Rust/rust-90357/objdir-dbgopt/rustc-dwarf-regression-repro/target/release/deps --extern nodwarfrepro=/media/pnkfelix/Rust/rust-90357/objdir-dbgopt/rustc-dwarf-regression-repro/target/release/deps/libnodwarfrepro-f2ccefc4246296b8.rlib`
    Finished release [optimized + debuginfo] target(s) in 2.55s
% dwarfdump target/release/nodwarfrepro | grep THE_STATIC
% 

<details>

<summary>For completeness, here is a transcript showing the behavior that is expected, from nightly-2021-09-22</summary>

% rustup override set nightly-2021-09-22
info: using existing install for 'nightly-2021-09-22-x86_64-unknown-linux-gnu'
info: override toolchain for '/media/pnkfelix/Rust/rust-90357/objdir-dbgopt/rustc-dwarf-regression-repro' set to 'nightly-2021-09-22-x86_64-unknown-linux-gnu'

  nightly-2021-09-22-x86_64-unknown-linux-gnu unchanged - rustc 1.57.0-nightly (ac2d9fc50 2021-09-21)

% rustup show active-toolchain
nightly-2021-09-22-x86_64-unknown-linux-gnu (directory override for '/media/pnkfelix/Rust/rust-90357/objdir-dbgopt/rustc-dwarf-regression-repro')
% rustc --version
rustc 1.57.0-nightly (ac2d9fc50 2021-09-21)
% cargo clean
% cargo build --release --verbose
   Compiling nodwarfrepro v0.1.0 (/media/pnkfelix/Rust/rust-90357/objdir-dbgopt/rustc-dwarf-regression-repro)
     Running `rustc --crate-name nodwarfrepro --edition=2018 src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C linker-plugin-lto -C debuginfo=2 -C metadata=f2ccefc4246296b8 -C extra-filename=-f2ccefc4246296b8 --out-dir /media/pnkfelix/Rust/rust-90357/objdir-dbgopt/rustc-dwarf-regression-repro/target/release/deps -L dependency=/media/pnkfelix/Rust/rust-90357/objdir-dbgopt/rustc-dwarf-regression-repro/target/release/deps`
     Running `rustc --crate-name nodwarfrepro --edition=2018 src/main.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type bin --emit=dep-info,link -C opt-level=3 -C lto -C debuginfo=2 -C metadata=f4b2592c51b39d90 -C extra-filename=-f4b2592c51b39d90 --out-dir /media/pnkfelix/Rust/rust-90357/objdir-dbgopt/rustc-dwarf-regression-repro/target/release/deps -L dependency=/media/pnkfelix/Rust/rust-90357/objdir-dbgopt/rustc-dwarf-regression-repro/target/release/deps --extern nodwarfrepro=/media/pnkfelix/Rust/rust-90357/objdir-dbgopt/rustc-dwarf-regression-repro/target/release/deps/libnodwarfrepro-f2ccefc4246296b8.rlib`
    Finished release [optimized + debuginfo] target(s) in 2.78s
% dwarfdump target/release/nodwarfrepro | grep THE_STATIC
                        DW_AT_name                  THE_STATIC
                        DW_AT_linkage_name          _ZN12nodwarfrepro10THE_STATIC17he3077d0fbb05bed3E
global die-in-sect 0x00000089, cu-in-sect 0x00000071, die-in-cu 0x00000023, cu-header-in-sect 0x00000066 'THE_STATIC'
name at offset 0x000000d1, length   10 is 'THE_STATIC'
name at offset 0x00000102, length   49 is '_ZN12nodwarfrepro10THE_STATIC17he3077d0fbb05bed3E'
% 

</details>

cbiffle

comment created time in 10 days

issue commentrust-lang/rust

DWARF info for `static` vars in lib crates has stopped being produced reliably in LTO builds

@cuviper it seems like it still reproduces to me on nightly.

% rustup show active-toolchain
nightly-x86_64-unknown-linux-gnu (directory override for '/media/pnkfelix/Rust/rust-90357/objdir-dbgopt/rustc-dwarf-regression-repro')
% rustc --version
rustc 1.58.0-nightly (65f3f8b22 2021-11-21)
% cargo clean
% cargo build --release --verbose
   Compiling nodwarfrepro v0.1.0 (/media/pnkfelix/Rust/rust-90357/objdir-dbgopt/rustc-dwarf-regression-repro)
     Running `rustc --crate-name nodwarfrepro --edition=2018 src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-typ\
e lib --emit=dep-info,metadata,link -C opt-level=3 -C linker-plugin-lto -C debuginfo=2 -C metadata=f2ccefc4246296b8 -C extra-filename=-\
f2ccefc4246296b8 --out-dir /media/pnkfelix/Rust/rust-90357/objdir-dbgopt/rustc-dwarf-regression-repro/target/release/deps -L dependency\
=/media/pnkfelix/Rust/rust-90357/objdir-dbgopt/rustc-dwarf-regression-repro/target/release/deps`
     Running `rustc --crate-name nodwarfrepro --edition=2018 src/main.rs --error-format=json --json=diagnostic-rendered-ansi --crate-ty\
pe bin --emit=dep-info,link -C opt-level=3 -C lto -C debuginfo=2 -C metadata=f4b2592c51b39d90 -C extra-filename=-f4b2592c51b39d90 --out\
-dir /media/pnkfelix/Rust/rust-90357/objdir-dbgopt/rustc-dwarf-regression-repro/target/release/deps -L dependency=/media/pnkfelix/Rust/\
rust-90357/objdir-dbgopt/rustc-dwarf-regression-repro/target/release/deps --extern nodwarfrepro=/media/pnkfelix/Rust/rust-90357/objdir-\
dbgopt/rustc-dwarf-regression-repro/target/release/deps/libnodwarfrepro-f2ccefc4246296b8.rlib`
    Finished release [optimized + debuginfo] target(s) in 2.55s
% dwarfdump target/release/nodwarfrepro | grep THE_STATIC
% 
cbiffle

comment created time in 10 days

more