profile
viewpoint
Camelid camelid Rust compiler contributor and compiler enthusiast.

camelid/rust 1

Empowering everyone to build reliable and efficient software.

camelid/backtrace-rs 0

Backtraces in Rust

camelid/blog.rust-lang.org 0

The Rust Programming Language Blog

camelid/cargo 0

The Rust package manager

camelid/cargo-bisect-rustc 0

Bisects rustc, either nightlies or CI artifacts

camelid/chalk 0

An implementation and definition of the Rust trait system using a PROLOG-like logic solver

camelid/colophon 0

Scrape open-access articles, filter to a particular topic, and import to your library's catalog.

camelid/crates.io 0

Source code for crates.io

camelid/docs.rs 0

crates.io documentation generator

camelid/download.servo.org 0

download.servo.org landing page

Pull request review commentrust-lang/rust

driver: Only output ANSI logging if connected to a terminal

 fn main_args(args: &[String]) -> MainResult {             early_error(ErrorOutputType::default(), &err.to_string());         }     };+    let sopts = build_session_options(&matches);

I'm unsure if this is the best way to do it since I think we'll then be calling build_session_options() twice, once in rustdoc and once in rustc. But I don't know of a good alternative.

camelid

comment created time in 9 minutes

PullRequestReviewEvent

Pull request review commentrust-lang/rust

f64: Refactor collapsible_if

 impl f64 {     fn log_wrapper<F: Fn(f64) -> f64>(self, log_fn: F) -> f64 {         if !cfg!(any(target_os = "solaris", target_os = "illumos")) {             log_fn(self)-        } else {-            if self.is_finite() {-                if self > 0.0 {-                    log_fn(self)-                } else if self == 0.0 {-                    Self::NEG_INFINITY // log(0) = -Inf-                } else {-                    Self::NAN // log(-n) = NaN-                }-            } else if self.is_nan() {-                self // log(NaN) = NaN-            } else if self > 0.0 {-                self // log(Inf) = Inf+        } else if self.is_finite() {+            if self > 0.0 {+                log_fn(self)+            } else if self == 0.0 {+                Self::NEG_INFINITY // log(0) = -Inf             } else {-                Self::NAN // log(-Inf) = NaN+                Self::NAN // log(-n) = NaN

You're right, that is a very misleading diff.

wcampbell0x2a

comment created time in 11 minutes

PullRequestReviewEvent

push eventcamelid/rust

Camelid

commit sha 7ed008efba65867182d920ac8d47b628d9af8a93

fmt

view details

push time in 12 minutes

Pull request review commentrust-lang/rust

f64: Refactor collapsible_if

 impl f64 {     fn log_wrapper<F: Fn(f64) -> f64>(self, log_fn: F) -> f64 {         if !cfg!(any(target_os = "solaris", target_os = "illumos")) {             log_fn(self)-        } else {-            if self.is_finite() {-                if self > 0.0 {-                    log_fn(self)-                } else if self == 0.0 {-                    Self::NEG_INFINITY // log(0) = -Inf-                } else {-                    Self::NAN // log(-n) = NaN-                }-            } else if self.is_nan() {-                self // log(NaN) = NaN-            } else if self > 0.0 {-                self // log(Inf) = Inf+        } else if self.is_finite() {+            if self > 0.0 {+                log_fn(self)+            } else if self == 0.0 {+                Self::NEG_INFINITY // log(0) = -Inf             } else {-                Self::NAN // log(-Inf) = NaN+                Self::NAN // log(-n) = NaN

Is this definitely correct? Just want to double-check.

wcampbell0x2a

comment created time in 14 minutes

PullRequestReviewEvent

Pull request review commentrust-lang/rust

[WIP] Add size-limited command interface

 impl Command {     pub fn creation_flags(&mut self, flags: u32) {         self.flags = flags;     }+    #[allow(dead_code)]

There seem to be a lot of these, some pre-existing 🤷

Artoria2e5

comment created time in 15 minutes

PullRequestReviewEvent

push eventcamelid/rust

Camelid

commit sha 8d17bfe77b216414c57706d4bbf4bb6ff2511eeb

rustdoc: Update to support new driver colors flag

view details

push time in 18 minutes

PR opened rust-lang/rust

Link to pass docs from NRVO module docs A-mir-opt-nrvo T-compiler T-doc

It can be easy to miss that this is documented on the pass's struct if you are looking at the module docs.

Cc https://rust-lang.zulipchat.com/#narrow/stream/189540-t-compiler.2Fwg-mir-opt/topic/what.20is.20NRVO.3F

+2 -0

0 comment

1 changed file

pr created time in 33 minutes

create barnchcamelid/rust

branch : mir-opt-nrvo-docs

created branch time in 33 minutes

pull request commentrust-lang/rust

driver: Only output ANSI logging if connected to a terminal

@jyn514 Okay, I finally got the new driver option working. Unfortunately, I think all the other tools that use the driver (rustdoc, miri, etc.) will have to be updated :/

Or do rustc options get passed through to rustdoc and the rest, and I can just access the option there? Not sure how to proceed.

camelid

comment created time in an hour

push eventcamelid/rust

Camelid

commit sha 0de35e8214f326649aff537bff3d871fad071f49

driver: Add option to always color log output Requested by @jyn514. I had to refactor the driver a bit so that I could read the option before the compiler is started. rustdoc and the other tools that use the driver will also need to be updated.

view details

push time in an hour

issue commentrust-lang/rust

`./x.py build --stage 2` does not build stage 1 rustdoc

Yeah, it's just because I'm testing stuff with Miri :)

camelid

comment created time in 2 hours

pull request commentrust-lang/rust

Make CTFE able to check for UB...

(Added S-waiting-on-author so this isn't lost.)

oli-obk

comment created time in 2 hours

pull request commentrust-lang/rust

Add test for #59352

Assigned Amanieu since I know they do some codegen stuff.

bugadani

comment created time in 2 hours

pull request commentrust-lang/rust

Add test for #59352

Not sure what happened here: This PR never got an assignee! Must have been a highfive bug.

bugadani

comment created time in 2 hours

issue closedrust-lang/rust

`./x.py build --stage 2` does not build stage 1 rustdoc

$ ./x.py build --stage 2
$ rustdoc +r2stage1 somefile.rs
error: 'rustdoc' is not installed for the toolchain 'r2stage1'
To install, run `rustup component add rustc --toolchain r2stage1`
$ ./x.py build
...
Copying stage1 std from stage1 (x86_64-apple-darwin -> x86_64-apple-darwin / x86_64-apple-darwin)
Building rustdoc for stage1 (x86_64-apple-darwin)
   Compiling rustdoc v0.0.0 (/Users/user/rust2/src/librustdoc)
   Compiling rustdoc-tool v0.0.0 (/Users/user/rust2/src/tools/rustdoc)
    Finished release [optimized + debuginfo] target(s) in 2m 13s
Build completed successfully in 0:02:18
$ rustdoc +r2stage1 somefile.rs
# works fine

Cc @jyn514 -- you know rustdoc and x.py :)

closed time in 2 hours

camelid

issue commentrust-lang/rust

`./x.py build --stage 2` does not build stage 1 rustdoc

You're probably right 🤦

I'm so used to using +stage1 that I forgot it's only for stage1.

camelid

comment created time in 2 hours

PR closed rust-lang/rust

Keep code coloring in search results short text S-waiting-on-author T-rustdoc

Fixes #32040.

Screenshot from 2020-01-31 14-11-32

r? @kinnison

+12 -1

31 comments

1 changed file

GuillaumeGomez

pr closed time in 3 hours

pull request commentrust-lang/rust

Keep code coloring in search results short text

Closing in favor of #77686.

GuillaumeGomez

comment created time in 3 hours

issue openedrust-lang/rust

`./x.py build --stage 2` does not build rustdoc

$ ./x.py build --stage 2
$ rustdoc +r2stage1 somefile.rs
error: 'rustdoc' is not installed for the toolchain 'r2stage1'
To install, run `rustup component add rustc --toolchain r2stage1`
$ ./x.py build
...
Copying stage1 std from stage1 (x86_64-apple-darwin -> x86_64-apple-darwin / x86_64-apple-darwin)
Building rustdoc for stage1 (x86_64-apple-darwin)
   Compiling rustdoc v0.0.0 (/Users/user/rust2/src/librustdoc)
   Compiling rustdoc-tool v0.0.0 (/Users/user/rust2/src/tools/rustdoc)
    Finished release [optimized + debuginfo] target(s) in 2m 13s
Build completed successfully in 0:02:18
$ rustdoc +r2stage1 somefile.rs
# works fine

Cc @jyn514 -- you know rustdoc and x.py :)

created time in 3 hours

create barnchcamelid/rust

branch : improve-drop_in_place-docs-wording

created branch time in 3 hours

PR opened rust-lang/rust

Improve wording of `core::ptr::drop_in_place` docs

And two small intra-doc link conversions in std::{f32, f64}.

+5 -5

0 comment

3 changed files

pr created time in 3 hours

issue commentrust-lang/rust

ICE: trying to compare incompatible ctors while building rustfmt

searched nightlies: from nightly-2020-10-28 to nightly-2020-10-30 regressed nightly: nightly-2020-10-30 searched commits: from https://github.com/rust-lang/rust/commit/31ee872db5aae4750e3da1ca4ed1523c4356947f to https://github.com/rust-lang/rust/commit/6bdae9edd0cc099daa6038bca469dc09b6fc078a regressed commit: https://github.com/rust-lang/rust/commit/f9187adaef2005b903f666bf323ac675cadf8407

<details> <summary>bisected with <a href='https://github.com/rust-lang/cargo-bisect-rustc'>cargo-bisect-rustc</a> v0.6.0</summary>

Host triple: x86_64-apple-darwin Reproduce with:

cargo bisect-rustc --preserve --regress=ice --start=2020-10-28 

</details>


It was #78430.

matthiaskrgr

comment created time in 5 hours

push eventcamelid/rust

Ian Jackson

commit sha dbb058302388824b717816b42bbfbc00330fa36d

docs: Reword `str::strip_prefix` and `strip_suffix` a bit "Some is returned with <some value>" is an awkward construction. The use of the passive voice is a bit odd, and doesn't seem like the house style. So say instead "returns X, wrapped in `Some`", for which there is some other precedent in stdlib. Instead of repeating "with the prefix removed", say "after the prefix". This is a bit clearer that the original is not modified. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

view details

Ian Jackson

commit sha b7974bd3cd2df94d19dad467fa09a79f78067559

docs: Reword `slice::strip_prefix` and `strip_suffix` a bit The stabilisation issue, #73413, has an open item for documentation. I looked at the docs and it is all there, but I felt it could do with some minor wording improvement. I looked at the `str::strip_prefix` docs for a template. (That resulted in me slightly changing that doc too.) I de-linkified `None` and `Some`, as I felt that rather noisy.. I searched stdlib, and these don't seem to be usually linkified. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

view details

Ian Jackson

commit sha 4549c777e690c69552dea2f2ea04c56074430546

docs: Rewrap `str::strip_prefix` and `strip_suffix` back to 100 Requested-by: @LukasKalbertodt Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

view details

Ian Jackson

commit sha 6f5e96fb5fcd7fb6c67c61027615abd96a9e5e69

docs: Rewrap `slice::strip_prefix` and `strip_suffix` back to 100 Requested-by: @LukasKalbertodt Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

view details

Ian Jackson

commit sha 22358c650ba72e29a35076e243d84d47915ff35c

docs: `slice::strip_prefix` and `strip_suffix`, fold in sentence Roughly as requested by @LukasKalbertodt. I still prefer clearly making these two cases. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

view details

Geoffrey Copin

commit sha bb0ce32423aefcb8b9eb587881973f56a6a6b0ee

Lint unnecessary int-to-int and float-to-float casts

view details

Tim Nielens

commit sha 915ce3608724e6c900d1b5eb4412cac2fcace33a

manual_unwrap_or / support Result::unwrap_or

view details

Takayuki Nakata

commit sha 114cb218f3ab2a709e3017c380790dd6e407132c

Remove an extra blank line in doc examples

view details

Patrick José Pereira

commit sha ec23db9496807f6c962b74fe0d6bf15be6c6d35b

Add linter for a single element for loop Signed-off-by: Patrick José Pereira <patrickelectric@gmail.com>

view details

Patrick José Pereira

commit sha ba1ca19c3bec20401a4cb13e5186c4c5952e94cc

tests: if_same_then_else2: Ignore single_element_loop lint Signed-off-by: Patrick José Pereira <patrickelectric@gmail.com>

view details

Tim Nielens

commit sha 65b52d84f83586752bff2834410e131290dc0155

needless-lifetime / multiple where clause predicates regression

view details

Daniel Smith

commit sha 57bf80f77626b134faaf2cd95664403627fba0da

Add lint for holding RefCell Ref across an await

view details

Daniel Smith

commit sha 8727169f7243c87e3708d99e9602562370f01a1a

fmt

view details

Daniel Smith

commit sha 070a751d4cf350a71901f75bc99ca0e0922a3133

update_lints

view details

Daniel Smith

commit sha 0f4abbf99a6f1ed783ea6935c83427c2aef95144

Better naming post copy/paste

view details

Daniel Smith

commit sha b3a427d8733a549b11f9bc88eceb31c857851411

Add another test case

view details

Daniel Smith

commit sha 3ed69cdb13e5953467f9d849d7ad480479ca01d6

Move existing lint into shared file

view details

Daniel Smith

commit sha ee20ebadafc9b2e4995015097e376c0a866d84af

Move refcell lint into shared module

view details

Daniel Smith

commit sha d8c6bce4407b1c99ed961f75a093ffe767818069

Convert the await holding lints to correctness

view details

Daniel Smith

commit sha 86f2b29d2ff33862264e2e6dfdc7cc20ad054ad1

Merge lints into one pass

view details

push time in 5 hours

pull request commentrust-lang/rust

driver: Only output ANSI logging if connected to a terminal

I've never added a driver CLI option before, so I would appreciate it if you could give me general instructions on how to do it! I looked at the "Command-line arguments" chapter in the rustc-dev-guide, but it doesn't seem to give instructions on how to add an option.

camelid

comment created time in 5 hours

Pull request review commentrust-lang/miri

Update locally-built rustc instructions

 tracing) enabled.  The setup for a local rustc works as follows: ```sh+# Clone the rust-lang/rust repo. git clone https://github.com/rust-lang/rust/ rustc cd rustc cp config.toml.example config.toml # Now edit `config.toml` and set `debug-assertions = true`.-# This step can take 30 minutes and more.-./x.py build src/rustc++# Build a stage 2 rustc.+# This step can take 30 minutes or more.+./x.py build compiler/rustc --stage 2 # If you change something, you can get a faster rebuild by doing-./x.py --keep-stage 0 build src/rustc+./x.py --keep-stage 0 build compiler/rustc --stage 2

Huh, okay.

camelid

comment created time in 6 hours

PullRequestReviewEvent

push eventcamelid/miri

Camelid

commit sha 8a7b5a66dfbcb36b2a1ab11d167873939fdaf1de

Fix `x.py` commands This should make them faster, at least according to @jyn514. Co-authored-by: Joshua Nelson <joshua@yottadb.com>

view details

push time in 6 hours

Pull request review commentrust-lang/miri

Update locally-built rustc instructions

 tracing) enabled.  The setup for a local rustc works as follows: ```sh+# Clone the rust-lang/rust repo. git clone https://github.com/rust-lang/rust/ rustc cd rustc cp config.toml.example config.toml # Now edit `config.toml` and set `debug-assertions = true`.-# This step can take 30 minutes and more.-./x.py build src/rustc++# Build a stage 2 rustc.+# This step can take 30 minutes or more.+./x.py build compiler/rustc --stage 2
./x.py build --stage 2 library/std
camelid

comment created time in 6 hours

PullRequestReviewEvent

Pull request review commentrust-lang/miri

Update locally-built rustc instructions

 tracing) enabled.  The setup for a local rustc works as follows: ```sh+# Clone the rust-lang/rust repo. git clone https://github.com/rust-lang/rust/ rustc cd rustc cp config.toml.example config.toml # Now edit `config.toml` and set `debug-assertions = true`.-# This step can take 30 minutes and more.-./x.py build src/rustc++# Build a stage 2 rustc.+# This step can take 30 minutes or more.+./x.py build compiler/rustc --stage 2 # If you change something, you can get a faster rebuild by doing-./x.py --keep-stage 0 build src/rustc+./x.py --keep-stage 0 build compiler/rustc --stage 2

Okay, I still feel confused. A bit less confused, but I think I will have to do some deep thinking on this ;)

I'll apply your patches since you're the x.py guru.

camelid

comment created time in 6 hours

PullRequestReviewEvent

Pull request review commentrust-lang/miri

Update locally-built rustc instructions

 tracing) enabled.  The setup for a local rustc works as follows: ```sh+# Clone the rust-lang/rust repo. git clone https://github.com/rust-lang/rust/ rustc cd rustc cp config.toml.example config.toml # Now edit `config.toml` and set `debug-assertions = true`.-# This step can take 30 minutes and more.-./x.py build src/rustc++# Build a stage 2 rustc.+# This step can take 30 minutes or more.+./x.py build compiler/rustc --stage 2 # If you change something, you can get a faster rebuild by doing-./x.py --keep-stage 0 build src/rustc+./x.py --keep-stage 0 build compiler/rustc --stage 2

Okay, I just read that, and I think I understand now: --stage 2 means:

  1. Compile std with beta rustc
  2. Compile rustc with beta rustc and std from step 1
  3. Compile std with rustc from step 2
  4. Compile rustc with rustc from step 2 and std from step 3

Is that correct?

camelid

comment created time in 6 hours

PullRequestReviewEvent

Pull request review commentrust-lang/miri

Update locally-built rustc instructions

 tracing) enabled.  The setup for a local rustc works as follows: ```sh+# Clone the rust-lang/rust repo. git clone https://github.com/rust-lang/rust/ rustc cd rustc cp config.toml.example config.toml # Now edit `config.toml` and set `debug-assertions = true`.-# This step can take 30 minutes and more.-./x.py build src/rustc++# Build a stage 2 rustc.+# This step can take 30 minutes or more.+./x.py build compiler/rustc --stage 2 # If you change something, you can get a faster rebuild by doing-./x.py --keep-stage 0 build src/rustc+./x.py --keep-stage 0 build compiler/rustc --stage 2

I think it's built out of tree, but I'm not sure.

And won't library/std only build std and not the compiler? That or I don't understand bootstrap filters at all, which is a possibility ;)

camelid

comment created time in 6 hours

PullRequestReviewEvent

Pull request review commentrust-lang/miri

Update locally-built rustc instructions

 tracing) enabled.  The setup for a local rustc works as follows: ```sh+# Clone the rust-lang/rust repo. git clone https://github.com/rust-lang/rust/ rustc cd rustc cp config.toml.example config.toml # Now edit `config.toml` and set `debug-assertions = true`.-# This step can take 30 minutes and more.-./x.py build src/rustc++# Build a stage 2 rustc.+# This step can take 30 minutes or more.+./x.py build compiler/rustc --stage 2 # If you change something, you can get a faster rebuild by doing-./x.py --keep-stage 0 build src/rustc+./x.py --keep-stage 0 build compiler/rustc --stage 2

But won't it build rustdoc etc. if you leave out compiler/rustc?

Also: I'm guessing you didn't mean to suggest removing build ;)

camelid

comment created time in 6 hours

PullRequestReviewEvent

Pull request review commentrust-lang/miri

Update locally-built rustc instructions

 tracing) enabled.  The setup for a local rustc works as follows: ```sh+# Clone the rust-lang/rust repo. git clone https://github.com/rust-lang/rust/ rustc cd rustc cp config.toml.example config.toml # Now edit `config.toml` and set `debug-assertions = true`.-# This step can take 30 minutes and more.-./x.py build src/rustc++# Build a stage 2 rustc.+# This step can take 30 minutes or more.+./x.py build compiler/rustc --stage 2

Revenge of the bootstrap stages! What should I change it to?

camelid

comment created time in 6 hours

PullRequestReviewEvent

delete branch camelid/rust

delete branch : rc-fully-qualified-syntax

delete time in 6 hours

pull request commentrust-lang/rust

driver: Only output ANSI if connected to a terminal

Hmm, it looks like log colors aren't working when connected to a terminal...

camelid

comment created time in 7 hours

pull request commentrust-lang/rust

driver: Only output ANSI if connected to a terminal

Before

A libstd for Miri is now available in `/Users/user/Library/Caches/org.rust-lang.miri/HOST`.

running 3 tests
test range_map::tests::basic_insert ... ok
test intptrcast::tests::test_align_addr ... ok
test range_map::tests::gaps ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out


running 200 tests
normalized stdout:
2:rustcrustc_mir::interpret::eval_context::frame main
2:rustcrustc_mir::interpret::eval_context::frame main
2:rustcDEBUG rustc_middle::mir::interpret creating alloc Function(Instance { def: Item(WithOptConstParam { did: DefId(0:8 ~ align[317d]::main), const_param_did: None }), substs: [] }) with id alloc5
2:rustcrustc_mir::interpret::eval_context::frame std::rt::lang_start::<()>
2:rustc├─12ms  INFO rustc_mir::interpret::step StorageLive(_4)
2:rustc├─12ms  INFO rustc_mir::interpret::step StorageLive(_5)
2:rustc├─12ms  INFO rustc_mir::interpret::step StorageLive(_6)
2:rustc├─12ms  INFO rustc_mir::interpret::step StorageLive(_7)
2:rustc├─12ms  INFO rustc_mir::interpret::step (_7.0: fn() -> T) = _1
2:rustc├─12ms  INFO rustc_mir::interpret::step Retag(_7)
2:rustc├─12ms  INFO rustc_mir::interpret::step _6 = &_7
2:rustc├─12ms  INFO rustc_mir::interpret::step Retag(_6)
2:rustc├─12ms  INFO rustc_mir::interpret::step _5 = &(*_6)
2:rustc├─12ms  INFO rustc_mir::interpret::step Retag(_5)
2:rustc├─12ms  INFO rustc_mir::interpret::step _4 = move _5 as &dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe (Pointer(Unsize))
2:rustc├─12ms DEBUG rustc_mir::interpret::util ensure_monomorphic_enough: ty=[closure@std::rt::lang_start<()>::{closure#0}]
2:rustc├─12ms DEBUG rustc_mir::interpret::util ensure_monomorphic_enough: ty=Some(Binder(std::ops::Fn<()>))
2:rustc├─16ms  INFO rustc_mir::interpret::step Retag(_4)
2:rustc├─16ms  INFO rustc_mir::interpret::step StorageDead(_5)
2:rustc├─16ms  INFO rustc_mir::interpret::step StorageLive(_8)
2:rustc├─16ms  INFO rustc_mir::interpret::step _8 = _2
2:rustc├─16ms  INFO rustc_mir::interpret::step StorageLive(_9)
2:rustc├─16ms  INFO rustc_mir::interpret::step _9 = _3
2:rustc├─16ms  INFO rustc_mir::interpret::step _0 = std::rt::lang_start_internal(move _4, move _8, move _9) -> bb1
2:rustc├┐rustc_mir::interpret::eval_context::frame std::rt::lang_start::<()>
2

After

A libstd for Miri is now available in `/Users/user/Library/Caches/org.rust-lang.miri/HOST`.

running 3 tests
test intptrcast::tests::test_align_addr ... ok
test range_map::tests::gaps ... ok
test range_map::tests::basic_insert ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out


running 200 tests
normalized stdout:
2:rustcrustc_mir::interpret::eval_context::frame main
2:rustcrustc_mir::interpret::eval_context::frame main
2:rustcDEBUG rustc_middle::mir::interpret creating alloc Function(Instance { def: Item(WithOptConstParam { did: DefId(0:8 ~ align[317d]::main), const_param_did: None }), substs: [] }) with id alloc5
2:rustcrustc_mir::interpret::eval_context::frame std::rt::lang_start::<()>
2:rustc├─1395ms INFO rustc_mir::interpret::step StorageLive(_4)
2:rustc├─1395ms INFO rustc_mir::interpret::step StorageLive(_5)
2:rustc├─1395ms INFO rustc_mir::interpret::step StorageLive(_6)
2:rustc├─1395ms INFO rustc_mir::interpret::step StorageLive(_7)
2:rustc├─1395ms INFO rustc_mir::interpret::step (_7.0: fn() -> T) = _1
2:rustc├─1396ms INFO rustc_mir::interpret::step Retag(_7)
2:rustc├─1396ms INFO rustc_mir::interpret::step _6 = &_7
2:rustc├─1396ms INFO rustc_mir::interpret::step Retag(_6)
2:rustc├─1452ms INFO rustc_mir::interpret::step _5 = &(*_6)
2:rustc├─1452ms INFO rustc_mir::interpret::step Retag(_5)
2:rustc├─1452ms INFO rustc_mir::interpret::step _4 = move _5 as &dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe (Pointer(Unsize))
2:rustc├─1454ms DEBUG rustc_mir::interpret::util ensure_monomorphic_enough: ty=[closure@std::rt::lang_start<()>::{closure#0}]
2:rustc├─1454ms DEBUG rustc_mir::interpret::util ensure_monomorphic_enough: ty=Some(Binder(std::ops::Fn<()>))
2:rustc├─1614ms INFO rustc_mir::interpret::step Retag(_4)
2:rustc├─1614ms INFO rustc_mir::interpret::step StorageDead(_5)
2:rustc├─1614ms INFO rustc_mir::interpret::step StorageLive(_8)
2:rustc├─1614ms INFO rustc_mir::interpret::step _8 = _2
2:rustc├─1614ms INFO rustc_mir::interpret::step StorageLive(_9)
2:rustc├─1614ms INFO rustc_mir::interpret::step _9 = _3
2:rustc├─1614ms INFO rustc_mir::interpret::step _0 = std::rt::lang_start_internal(move _4, move _8, move _9) -> bb1
2:rustc├┐rustc_mir::interpret::eval_context::frame std::rt::lang_start::<()>
camelid

comment created time in 7 hours

delete branch camelid/miri

delete branch : patch-1

delete time in 7 hours

Pull request review commentrust-lang/miri

Update locally-built rustc instructions

 tracing) enabled.  The setup for a local rustc works as follows: ```sh+# Clone the rust-lang/rust repo. git clone https://github.com/rust-lang/rust/ rustc cd rustc cp config.toml.example config.toml # Now edit `config.toml` and set `debug-assertions = true`.-# This step can take 30 minutes and more.-./x.py build src/rustc++# Build a stage 2 rustc.+# This step can take 30 minutes or more.+./x.py build compiler/rustc --stage 2 # If you change something, you can get a faster rebuild by doing-./x.py --keep-stage 0 build src/rustc+./x.py --keep-stage 0 build compiler/rustc --stage 2

Also didn't check if --keep-stage 0 still works.

camelid

comment created time in 7 hours

Pull request review commentrust-lang/miri

Update locally-built rustc instructions

 tracing) enabled.  The setup for a local rustc works as follows: ```sh+# Clone the rust-lang/rust repo. git clone https://github.com/rust-lang/rust/ rustc cd rustc cp config.toml.example config.toml # Now edit `config.toml` and set `debug-assertions = true`.-# This step can take 30 minutes and more.-./x.py build src/rustc++# Build a stage 2 rustc.+# This step can take 30 minutes or more.+./x.py build compiler/rustc --stage 2

I haven't test this particular command; I just used ./x.py build --stage 2, but it's probably faster to use what this suggests.

camelid

comment created time in 7 hours

PullRequestReviewEvent
PullRequestReviewEvent

PR opened rust-lang/miri

Update locally-built rustc instructions

Cc rust-lang/rust#78435

+7 -4

0 comment

1 changed file

pr created time in 7 hours

push eventcamelid/miri

Camelid

commit sha 8c84e65b150a424bc24ba355d2f5e0d220051592

Update locally-built rustc instructions

view details

push time in 7 hours

create barnchcamelid/rust

branch : driver-tty

created branch time in 7 hours

PR opened rust-lang/rust

driver: Only output ANSI if connected to a terminal

Fixes #78435.

See #78435 for more.

Cc @RalfJung @oli-obk

+1 -1

0 comment

1 changed file

pr created time in 7 hours

push eventcamelid/rustc-dev-guide

Camelid

commit sha 5d6a0cdf69da83dd48135db81b7199763f60eacf

Fix broken tags in glossary

view details

Camelid

commit sha 384eddb2efc13d18f12cc7d591beff20881218d7

Put `TyCtxt` at the right position It should now be at its alphabetical position. Also fixed link to `TyCtxt` anchor.

view details

Camelid

commit sha cc841a185fea73437bf63c616dd52f64b44b1b60

Use new-style mdBook internal links in glossary

view details

push time in 7 hours

PR opened rust-lang/miri

Fix link in README
+3 -1

0 comment

1 changed file

pr created time in 7 hours

push eventcamelid/miri

Camelid

commit sha 02af2a38acc9c96e6012f8647d063669b19c0a32

Fix link in README

view details

push time in 7 hours

push eventcamelid/rust

Wesley Wiser

commit sha 1c1c591c81a6fba8199355066a4b4ca00df659b2

[resolve] Use `unwrap_or_else` instead of `unwrap_or` in a hot path This improves the performance of the `resolve_crate` function by 30% for a very large single file crate with auto-generated C bindings.

view details

bors

commit sha 6bdae9edd0cc099daa6038bca469dc09b6fc078a

Auto merge of #78508 - wesleywiser:optimize_visit_scopes, r=petrochenkov [resolve] Use `unwrap_or_else` instead of `unwrap_or` in a hot path This improves the performance of the `resolve_crate` function by 30% for a very large single file crate with auto-generated C bindings. cc `@rylev`

view details

push time in 8 hours

issue commentrust-lang/rust

Driver logging: disable colors when logging to file

Hmm, I'm getting this error:

error[E0463]: can't find crate for `rustc_attr`
  --> src/lib.rs:14:1
   |
14 | extern crate rustc_attr;
   | ^^^^^^^^^^^^^^^^^^^^^^^^ can't find crate

error: aborting due to previous error

I'm using the latest master rustc and the latest miri. Is miri broken right now?

RalfJung

comment created time in 8 hours

push eventcamelid/miri

Camelid

commit sha 05e9ae042c83345d00d6abba2e4f567b163a90f7

Make `miri_default_args()` a constant

view details

bors

commit sha ef4127459c46d4c0c9da70502677e7f69386c4be

Auto merge of #1599 - camelid:default-args-const, r=RalfJung Make `miri_default_args()` a constant Feel free to close this if this is intentionally not a constant.

view details

Ralf Jung

commit sha ddcc4f241e1e9987b050067f4303d0449774b36e

rustup; make panic output less dependent on stdlib internals

view details

bors

commit sha 88da6757d7fe75c853767e4615a6255e9466b67a

Auto merge of #1600 - RalfJung:rustup, r=RalfJung rustup; make panic output less dependent on stdlib internals

view details

Ralf Jung

commit sha 16491aef42d386a9e721b913b9b4d8361a127a5a

Use bash to make sure &> works

view details

Ralf Jung

commit sha 086e9c49a95ab30380954cc3bca632145786cee2

pointer tag tracking: also show when tag is being created

view details

bors

commit sha 5fdea5be99eb44ea2b3adebb1f8a3c1c244ffd7e

Auto merge of #1601 - RalfJung:misc, r=RalfJung pointer tag tracking: also show when tag is being created Also use bash to make sure `&>` works.

view details

Ralf Jung

commit sha ecf330f39eaed1f798445ae018cfb645517078bc

test Box::into_raw aliasing

view details

bors

commit sha c7c77b149bb2401f82ffffc40989d084496986d0

Auto merge of #1602 - RalfJung:box, r=RalfJung test Box::into_raw aliasing Directly test aliasing problems caused by `Box::into_raw` issues (like we have them again right now due to https://github.com/rust-lang/rust/pull/77187, but the pinned rustc is older than that so this should still be able to land).

view details

Ralf Jung

commit sha 39f7b35327cd4747da1a20a187fbaf220ee4a09c

Stacked Borrows: print affected memory location on errors

view details

Ralf Jung

commit sha 194451345dc6b7d269a5ded6fde49883cb862d75

add an option to track raw pointer tags in Stacked Borrows

view details

Ralf Jung

commit sha 19e78a65d95d03b6d7ac670075231837cc00edf4

run some tests with raw pointer tracking

view details

Ralf Jung

commit sha 1044099c196ced6108234fe2450fcd2f7f969fa7

disable debug assertions in the standard library

view details

Ralf Jung

commit sha 00c4869d560e108a9b8298c7d1861c7320be45c6

remove outdated CI badges

view details

bors

commit sha b7d0cecf2de592fb5a6f1d6086512e5d95cad30d

Auto merge of #1605 - RalfJung:readme, r=RalfJung Readme: remove outdated CI badges

view details

Ralf Jung

commit sha 70af7aed88456b8c478e06d1d28b0d8523a46b38

expand flag docs

view details

bors

commit sha 606436753abeb7d0251d17f8e0c91d4ec162765a

Auto merge of #1604 - RalfJung:std-debug-assert, r=oli-obk disable debug assertions in the standard library Debug assertions in the standard library can be somewhat expensive to check, in particular the ones covering each and every `ptr::write/copy/copy_nonoverlapping`. Miri will find most of those problems anyway since they cause UB. There are other debug assertions, such as ensuring internal invariants are maintained, but given how slow Miri already is, I think it is better to skip those checks in Miri and instead figure out a better way for people to use a standard library with debug assertions enabled.

view details

Ralf Jung

commit sha bf54607ba03cf12a015e7027be6d5ffdf08cc3ca

test raw pointer tracking; we cannot track raw pointers on Windows

view details

Ralf Jung

commit sha 2589b482516941c109c1ab2f98dd446e23ca6887

update trophy case

view details

bors

commit sha 83f7657ed06ea38eaeb6c8e83d83430f49827559

Auto merge of #1603 - RalfJung:track-raw, r=oli-obk add an option to track raw pointer tags in Stacked Borrows Also make error messages more informative by printing the affected memory location

view details

push time in 8 hours

issue commentrust-lang/rust

Driver logging: disable colors when logging to file

Ah, thanks! I forgot about that part of the docs :)

RalfJung

comment created time in 9 hours

issue commentrust-lang/rust

VecDeque from Vec fails with ZST

Assigning P-high and removing I-prioritize as discussed in the prioritization working group.

alecmocatta

comment created time in 9 hours

issue commentrust-lang/rust

Better diagnostics for missing iterator in for-loop

Yes, I just wanted to make sure we were on the same page :)

jyn514

comment created time in 9 hours

issue commentrust-lang/rust

Driver logging: disable colors when logging to file

How can I run miri from the rust repo? (i.e. built using ./x.py build)

RalfJung

comment created time in 10 hours

issue commentrust-lang/rust

VecDeque from Vec fails with ZST

Why is this specific to ZSTs?

alecmocatta

comment created time in 10 hours

issue commentrust-lang/rust

compiletest: Show real patches as diffs?

Ugh, this looks like it might be annoying to implement.

camelid

comment created time in 10 hours

issue commentrust-lang/rust

Better diagnostics for missing iterator in for-loop

I'd love it to instead say 'missing iterator for loop':

error: expected iterator, found block
 --> src/lib.rs
  |
2 |    for i in {
  |             ^ this starts a block expression ...
5 |     1
  |     ^ ... so there is no body for the loop
  =     help: try adding an iterator to the for-loop: `for i in iter {`

Well, it thinks the block is the iterator.

jyn514

comment created time in 10 hours

pull request commentrust-lang/rust

Qualify `panic!` as `core::panic!` in non-built-in `core` macros

@m-ou-se Ready for a new r+ :)

camelid

comment created time in 10 hours

push eventcamelid/rust

Camelid

commit sha 7b3d8971bb60347d39a93608ec19069f58731430

Add two more test cases

view details

push time in 10 hours

delete branch camelid/backtrace-rs

delete branch : patch-1

delete time in 10 hours

Pull request review commentrust-lang/backtrace-rs

Update gimli docs

 //! Support for symbolication using the `gimli` crate on crates.io //!-//! This implementation is largely a work in progress and is off by default for-//! all platforms, but it's hoped to be developed over time! Long-term this is-//! intended to wholesale replace the `libbacktrace.rs` implementation.+//! This is the default symbolication implementation for Rust.

Let me know if this wording is incorrect, I am not very knowledgeable about gimli :)

camelid

comment created time in 10 hours

PullRequestReviewEvent

PR opened rust-lang/backtrace-rs

Update gimli docs

I believe gimli is now the default implementation.

Cc https://github.com/rust-lang/backtrace-rs/pull/373#discussion_r502059176

+1 -3

0 comment

1 changed file

pr created time in 10 hours

push eventcamelid/backtrace-rs

Camelid

commit sha cc6b6075ab93ca7ab5d11138a88edc7a61864504

Update gimli docs

view details

push time in 10 hours

push eventcamelid/rust

Camelid

commit sha 93ca9aebb9183c7256db9b277cfe01d0beaf75a2

Qualify `panic!` as `core::panic!` in non-built-in `core` macros Otherwise code like this #![no_implicit_prelude] fn main() { ::std::todo!(); ::std::unimplemented!(); } will fail to compile, which is unfortunate and presumably unintended. This changes many invocations of `panic!` in a `macro_rules!` definition to invocations of `$crate::panic!`, which makes the invocations hygienic. Note that this does not make the built-in macro `assert!` hygienic.

view details

Camelid

commit sha 5c87941896c77e7347d31655c85e2a16279baff3

Clean up `core` macros documentation * Switch a couple links over to intra-doc links * Clean up some formatting/typography

view details

push time in 10 hours

pull request commentrust-lang/rust

Qualify `panic!` as `core::panic!` in non-built-in `core` macros

Squashed!

camelid

comment created time in 10 hours

push eventcamelid/rust

Bastian Kauschke

commit sha 4a15a256626d3a9e017a18bb60bf98b1a6358bd5

min_const_generics: allow ty param in repeat expr

view details

Bastian Kauschke

commit sha 83ecbb4a294abca245f8c515e298464e9425b9a2

add tests for self with const params

view details

Nadrieril

commit sha feb1e13960ab435ba14a37e237a3c5aaee8b9558

Split `split_grouped_constructor` into smaller functions

view details

Nadrieril

commit sha 7c4f94be4859ee6b6bc8fd50fa75328b3d30c9aa

Use pat_constructor to simplify specialize_one_pattern

view details

Nadrieril

commit sha 6ad9f44a50fdfdb2388850fbd9b07db66f452ec7

Clarify specialization into two steps First is checking for constructor overlap, second is extracting the resulting fields.

view details

Nadrieril

commit sha c511955a9ff89089bff313cd8a87a6e62e2783f5

Factor out the two specialization steps

view details

Nadrieril

commit sha 41e7ca499d51913131a5afa5fa76db914cb672cd

Inline `specialize_one_pattern`

view details

Nadrieril

commit sha 833089fbc9d800813686d4d9b228c0dfe2aabd7b

Unify the two kinds of specialization by adding a Wildcard ctor

view details

Nadrieril

commit sha 1190e7275cd1eadc0ef17b564fc84551973b6d85

Cache head constructor in PatStack Since the constructor is recomputed a lot, caching is worth it.

view details

Nadrieril

commit sha cdafd1e1bda60f19c41540302da9543069cc1f66

Let MissingConstructors handle the subtleties of missing constructors

view details

Nadrieril

commit sha b49f90760d0c464e6e7c3da06dc6a1eb122552ec

Pass more things through `PatCtxt` This is even a perf improvement on the match-heavy benchmarks.

view details

Nadrieril

commit sha c96bd28ab375e6e273bac174e86860c9d3a27510

Recompute `MissingConstructors` when needed This only happens in a slow (diagnostics) path, so the code clarity gain is worth it.

view details

Nadrieril

commit sha 54fa70290d8ab65e33116eb888278f7a64ca6da4

Unify the paths through `is_useful`

view details

Nadrieril

commit sha db9a8480c481deb0936508c224dc0514e4fe0e80

Simplify specialize_constructor Also removes the ugly caching that was introduced in #76918. It was bolted on without deeper knowledge of the workings of the algorithm. This commit manages to be more performant without any of the complexity. It should be better on representative workloads too.

view details

Nadrieril

commit sha 1fab669f8dbc1138509fe3a28c200cab5c54db21

Be honest about being able to list constructors The test change is because we used to treat `&str` like other `&T`s, ie as having a single constructor. That's not quite true though since we consider `&str` constants as atomic instead of refs to `str` constants.

view details

Nadrieril

commit sha cd4c7144de75e4789dd6dac5f6020aecb1e8e0b0

Deduplicate work between splitting and subtraction After splitting, subtraction becomes much simpler

view details

Nadrieril

commit sha 766ab78a1cb243293eb84efd073186aa28724802

Simplify slice splitting a bit

view details

Ralf Jung

commit sha ab374dc37c168dbd2125f7322ed2a0e842504bc1

fix Box::into_unique

view details

kadmin

commit sha eb8e8bd8bfe492f154ab0438b0067b7a302d2fc1

Add UI test for invalid values for bool & char

view details

Camelid

commit sha 0217edbd292eeb9d5febfda6e33c574ab88cf916

Clean up intra-doc links in `std::path`

view details

push time in 11 hours

issue commentrust-lang/rust

compiletest: Show real patches as diffs?

Or we could just run

$ diff -u src/test/ui/hygiene/no_implicit_prelude.stderr build/x86_64-apple-darwin/test/ui/hygiene/no_implicit_prelude/no_implicit_prelude.stderr

:)

camelid

comment created time in 11 hours

pull request commentrust-lang/rust

Qualify `panic!` as `core::panic!` in non-built-in `core` macros

Maybe we could print some kind of warning (or have a lint) if someone defines their own panic! macro that encourages them to use #[panic_handler]? I'm just wondering if there could be any false-positives.

camelid

comment created time in 11 hours

pull request commentrust-lang/rust

Qualify `panic!` as `core::panic!` in non-built-in `core` macros

The "proper" solution is #[panic_handler]. It might just be that that code predates stabilization of this attribute?

Yeah, I was wondering if that was relevant.

camelid

comment created time in 11 hours

pull request commentrust-lang/rust

Qualify `panic!` as `core::panic!` in non-built-in `core` macros

That's unfortunate :/

It is an implementation detail, but ideally we wouldn't break so much without providing a solution. Maybe we could provide some kind of attribute that you apply to override the implementation of panic!? Pseudo-code:

#[panic_macro]
macro_rules! mypanic { /* ... */ }

But that doesn't feel like a great solution. What can we do about this?

camelid

comment created time in 11 hours

push eventcamelid/rust

Mara Bos

commit sha 8fa7d581103a7964ae053c5c1e4b994931b76ca1

Update 32-bit mir tests.

view details

push time in 11 hours

pull request commentrust-lang/rust

Qualify `panic!` as `core::panic!` in non-built-in `core` macros

Thanks!

camelid

comment created time in 11 hours

pull request commentrust-lang/rust

Qualify `panic!` as `core::panic!` in non-built-in `core` macros

Or modify it to run --bless and commit and push the changes it to this branch. ;)

Yeah, that might be more error-prone, but it could work ;)

I just realized that the test file does not seem to ignore x64. Am I misinterpreting the directives?

fn main() {
    let split = match Some(1) {
        Some(v) => v,
        None => return,
    };

    let _prev = Some(split);
    assert_eq!(split, 1);
}

// EMIT_MIR_FOR_EACH_BIT_WIDTH
// EMIT_MIR issue_73223.main.SimplifyArmIdentity.diff
// EMIT_MIR issue_73223.main.PreCodegen.diff
camelid

comment created time in 12 hours

pull request commentrust-lang/rust

Qualify `panic!` as `core::panic!` in non-built-in `core` macros

Or I could do something hacky :)

  1. Modify compiletest to print out real patches
  2. Push that up
  3. Wait for CI to finish, then copy the patch and apply it locally
  4. Then remove the compiletest mod
camelid

comment created time in 12 hours

issue commentrust-lang/rust

VecDeque from Vec fails with ZST

I can reproduce when using Miri, but it works fine for me with WASM:

$ cargo +stable build --target=wasm32-unknown-unknown
   Compiling rust-issue-78532 v0.1.0 (/Users/user/rust-issue-78532)
    Finished dev [unoptimized + debuginfo] target(s) in 0.17s
alecmocatta

comment created time in 12 hours

issue openedrust-lang/rust

compiletest: Show real patches as diffs?

Current compiletest diffs are not accepted by patch (at least when I've tried):

patch: **** Only garbage was found in the patch input.

Maybe we could change compiletest to output real patches, at least in CI, so that you can just copy-paste the diff and apply it locally if you are not able to run ./x.py test --bless?

Cc https://github.com/rust-lang/rust/pull/78343#issuecomment-718949632

created time in 12 hours

pull request commentrust-lang/rust

Qualify `panic!` as `core::panic!` in non-built-in `core` macros

Hmm, I tried that with several different platforms (including Apple ones since I'm on macOS), but all of them failed with various linker errors :/

I also tried copy-pasting the CI diff, but patch complains that it got "only garbage input". Any ideas?

camelid

comment created time in 12 hours

issue commentrust-lang/rust

compiletest: show affected architecture in error summary

And also it would be nice if when it ignored a test because it was the wrong platform, it showed some indication of that, because otherwise it looks like it ran the test and it passed. Perhaps show a question mark (?)? (We already use i for tests that were ignored because they were already run and passed.)

RalfJung

comment created time in 12 hours

pull request commentrust-lang/rust

Qualify `panic!` as `core::panic!` in non-built-in `core` macros

Ah, I missed that. Should I just apply the patch generated by CI then?

camelid

comment created time in 13 hours

delete branch camelid/rust

delete branch : fixup-std-path-intra-doc

delete time in a day

push eventcamelid/rust

Camelid

commit sha a9c12fe111e74c1211506ea9be2f8f999e7e7af0

Add missing period in docs

view details

push time in a day

pull request commentrust-lang/rust

Qualify `panic!` as `core::panic!` in non-built-in `core` macros

Finished a stage 2 build. It still passes.

@jonas-schievink do you know why this might be happening?

camelid

comment created time in a day

issue commentrust-lang/rust

Regression parsing closing angle brackets near function ptr return type

searched nightlies: from nightly-2020-10-27 to nightly-2020-10-29 regressed nightly: nightly-2020-10-29 searched commits: from https://github.com/rust-lang/rust/commit/07e968b640e8ff76fa8be4b48b70ab80ea577800 to https://github.com/rust-lang/rust/commit/31ee872db5aae4750e3da1ca4ed1523c4356947f regressed commit: https://github.com/rust-lang/rust/commit/db241bb0c8d257e13c1560f6250e49879477039e

<details> <summary>bisected with <a href='https://github.com/rust-lang/cargo-bisect-rustc'>cargo-bisect-rustc</a> v0.6.0</summary>

Host triple: x86_64-apple-darwin Reproduce with:

cargo bisect-rustc --preserve --regress=error --start=2020-10-27 

</details>

dtolnay

comment created time in a day

issue commentrust-lang/rust

Regression parsing closing angle brackets near function ptr return type

Assigning P-critical and removing I-prioritize as discussed in the prioritization working group.

dtolnay

comment created time in a day

pull request commentrust-lang/rust

Qualify `panic!` as `core::panic!` in non-built-in `core` macros

Hmm, src/test/mir-opt/issue-73223.rs is still failing on CI, but it seems to work fine on my machine. Maybe it's some kind of platform-specific thing.

camelid

comment created time in a day

pull request commentrust-lang/rust

Explain fully qualified syntax for `Rc` and `Arc`

@steveklabnik This is ready for a re-review :)

camelid

comment created time in a day

push eventcamelid/rust

Camelid

commit sha 4e30e10f25ed39453ef69666a98e9650c7222c52

Don't say you "should" use fully qualified syntax That recommendation was removed last year; there isn't a particular style that is officially recommended anymore.

view details

push time in a day

more