profile
viewpoint

rust-lang/cargo 6090

The Rust package manager

rust-lang/book 5926

The Rust Programming Language

rust-lang/crates.io 1783

Source code for crates.io

rust-lang/chalk 947

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

rust-lang/api-guidelines 772

Rust API guidelines

rust-lang/async-book 710

Asynchronous Programming in Rust

rust-lang/datafrog 362

A lightweight Datalog engine in Rust

rust-lang/arewewebyet 339

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

rust-lang/crater 260

Run experiments across parts of the Rust ecosystem!

rust-lang/backtrace-rs 243

Backtraces in Rust

push eventrust-lang/crates.io-index

bors

commit sha 8c87e3eab6bdb64125af0fd4d53016aa5c4846c6

Updating crate `gfx-backend-dx11#0.6.9`

view details

push time in a few seconds

Pull request review commentrust-lang/rfcs

RFC: Plan to make core and std's panic identical.

+- Start Date: 2020-10-25+- RFC PR: [rust-lang/rfcs#3007](https://github.com/rust-lang/rfcs/pull/3007)+- Rust Issue: -++# Summary++This RFC proposes to make `core::panic!` and `std::panic!` identical and consistent in Rust 2021,+and proposes a way to deal with the differences in earlier editions without breaking code.++# Problems++`core::panic!` and `std::panic!` behave mostly the same, but have their own incompatible quirks for the single-argument case.++This leads to several different problems, which would all be solved if they didn't special-case `panic!(one_argument)`.++For multiple-arguments (e.g. `panic!("error: {}", e)`), both already behave identical.++## Panic++Both do not use `format_args!("..")` for `panic!("..")` like they do for multiple arguments, but use the string literally.++*💔 **Problem 1:** `panic!("error: {}")` is probably a mistake, but compiles fine.*++*💔 **Problem 2:** `panic!("Here's a brace: {{")` outputs two braces (`{{`), not one (`{`).*++In the case of `std::panic!(x)`, `x` does not have to be a string literal, but can be of any (`Any + Send`) type.+This means that `std::panic!("{}")` and even `std::panic!(&"hi")` compile without errors or warnings, even though these are most likely mistakes.++*💔 **Problem 3:** `panic!(123)`, `panic!(&"..")`, `panic!(b"..")`, etc. are probably mistakes, but compile fine with `std`.*++In the case of `core::panic!(x)`, `x` must be a `&str`, but does not have to be a string literal, nor does it have to be `'static`.+This means that `core::panic!("{}")` and `core::panic!(string.as_str())` compile fine.++*💔 **Problem 4:** `let error = String::from("error"); panic!(&error);` works fine in `no_std` code, but no longer compiles when switching `no_std` off.*++*💔 **Problem 5:** `panic!(CustomError::Error);` works with std, but no longer compiles when switching `no_std` on.*++## Assert++`assert!(expr, args..)` and `assert_debug(expr, args..)` expand to `panic!(args..)` and therefore will have all the same problems.+In addition, these can result in confusing mistakes:++```rust+assert!(v.is_empty(), false); // runs panic!(false) if v is not empty  😕+```++*💔 **Problem 6:** `assert!(expr, expr)` should probably have been a `assert_eq!`, but compiles fine and gives no useful panic message.*++Because `core::panic!` and `std::panic!` are different, `assert!` and related macros expand to `panic!(..)`, not to `$crate::panic!(..)`,+making these macros not work with `#![no_implicit_prelude]`, as reported in [#78333](https://github.com/rust-lang/rust/issues/78333).+This also means that the panic of an assert can be accidentally 'hijacked' by a locally defined `panic!` macro.++*💔 **Problem 7:** `assert!` and related macros need to choose between `core::panic!` and `std::panic!`, and can't use `$crate::panic!` for proper hygiene.*++## Implicit formatting arguments++[RFC 2795] adds implicit formatting args, as follows:++```rust+let a = 4;+println!("a is {a}");+```++It modifies `format_args!()` to automatically capture variables that are named in a formatting placeholder.++With the current implementations of `panic!()` (both core's and std's), this would not work if there are no additional explicit arguments:++```rust+let a = 4;++println!("{}", a); // prints `4`+panic!("{}", a); // panics with `4`++println!("{a}"); // prints `4`+panic!("{a}"); // panics with `{a}`  😕++println!("{a} {}", 4); // prints `4 4`+panic!("{a} {}", 4); // panics with `4 4`+```++*💔 **Problem 8:** `panic!("error: {error}")` will silently not work as expected, after [RFC 2795] is implemented.*++## Bloat++`core::panic!("hello {")` produces the same `fmt::Arguments` as `format_args!("hello {{")`, not `format_args!("{}", "hello {")` to avoid pulling in string's `Display` code,+which can be quite big.++However, `core::panic!(non_static_str)` does need to expand to `format_args!("{}", non_static_str)`, because `fmt::Arguments` requires a `'static` lifetime+for the non-formatted pieces. Because the `panic!` `macro_rules` macro can't distinguish between non-`'static` and `'static` values,+this optimization is only applied to what macro_rules consider a `$_:literal`, which does not include `concat!(..)` or `CONST_STR`.++*💔 **Problem 9:** `const CONST_STR: &'static str = "hi"; core::panic!(CONST_STR)` works,+but will silently result in a lot more generated code than `core::panic!("hi")`.+(And also needs [special handling](https://github.com/rust-lang/rust/pull/78069) to make `const_panic` work.)*++# Solution if we could go back in time++None of these these problems would have existed if+1\) `panic!()` did not handle the single-argument case differently, and+2\) `std::panic!` was no different than `core::panic!`:++```rust+// core+macro_rules! panic {+    () => (+        $crate::panic!("explicit panic")+    );+    ($($t:tt)*) => (+        $crate::panicking::panic_fmt($crate::format_args!($($t)+))+    );+}++// std+use core::panic;+```++The examples from problems 1, 2, 3, 4, 5, 6 and 9 would simply not compile, and problems 7 and 8 would not occur.++However, that would break too much existing code.++# Proposed solution++Considering we should not break existing code, I propose we gate the breaking changs on the 2021 edition.++In addition, we add a lint that *warns* about the problems in Rust 2015/2018, while not giving errors or changing the behaviour.++Specifically:++- Only for Rust 2021, we apply the breaking changes as in the previous section.

That's true. However, there have been a bunch of proc-macro API stabilizations since the 2018 edition, so I don't think it's really come up before.

m-ou-se

comment created time in 3 minutes

PullRequestReviewEvent

PR closed rust-lang/rust

[do not merge] get build artifact for freebsd S-waiting-on-author

This PR updates backtrace-rs submodule to get the artifact for testing. cc #78184 .

+29 -9

13 comments

7 changed files

lzutao

pr closed time in 3 minutes

pull request commentrust-lang/rust

[do not merge] get build artifact for freebsd

Build artifacts are ok.

lzutao

comment created time in 3 minutes

pull request commentrust-lang/rust

BTreeMap: ban BoxedNode from Root

:umbrella: The latest upstream changes (presumably #77187) made this pull request unmergeable. Please resolve the merge conflicts.

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author
ssomers

comment created time in 4 minutes

pull request commentrust-lang/rust

Rollup of 16 pull requests

:pushpin: Commit 4236d27c9bb0af5cbdfaaa840b211827c65fb1ee has been approved by JohnTitor

<!-- @bors r=JohnTitor 4236d27c9bb0af5cbdfaaa840b211827c65fb1ee --> <!-- homu: {"type":"Approved","sha":"4236d27c9bb0af5cbdfaaa840b211827c65fb1ee","approver":"JohnTitor"} -->

JohnTitor

comment created time in 4 minutes

pull request commentrust-lang/rust

Rollup of 16 pull requests

@bors r+ rollup=never p=5 @rustbot modify labels: rollup

JohnTitor

comment created time in 4 minutes

Pull request review commentrust-lang/rfcs

RFC: Plan to make core and std's panic identical.

+- Start Date: 2020-10-25+- RFC PR: [rust-lang/rfcs#3007](https://github.com/rust-lang/rfcs/pull/3007)+- Rust Issue: -++# Summary++This RFC proposes to make `core::panic!` and `std::panic!` identical and consistent in Rust 2021,+and proposes a way to deal with the differences in earlier editions without breaking code.++# Problems++`core::panic!` and `std::panic!` behave mostly the same, but have their own incompatible quirks for the single-argument case.++This leads to several different problems, which would all be solved if they didn't special-case `panic!(one_argument)`.++For multiple-arguments (e.g. `panic!("error: {}", e)`), both already behave identical.++## Panic++Both do not use `format_args!("..")` for `panic!("..")` like they do for multiple arguments, but use the string literally.++*💔 **Problem 1:** `panic!("error: {}")` is probably a mistake, but compiles fine.*++*💔 **Problem 2:** `panic!("Here's a brace: {{")` outputs two braces (`{{`), not one (`{`).*++In the case of `std::panic!(x)`, `x` does not have to be a string literal, but can be of any (`Any + Send`) type.+This means that `std::panic!("{}")` and even `std::panic!(&"hi")` compile without errors or warnings, even though these are most likely mistakes.++*💔 **Problem 3:** `panic!(123)`, `panic!(&"..")`, `panic!(b"..")`, etc. are probably mistakes, but compile fine with `std`.*++In the case of `core::panic!(x)`, `x` must be a `&str`, but does not have to be a string literal, nor does it have to be `'static`.+This means that `core::panic!("{}")` and `core::panic!(string.as_str())` compile fine.++*💔 **Problem 4:** `let error = String::from("error"); panic!(&error);` works fine in `no_std` code, but no longer compiles when switching `no_std` off.*++*💔 **Problem 5:** `panic!(CustomError::Error);` works with std, but no longer compiles when switching `no_std` on.*++## Assert++`assert!(expr, args..)` and `assert_debug(expr, args..)` expand to `panic!(args..)` and therefore will have all the same problems.+In addition, these can result in confusing mistakes:++```rust+assert!(v.is_empty(), false); // runs panic!(false) if v is not empty  😕+```++*💔 **Problem 6:** `assert!(expr, expr)` should probably have been a `assert_eq!`, but compiles fine and gives no useful panic message.*++Because `core::panic!` and `std::panic!` are different, `assert!` and related macros expand to `panic!(..)`, not to `$crate::panic!(..)`,+making these macros not work with `#![no_implicit_prelude]`, as reported in [#78333](https://github.com/rust-lang/rust/issues/78333).+This also means that the panic of an assert can be accidentally 'hijacked' by a locally defined `panic!` macro.++*💔 **Problem 7:** `assert!` and related macros need to choose between `core::panic!` and `std::panic!`, and can't use `$crate::panic!` for proper hygiene.*++## Implicit formatting arguments++[RFC 2795] adds implicit formatting args, as follows:++```rust+let a = 4;+println!("a is {a}");+```++It modifies `format_args!()` to automatically capture variables that are named in a formatting placeholder.++With the current implementations of `panic!()` (both core's and std's), this would not work if there are no additional explicit arguments:++```rust+let a = 4;++println!("{}", a); // prints `4`+panic!("{}", a); // panics with `4`++println!("{a}"); // prints `4`+panic!("{a}"); // panics with `{a}`  😕++println!("{a} {}", 4); // prints `4 4`+panic!("{a} {}", 4); // panics with `4 4`+```++*💔 **Problem 8:** `panic!("error: {error}")` will silently not work as expected, after [RFC 2795] is implemented.*++## Bloat++`core::panic!("hello {")` produces the same `fmt::Arguments` as `format_args!("hello {{")`, not `format_args!("{}", "hello {")` to avoid pulling in string's `Display` code,+which can be quite big.++However, `core::panic!(non_static_str)` does need to expand to `format_args!("{}", non_static_str)`, because `fmt::Arguments` requires a `'static` lifetime+for the non-formatted pieces. Because the `panic!` `macro_rules` macro can't distinguish between non-`'static` and `'static` values,+this optimization is only applied to what macro_rules consider a `$_:literal`, which does not include `concat!(..)` or `CONST_STR`.++*💔 **Problem 9:** `const CONST_STR: &'static str = "hi"; core::panic!(CONST_STR)` works,+but will silently result in a lot more generated code than `core::panic!("hi")`.+(And also needs [special handling](https://github.com/rust-lang/rust/pull/78069) to make `const_panic` work.)*++# Solution if we could go back in time++None of these these problems would have existed if+1\) `panic!()` did not handle the single-argument case differently, and+2\) `std::panic!` was no different than `core::panic!`:++```rust+// core+macro_rules! panic {+    () => (+        $crate::panic!("explicit panic")+    );+    ($($t:tt)*) => (+        $crate::panicking::panic_fmt($crate::format_args!($($t)+))+    );+}++// std+use core::panic;+```++The examples from problems 1, 2, 3, 4, 5, 6 and 9 would simply not compile, and problems 7 and 8 would not occur.++However, that would break too much existing code.++# Proposed solution++Considering we should not break existing code, I propose we gate the breaking changs on the 2021 edition.++In addition, we add a lint that *warns* about the problems in Rust 2015/2018, while not giving errors or changing the behaviour.++Specifically:++- Only for Rust 2021, we apply the breaking changes as in the previous section.

@Aaron1011 isn't this true for all edition changes though? If I write a proc-macro that attaches the wrong spans, then it may stop working when a crate using that macro upgrades to a new edition.

Perhaps there should be an exception to the stability rules for bugs that cause code to be tagged with the wrong edition.

m-ou-se

comment created time in 5 minutes

PullRequestReviewEvent

PR opened rust-lang/rust

Rollup of 16 pull requests

Successful merges:

  • #76635 (Add [T]::as_chunks(_mut))
  • #77703 (add system-llvm-libunwind config option)
  • #78219 (Prefer to use print_def_path)
  • #78298 (Add test for bad NLL higher-ranked subtype)
  • #78332 (Update description for error E0308)
  • #78342 (Use check-pass in single-use-lifetime ui tests)
  • #78347 (Add lexicographical comparison doc)
  • #78348 (Make some functions private that don't have to be public)
  • #78349 (Use its own TypeckResults to avoid ICE)
  • #78375 (Use ? in core/std macros)
  • #78377 (Fix typo in debug statement)
  • #78388 (Add some regression tests)
  • #78394 (fix(docs): typo in BufWriter documentation)
  • #78396 (Add compiler support for LLVM's x86_64 ERMSB feature)
  • #78405 (Fix typo in lint description)
  • #78412 (Improve formatting of hash collections docs)

Failed merges:

r? @ghost

+558 -262

0 comment

51 changed files

pr created time in 5 minutes

pull request commentrust-lang/cargo

Remove redundant "For example, "

:pushpin: Commit 587922d72911432ca7767aabac0d27557d875b5d has been approved by ehuss

<!-- @bors r=ehuss 587922d72911432ca7767aabac0d27557d875b5d --> <!-- homu: {"type":"Approved","sha":"587922d72911432ca7767aabac0d27557d875b5d","approver":"ehuss"} -->

sean-hut

comment created time in 6 minutes

pull request commentrust-lang/cargo

Remove redundant "For example, "

Thanks! @bors r+

sean-hut

comment created time in 6 minutes

push eventrust-lang/futures-rs

Kyle Huey

commit sha 8bb7fd9aea23a29764e6c321b8da875f0044200e

Add WeakShared. This makes implementing a cache with futures much easier. With the current architecture a cache that uses Shareds cannot honor the "drop as cancellation" feature of futures. And the cache is forced to either poll futures itself to ensure they're polled to completion or to leave half-polled futures dangling inside it (potentially consuming resources like sockets or database connections). WeakShared is to Shared as Weak is to Arc. If any copy of the underlying Shared exists that has not be dropped or polled to completion the WeakShared can be upgraded to it. This makes it possible to construct a cache that does not entrain futures, thus honoring the "drop as cancellation" feature.

view details

push time in 7 minutes

PR merged rust-lang/futures-rs

Add WeakShared. futures-util

This makes implementing a cache with futures much easier. With the current architecture a cache that uses Shareds cannot honor the "drop as cancellation" feature of futures. And the cache is forced to either poll futures itself to ensure they're polled to completion or to leave half-polled futures dangling inside it (potentially consuming resources like sockets or database connections). WeakShared is to Shared as Weak is to Arc. If any copy of the underlying Shared exists that has not be dropped or polled to completion the WeakShared can be upgraded to it. This makes it possible to construct a cache that does not entrain futures, thus honoring the "drop as cancellation" feature.

+65 -4

2 comments

5 changed files

khuey

pr closed time in 7 minutes

PullRequestReviewEvent

pull request commentrust-lang/rust

Compile rustc crates with the initial-exec TLS model

@bjorn3 I thought that was an artifact of cg_clif being out-of-tree, and that it would become less of an issue once it wasn't.

The integration uses git subtree. I will continue developing it out of tree and syncing it once in a while.

But in any case, I can certainly add Mode::Codegen to the list. Will that prevent optimizing the LLVM backend's use of TLS, if any?

The LLVM backend is compiled as dependency lf rustc_interface and thus uses Mode::Rustc.

joshtriplett

comment created time in 8 minutes

pull request commentrust-lang/rust

Move ExpnId fingerprint cache from TLS to StableHashingContext

Queued 5b3632cd0dcd6a5560a00fecbf3ccb1b1254f98f with parent 0da6d42f297642a60f2640ec313b879b376b9ad8, future comparison URL.

Aaron1011

comment created time in 9 minutes

pull request commentrust-lang/rust

Move ExpnId fingerprint cache from TLS to StableHashingContext

:sunny: Try build successful - checks-actions Build commit: 5b3632cd0dcd6a5560a00fecbf3ccb1b1254f98f (5b3632cd0dcd6a5560a00fecbf3ccb1b1254f98f) <!-- homu: {"type":"TryBuildCompleted","builders":{"checks-actions":"https://github.com/rust-lang-ci/rust/runs/1311880084"},"merge_sha":"5b3632cd0dcd6a5560a00fecbf3ccb1b1254f98f"} -->

Aaron1011

comment created time in 9 minutes

pull request commentrust-lang/cargo

Document platform-specific build-dependencies

:hourglass: Testing commit 2b2f0443fa2699abf535bd23095c7d41af1e534a with merge e497e325ece73d46c475abce0e8ff271355d7dbc... <!-- homu: {"type":"BuildStarted","head_sha":"2b2f0443fa2699abf535bd23095c7d41af1e534a","merge_sha":"e497e325ece73d46c475abce0e8ff271355d7dbc"} -->

roblabla

comment created time in 9 minutes

push eventrust-lang/cargo

Robin Lambertz

commit sha 2b2f0443fa2699abf535bd23095c7d41af1e534a

Document platform-specific build-dependencies It turns out that `target.'cfg()'.build-dependencies` are a currently stable but undocumented feature.

view details

bors

commit sha e497e325ece73d46c475abce0e8ff271355d7dbc

Auto merge of #8809 - roblabla:patch-1, r=ehuss Document platform-specific build-dependencies It turns out that `target.'cfg()'.build-dependencies` are a currently stable but undocumented feature. This PR mentions it in the cargo reference.

view details

push time in 9 minutes

pull request commentrust-lang/cargo

Document platform-specific build-dependencies

:pushpin: Commit 2b2f0443fa2699abf535bd23095c7d41af1e534a has been approved by ehuss

<!-- @bors r=ehuss 2b2f0443fa2699abf535bd23095c7d41af1e534a --> <!-- homu: {"type":"Approved","sha":"2b2f0443fa2699abf535bd23095c7d41af1e534a","approver":"ehuss"} -->

roblabla

comment created time in 10 minutes

pull request commentrust-lang/cargo

Document platform-specific build-dependencies

Thanks! This has been sitting in my todo list for a long time.

@bors r+

roblabla

comment created time in 10 minutes

push eventrust-lang/crates.io-index

bors

commit sha 8c1d621c44699a6e976f2347d34c72e1a8dd02cd

Updating crate `roux#1.2.0`

view details

push time in 10 minutes

pull request commentrust-lang/rust

Fix #66228 and #71924 (improve error message for wrong number of generic args)

:umbrella: The latest upstream changes (presumably #77187) made this pull request unmergeable. Please resolve the merge conflicts.

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author
Patryk27

comment created time in 11 minutes

Pull request review commentrust-lang/rfcs

RFC: Plan to make core and std's panic identical.

+- Start Date: 2020-10-25+- RFC PR: [rust-lang/rfcs#3007](https://github.com/rust-lang/rfcs/pull/3007)+- Rust Issue: -++# Summary++This RFC proposes to make `core::panic!` and `std::panic!` identical and consistent in Rust 2021,+and proposes a way to deal with the differences in earlier editions without breaking code.++# Problems++`core::panic!` and `std::panic!` behave mostly the same, but have their own incompatible quirks for the single-argument case.++This leads to several different problems, which would all be solved if they didn't special-case `panic!(one_argument)`.++For multiple-arguments (e.g. `panic!("error: {}", e)`), both already behave identical.++## Panic++Both do not use `format_args!("..")` for `panic!("..")` like they do for multiple arguments, but use the string literally.++*💔 **Problem 1:** `panic!("error: {}")` is probably a mistake, but compiles fine.*++*💔 **Problem 2:** `panic!("Here's a brace: {{")` outputs two braces (`{{`), not one (`{`).*++In the case of `std::panic!(x)`, `x` does not have to be a string literal, but can be of any (`Any + Send`) type.+This means that `std::panic!("{}")` and even `std::panic!(&"hi")` compile without errors or warnings, even though these are most likely mistakes.++*💔 **Problem 3:** `panic!(123)`, `panic!(&"..")`, `panic!(b"..")`, etc. are probably mistakes, but compile fine with `std`.*++In the case of `core::panic!(x)`, `x` must be a `&str`, but does not have to be a string literal, nor does it have to be `'static`.+This means that `core::panic!("{}")` and `core::panic!(string.as_str())` compile fine.++*💔 **Problem 4:** `let error = String::from("error"); panic!(&error);` works fine in `no_std` code, but no longer compiles when switching `no_std` off.*++*💔 **Problem 5:** `panic!(CustomError::Error);` works with std, but no longer compiles when switching `no_std` on.*++## Assert++`assert!(expr, args..)` and `assert_debug(expr, args..)` expand to `panic!(args..)` and therefore will have all the same problems.+In addition, these can result in confusing mistakes:++```rust+assert!(v.is_empty(), false); // runs panic!(false) if v is not empty  😕+```++*💔 **Problem 6:** `assert!(expr, expr)` should probably have been a `assert_eq!`, but compiles fine and gives no useful panic message.*++Because `core::panic!` and `std::panic!` are different, `assert!` and related macros expand to `panic!(..)`, not to `$crate::panic!(..)`,+making these macros not work with `#![no_implicit_prelude]`, as reported in [#78333](https://github.com/rust-lang/rust/issues/78333).+This also means that the panic of an assert can be accidentally 'hijacked' by a locally defined `panic!` macro.++*💔 **Problem 7:** `assert!` and related macros need to choose between `core::panic!` and `std::panic!`, and can't use `$crate::panic!` for proper hygiene.*++## Implicit formatting arguments++[RFC 2795] adds implicit formatting args, as follows:++```rust+let a = 4;+println!("a is {a}");+```++It modifies `format_args!()` to automatically capture variables that are named in a formatting placeholder.++With the current implementations of `panic!()` (both core's and std's), this would not work if there are no additional explicit arguments:++```rust+let a = 4;++println!("{}", a); // prints `4`+panic!("{}", a); // panics with `4`++println!("{a}"); // prints `4`+panic!("{a}"); // panics with `{a}`  😕++println!("{a} {}", 4); // prints `4 4`+panic!("{a} {}", 4); // panics with `4 4`+```++*💔 **Problem 8:** `panic!("error: {error}")` will silently not work as expected, after [RFC 2795] is implemented.*++## Bloat++`core::panic!("hello {")` produces the same `fmt::Arguments` as `format_args!("hello {{")`, not `format_args!("{}", "hello {")` to avoid pulling in string's `Display` code,+which can be quite big.++However, `core::panic!(non_static_str)` does need to expand to `format_args!("{}", non_static_str)`, because `fmt::Arguments` requires a `'static` lifetime+for the non-formatted pieces. Because the `panic!` `macro_rules` macro can't distinguish between non-`'static` and `'static` values,+this optimization is only applied to what macro_rules consider a `$_:literal`, which does not include `concat!(..)` or `CONST_STR`.++*💔 **Problem 9:** `const CONST_STR: &'static str = "hi"; core::panic!(CONST_STR)` works,+but will silently result in a lot more generated code than `core::panic!("hi")`.+(And also needs [special handling](https://github.com/rust-lang/rust/pull/78069) to make `const_panic` work.)*++# Solution if we could go back in time++None of these these problems would have existed if+1\) `panic!()` did not handle the single-argument case differently, and+2\) `std::panic!` was no different than `core::panic!`:++```rust+// core+macro_rules! panic {+    () => (+        $crate::panic!("explicit panic")+    );+    ($($t:tt)*) => (+        $crate::panicking::panic_fmt($crate::format_args!($($t)+))+    );+}++// std+use core::panic;+```++The examples from problems 1, 2, 3, 4, 5, 6 and 9 would simply not compile, and problems 7 and 8 would not occur.++However, that would break too much existing code.++# Proposed solution++Considering we should not break existing code, I propose we gate the breaking changs on the 2021 edition.++In addition, we add a lint that *warns* about the problems in Rust 2015/2018, while not giving errors or changing the behaviour.++Specifically:++- Only for Rust 2021, we apply the breaking changes as in the previous section.

With proc macros, it may not be as clear that crate2021 is to blame. Using Span::resolved_at, you could get a panic ident that appears to come from a 2018 crate, even if the literal panic never appears in a 2018 crate.

To be clear, I woud be shocked if this ever came up in practice. However, I think it would be worth adding an note to the RFC that this is idended to mitigate cross-edition breakage, not prevent it entirely.

m-ou-se

comment created time in 12 minutes

PullRequestReviewEvent

Pull request review commentrust-lang/cargo

List available packages if providing `--package` with an empty value

 fn print_available(     let mut output = String::new();     writeln!(output, "\"{}\" takes one argument.", option_name)?; -    if targets.is_empty() {+    print_availables(output, &targets, plural_name)+}++fn print_availables(output: String, availables: &[&str], plural_name: &str) -> CargoResult<()> {+    let mut output = output;+    if availables.is_empty() {         writeln!(output, "No {} available.", plural_name)?;     } else {         writeln!(output, "Available {}:", plural_name)?;-        for target in targets {-            writeln!(output, "    {}", target.name())?;+        for available in availables {+            writeln!(output, "    {}", available)?;         }     }     bail!("{}", output) } +pub fn print_available_packages(ws: &Workspace<'_>) -> CargoResult<()> {+    let packages = ws+        .members()+        .map(|pkg| pkg.name().as_str())+        .collect::<Vec<_>>();++    let mut output = String::new();+    writeln!(+        output,+        "\"--package <SPEC>\" requires a SPEC format value.\n\+        Run `cargo help pkgid` for more infomation about SPEC format."+    )?;
    let output = "\"--package <SPEC>\" requires a SPEC format value.\n\
        Run `cargo help pkgid` for more infomation about SPEC format.\n"
        .to_string();
weihanglo

comment created time in 29 minutes

Pull request review commentrust-lang/cargo

List available packages if providing `--package` with an empty value

 fn print_available(     let mut output = String::new();     writeln!(output, "\"{}\" takes one argument.", option_name)?; -    if targets.is_empty() {+    print_availables(output, &targets, plural_name)+}++fn print_availables(output: String, availables: &[&str], plural_name: &str) -> CargoResult<()> {+    let mut output = output;
fn print_availables(mut output: String, availables: &[&str], plural_name: &str) -> CargoResult<()> {
weihanglo

comment created time in 33 minutes

PullRequestReviewEvent
PullRequestReviewEvent

pull request commentrust-lang/rust

Compile rustc crates with the initial-exec TLS model

@bjorn3 I thought that was an artifact of cg_clif being out-of-tree, and that it would become less of an issue once it wasn't.

But in any case, I can certainly add Mode::Codegen to the list. Will that prevent optimizing the LLVM backend's use of TLS, if any?

joshtriplett

comment created time in 12 minutes

issue commentrust-lang/cargo

Pass --cfg doc to check builds of dependencies as part of cargo doc/rustdoc

Also, I've marked this a bug, because of the unexpected behavior it produces, but I could see the argument to call it a feature request.

djrenren

comment created time in 14 minutes

issue commentrust-lang/wg-allocators

Tracking Issue for structs which needs an allocator

rust-lang/rust#77187 just got merged. I'll add an allocator parameter to Vec next.

TimDiekmann

comment created time in 15 minutes

push eventrust-lang/crates.io-index

bors

commit sha 3fb466179721d9b63e424ebf7330ba0e647cc20e

Updating crate `gfx-backend-dx12#0.6.11`

view details

push time in 16 minutes

Pull request review commentrust-lang/rfcs

RFC: Plan to make core and std's panic identical.

+- Start Date: 2020-10-25+- RFC PR: [rust-lang/rfcs#3007](https://github.com/rust-lang/rfcs/pull/3007)+- Rust Issue: -++# Summary++This RFC proposes to make `core::panic!` and `std::panic!` identical and consistent in Rust 2021,+and proposes a way to deal with the differences in earlier editions without breaking code.++# Problems++`core::panic!` and `std::panic!` behave mostly the same, but have their own incompatible quirks for the single-argument case.++This leads to several different problems, which would all be solved if they didn't special-case `panic!(one_argument)`.++For multiple-arguments (e.g. `panic!("error: {}", e)`), both already behave identical.++## Panic++Both do not use `format_args!("..")` for `panic!("..")` like they do for multiple arguments, but use the string literally.++*💔 **Problem 1:** `panic!("error: {}")` is probably a mistake, but compiles fine.*++*💔 **Problem 2:** `panic!("Here's a brace: {{")` outputs two braces (`{{`), not one (`{`).*++In the case of `std::panic!(x)`, `x` does not have to be a string literal, but can be of any (`Any + Send`) type.+This means that `std::panic!("{}")` and even `std::panic!(&"hi")` compile without errors or warnings, even though these are most likely mistakes.++*💔 **Problem 3:** `panic!(123)`, `panic!(&"..")`, `panic!(b"..")`, etc. are probably mistakes, but compile fine with `std`.*++In the case of `core::panic!(x)`, `x` must be a `&str`, but does not have to be a string literal, nor does it have to be `'static`.+This means that `core::panic!("{}")` and `core::panic!(string.as_str())` compile fine.++*💔 **Problem 4:** `let error = String::from("error"); panic!(&error);` works fine in `no_std` code, but no longer compiles when switching `no_std` off.*++*💔 **Problem 5:** `panic!(CustomError::Error);` works with std, but no longer compiles when switching `no_std` on.*++## Assert++`assert!(expr, args..)` and `assert_debug(expr, args..)` expand to `panic!(args..)` and therefore will have all the same problems.+In addition, these can result in confusing mistakes:++```rust+assert!(v.is_empty(), false); // runs panic!(false) if v is not empty  😕+```++*💔 **Problem 6:** `assert!(expr, expr)` should probably have been a `assert_eq!`, but compiles fine and gives no useful panic message.*++Because `core::panic!` and `std::panic!` are different, `assert!` and related macros expand to `panic!(..)`, not to `$crate::panic!(..)`,+making these macros not work with `#![no_implicit_prelude]`, as reported in [#78333](https://github.com/rust-lang/rust/issues/78333).+This also means that the panic of an assert can be accidentally 'hijacked' by a locally defined `panic!` macro.++*💔 **Problem 7:** `assert!` and related macros need to choose between `core::panic!` and `std::panic!`, and can't use `$crate::panic!` for proper hygiene.*++## Implicit formatting arguments++[RFC 2795] adds implicit formatting args, as follows:++```rust+let a = 4;+println!("a is {a}");+```++It modifies `format_args!()` to automatically capture variables that are named in a formatting placeholder.++With the current implementations of `panic!()` (both core's and std's), this would not work if there are no additional explicit arguments:++```rust+let a = 4;++println!("{}", a); // prints `4`+panic!("{}", a); // panics with `4`++println!("{a}"); // prints `4`+panic!("{a}"); // panics with `{a}`  😕++println!("{a} {}", 4); // prints `4 4`+panic!("{a} {}", 4); // panics with `4 4`+```++*💔 **Problem 8:** `panic!("error: {error}")` will silently not work as expected, after [RFC 2795] is implemented.*++## Bloat++`core::panic!("hello {")` produces the same `fmt::Arguments` as `format_args!("hello {{")`, not `format_args!("{}", "hello {")` to avoid pulling in string's `Display` code,+which can be quite big.++However, `core::panic!(non_static_str)` does need to expand to `format_args!("{}", non_static_str)`, because `fmt::Arguments` requires a `'static` lifetime+for the non-formatted pieces. Because the `panic!` `macro_rules` macro can't distinguish between non-`'static` and `'static` values,+this optimization is only applied to what macro_rules consider a `$_:literal`, which does not include `concat!(..)` or `CONST_STR`.++*💔 **Problem 9:** `const CONST_STR: &'static str = "hi"; core::panic!(CONST_STR)` works,+but will silently result in a lot more generated code than `core::panic!("hi")`.+(And also needs [special handling](https://github.com/rust-lang/rust/pull/78069) to make `const_panic` work.)*++# Solution if we could go back in time++None of these these problems would have existed if+1\) `panic!()` did not handle the single-argument case differently, and+2\) `std::panic!` was no different than `core::panic!`:++```rust+// core+macro_rules! panic {+    () => (+        $crate::panic!("explicit panic")+    );+    ($($t:tt)*) => (+        $crate::panicking::panic_fmt($crate::format_args!($($t)+))+    );+}++// std+use core::panic;+```++The examples from problems 1, 2, 3, 4, 5, 6 and 9 would simply not compile, and problems 7 and 8 would not occur.++However, that would break too much existing code.++# Proposed solution++Considering we should not break existing code, I propose we gate the breaking changs on the 2021 edition.++In addition, we add a lint that *warns* about the problems in Rust 2015/2018, while not giving errors or changing the behaviour.++Specifically:++- Only for Rust 2021, we apply the breaking changes as in the previous section.

That'd still make sense right? You're now passing the macro the 2021 panic, not the 2018 panic. With this style of macro, it's the responsibility of the caller to provide it with the name of a macro that works. Just like custom_invoke!(println) also wouldn't compile. So I'd say the breakage in this example is in the 2021 crate that calls the macro, not in the 2018 one that defines it.

m-ou-se

comment created time in 16 minutes

PullRequestReviewEvent

issue closedrust-lang/wg-allocators

Compat of adding parameters to stable types

Are there backward-compatibility issues with adding a defaulted type parameter to a stable type? For example changing:

struct Vec<T> {…}

To:

struct Vec<T, A: Alloc = Global> {…}

The API Evolution RFC claims this is not a major breaking change, but I vaguely recall discussion of type inference being negatively affected.

Is https://github.com/rust-lang/rust/issues/27336 relevant here?

closed time in 16 minutes

SimonSapin

issue commentrust-lang/wg-allocators

Compat of adding parameters to stable types

We tested this with rust-lang/rust#71873 and rust-lang/rust#77187.

SimonSapin

comment created time in 16 minutes

pull request commentrust-lang/rust

Uplift `temporary-cstring-as-ptr` lint from `clippy` into rustc

Rebased and addressed comments. I'm not sure why this failed in rollup before, hopefully it's resolved now? @rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

nathanwhit

comment created time in 17 minutes

startedrust-lang/rustlings

started time in 17 minutes

startedrust-lang/rust

started time in 17 minutes

issue openedrust-lang/cargo

Pass --cfg doc to check builds of dependencies as part of cargo doc/rustdoc

Problem Some packages such as llvm-sys have workarounds that allow their docs to build on docs.rs despite the fact that no usable binary can be generated (in this case because it relies on a platform binary that is not present on docs.rs). Essentially it uses detection of #[cfg(doc)] to allow builds to succeed when they would otherwise fail. This works well today.

However, when this project is a dependency in another project, cargo doc will not just run rustdoc, it will also invoke rustc to perform a check build. This bypasses any #[cfg(doc)] protections because it runs without --cfg doc. It is currently not possible to detect that your crate is being compiled in check mode as part of a larger doc run. The desired build characteristics, however, are the same. We don't need a working binary, and we're invoking the compiler for the purpose of docs.

It's also very strange to have a case where cargo doc works on a project but not when that project.

I've produced a minimal example of this that demonstrates the issue without all the cruft of thinking about LLVM and system dependencies.

Steps <!-- The steps to reproduce the bug. -->

  1. Clone (djrenren/cargo-doc-failure)[https://github.com/djrenren/cargo-doc-failure]
  2. cd app
  3. cargo rustdoc

Notice this fails while cargo rustdoc in the dependency succeeds. A

Current Workarounds Local workaround: $ RUSTFLAGS="--cfg doc" cargo doc

Docs.rs workaround: Cargo.toml:

[package.metadata.docs.rs]
rustc-args = [ "--cfg" , "doc"]

Suggested Solution(s)

  1. As suggested in the title of the issue, pass the doc config flag in while doing check builds as part of cargo rustdoc

  2. Provide a standard way to add cfg flags to libraries when built as part of rustdoc. That is, standardize what docs.rs already does so that it works locally as well.

Notes This occurs on all cargo versions I've been able to find so the version is largely irrelevant, but let's say latest stable 1.47.0

Passing a doc flag by default to check builds could produce strange results if downstream crates use doc cfg's to change the interface of their crate, which may be a point in favor of solution 2.

created time in 18 minutes

push eventrust-lang/crates.io-index

bors

commit sha fb64571cefe908fa061583091f859b0dbf3d80d6

Updating crate `gfx-backend-metal#0.6.4`

view details

push time in 20 minutes

Pull request review commentrust-lang/rust-clippy

Add invalid null pointer usage lint.

 vec![         deprecation: None,         module: "atomic_ordering",     },+    Lint {+        name: "invalid_null_usage",+        group: "correctness",+        desc: "invalid usage of a null pointer, suggesting `NonNull::dangling()` instead.",
        desc: "invalid usage of a null pointer, suggesting `NonNull::dangling()` instead",

nit

boxdot

comment created time in an hour

Pull request review commentrust-lang/rust-clippy

Add invalid null pointer usage lint.

 declare_clippy_lint! {     "fns that create mutable refs from immutable ref args" } -declare_lint_pass!(Ptr => [PTR_ARG, CMP_NULL, MUT_FROM_REF]);+declare_clippy_lint! {+    /// **What it does:** This lint checks for invalid usages of `ptr::null`.+    ///+    /// **Why is this bad?** This causes undefined behavior.+    ///+    /// **Known problems:** None.+    ///+    /// **Example:**+    /// ```ignore+    /// // Bad. Undefined behavior+    /// unsafe { std::slice::from_raw_parts(ptr::null(), 0); }+    /// ```+    ///+    /// // Good+    /// unsafe { std::slice::from_raw_parts(NonNull::dangling().as_ptr(), 0); }+    /// ```+    pub INVALID_NULL_USAGE,+    correctness,+    "invalid usage of a null pointer, suggesting `NonNull::dangling()` instead."
    "invalid usage of a null pointer, suggesting `NonNull::dangling()` instead"

nit

boxdot

comment created time in 31 minutes

Pull request review commentrust-lang/rust-clippy

Add invalid null pointer usage lint.

+// run-rustfix++fn main() {+    let _slice: &[usize] = unsafe { std::slice::from_raw_parts(std::ptr::null(), 0) };+    let _slice: &[usize] = unsafe { std::slice::from_raw_parts(core::ptr::null(), 0) };

Let's add a test where the parameter is a call to std::ptr::null_mut()

boxdot

comment created time in an hour

PullRequestReviewEvent
PullRequestReviewEvent

pull request commentrust-lang/rust

Associate an allocator to boxes

In case anyone subscribed here and want an update: #77187 just got merged :rocket:

glandium

comment created time in 20 minutes

Pull request review commentrust-lang/rfcs

RFC: Plan to make core and std's panic identical.

+- Start Date: 2020-10-25+- RFC PR: [rust-lang/rfcs#3007](https://github.com/rust-lang/rfcs/pull/3007)+- Rust Issue: -++# Summary++This RFC proposes to make `core::panic!` and `std::panic!` identical and consistent in Rust 2021,+and proposes a way to deal with the differences in earlier editions without breaking code.++# Problems++`core::panic!` and `std::panic!` behave mostly the same, but have their own incompatible quirks for the single-argument case.++This leads to several different problems, which would all be solved if they didn't special-case `panic!(one_argument)`.++For multiple-arguments (e.g. `panic!("error: {}", e)`), both already behave identical.++## Panic++Both do not use `format_args!("..")` for `panic!("..")` like they do for multiple arguments, but use the string literally.++*💔 **Problem 1:** `panic!("error: {}")` is probably a mistake, but compiles fine.*++*💔 **Problem 2:** `panic!("Here's a brace: {{")` outputs two braces (`{{`), not one (`{`).*++In the case of `std::panic!(x)`, `x` does not have to be a string literal, but can be of any (`Any + Send`) type.+This means that `std::panic!("{}")` and even `std::panic!(&"hi")` compile without errors or warnings, even though these are most likely mistakes.++*💔 **Problem 3:** `panic!(123)`, `panic!(&"..")`, `panic!(b"..")`, etc. are probably mistakes, but compile fine with `std`.*++In the case of `core::panic!(x)`, `x` must be a `&str`, but does not have to be a string literal, nor does it have to be `'static`.+This means that `core::panic!("{}")` and `core::panic!(string.as_str())` compile fine.++*💔 **Problem 4:** `let error = String::from("error"); panic!(&error);` works fine in `no_std` code, but no longer compiles when switching `no_std` off.*++*💔 **Problem 5:** `panic!(CustomError::Error);` works with std, but no longer compiles when switching `no_std` on.*++## Assert++`assert!(expr, args..)` and `assert_debug(expr, args..)` expand to `panic!(args..)` and therefore will have all the same problems.+In addition, these can result in confusing mistakes:++```rust+assert!(v.is_empty(), false); // runs panic!(false) if v is not empty  😕+```++*💔 **Problem 6:** `assert!(expr, expr)` should probably have been a `assert_eq!`, but compiles fine and gives no useful panic message.*++Because `core::panic!` and `std::panic!` are different, `assert!` and related macros expand to `panic!(..)`, not to `$crate::panic!(..)`,+making these macros not work with `#![no_implicit_prelude]`, as reported in [#78333](https://github.com/rust-lang/rust/issues/78333).+This also means that the panic of an assert can be accidentally 'hijacked' by a locally defined `panic!` macro.++*💔 **Problem 7:** `assert!` and related macros need to choose between `core::panic!` and `std::panic!`, and can't use `$crate::panic!` for proper hygiene.*++## Implicit formatting arguments++[RFC 2795] adds implicit formatting args, as follows:++```rust+let a = 4;+println!("a is {a}");+```++It modifies `format_args!()` to automatically capture variables that are named in a formatting placeholder.++With the current implementations of `panic!()` (both core's and std's), this would not work if there are no additional explicit arguments:++```rust+let a = 4;++println!("{}", a); // prints `4`+panic!("{}", a); // panics with `4`++println!("{a}"); // prints `4`+panic!("{a}"); // panics with `{a}`  😕++println!("{a} {}", 4); // prints `4 4`+panic!("{a} {}", 4); // panics with `4 4`+```++*💔 **Problem 8:** `panic!("error: {error}")` will silently not work as expected, after [RFC 2795] is implemented.*++## Bloat++`core::panic!("hello {")` produces the same `fmt::Arguments` as `format_args!("hello {{")`, not `format_args!("{}", "hello {")` to avoid pulling in string's `Display` code,+which can be quite big.++However, `core::panic!(non_static_str)` does need to expand to `format_args!("{}", non_static_str)`, because `fmt::Arguments` requires a `'static` lifetime+for the non-formatted pieces. Because the `panic!` `macro_rules` macro can't distinguish between non-`'static` and `'static` values,+this optimization is only applied to what macro_rules consider a `$_:literal`, which does not include `concat!(..)` or `CONST_STR`.++*💔 **Problem 9:** `const CONST_STR: &'static str = "hi"; core::panic!(CONST_STR)` works,+but will silently result in a lot more generated code than `core::panic!("hi")`.+(And also needs [special handling](https://github.com/rust-lang/rust/pull/78069) to make `const_panic` work.)*++# Solution if we could go back in time++None of these these problems would have existed if+1\) `panic!()` did not handle the single-argument case differently, and+2\) `std::panic!` was no different than `core::panic!`:++```rust+// core+macro_rules! panic {+    () => (+        $crate::panic!("explicit panic")+    );+    ($($t:tt)*) => (+        $crate::panicking::panic_fmt($crate::format_args!($($t)+))+    );+}++// std+use core::panic;+```++The examples from problems 1, 2, 3, 4, 5, 6 and 9 would simply not compile, and problems 7 and 8 would not occur.++However, that would break too much existing code.++# Proposed solution++Considering we should not break existing code, I propose we gate the breaking changs on the 2021 edition.++In addition, we add a lint that *warns* about the problems in Rust 2015/2018, while not giving errors or changing the behaviour.++Specifically:++- Only for Rust 2021, we apply the breaking changes as in the previous section.

That sounds reasonable to me. Note that this will be a 'best effort' approach to preventing breakage. With a somewhat contrived macro, this approach can be made to fail:

macro_rules! custom_invoke {
    ($name:ident) => {
        $name!("My panic: {}")
    }
}

fn main() {
    custom_invoke!(panic)
}

That is, a higher-order macro would use the ident panic from a 2021 edition crate, causing the new behavior to be used.

While this particular macro seems very unrealistic, there are some places in rustc that actually use higher-order macros. Unfortunately, I think we need to accept some amount of breakage if this RFC is accepted.

m-ou-se

comment created time in 21 minutes

pull request commentrust-lang/rust

Make CTFE able to check for UB...

Finished benchmarking try commit (3dbdd3b981f75f965ac04452739653a3d47ff0ed): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never

oli-obk

comment created time in 21 minutes

pull request commentrust-lang/rust

Suggest calling associated `fn` inside `trait`s

r? @petrochenkov

(rust_highfive has picked a reviewer for you, use r? to override)

estebank

comment created time in 21 minutes

PullRequestReviewEvent

PR opened rust-lang/rust

Suggest calling associated `fn` inside `trait`s

When calling a function that doesn't exist inside of a trait's associated fn, and another associated fn in that trait has that name, suggest calling it with the appropriate fully-qualified path.

Expand the label to be more descriptive.

Prompted by the following user experience: https://users.rust-lang.org/t/cannot-find-function/50663

+129 -49

0 comment

9 changed files

pr created time in 21 minutes

push eventrust-lang/crates.io-index

bors

commit sha b84b3e0a149af50fc8b5ae98647ea6d3ca294e05

Updating crate `astrolab-smart-coffee-types#0.0.10010`

view details

push time in 23 minutes

push eventrust-lang/crates.io-index

bors

commit sha ee46ad8646cc58213b442ec1abbf5cedf88cb6ec

Updating crate `haybale#0.6.3`

view details

push time in 24 minutes

pull request commentrust-lang/rust

rustc_span: avoid hashing ExpnId tag when using cached hash

Queued c78e1a98403d935f0d0ab399b69944da91214f16 with parent 0da6d42f297642a60f2640ec313b879b376b9ad8, future comparison URL.

tgnottingham

comment created time in 25 minutes

pull request commentrust-lang/rust

rustc_span: avoid hashing ExpnId tag when using cached hash

:sunny: Try build successful - checks-actions Build commit: c78e1a98403d935f0d0ab399b69944da91214f16 (c78e1a98403d935f0d0ab399b69944da91214f16) <!-- homu: {"type":"TryBuildCompleted","builders":{"checks-actions":"https://github.com/rust-lang-ci/rust/runs/1311823030"},"merge_sha":"c78e1a98403d935f0d0ab399b69944da91214f16"} -->

tgnottingham

comment created time in 25 minutes

pull request commentrust-lang/rust

Compile rustc crates with the initial-exec TLS model

cg_clif is only loaded using dlopen. Adding it as dependency of rustc would require specifying the path to every rustc dependency instead of loading them from the sysroot. This doesn't work for out of tree development.

joshtriplett

comment created time in 25 minutes

pull request commentrust-lang/rust

Fix `x.py clippy`

The outstanding comments are:

  • --fix doesn't work: https://github.com/rust-lang/rust/pull/77351#issuecomment-701893783
  • We might also want to have x.py download clippy on demand (when running clippy) so that there's less version problems: https://github.com/rust-lang/rust/pull/77351#issuecomment-701071012

I think both of these can be addressed in follow-ups, they're improvements more than bugfixes. But I'm happy to work on them here if you want.

jyn514

comment created time in 26 minutes

PR merged rust-lang/rust

Support custom allocators in `Box` A-allocators S-waiting-on-bors T-libs merged-by-bors

r? @Amanieu

This pull request requires a crater run.

Prior work:

Currently blocked on:

  • ~#77118~
  • ~https://github.com/rust-lang/chalk/issues/615 (#77515)~
+577 -215

36 comments

30 changed files

TimDiekmann

pr closed time in 27 minutes

pull request commentrust-lang/rust

Support custom allocators in `Box`

📣 Toolstate changed by rust-lang/rust#77187!

Tested on commit rust-lang/rust@fd542592f08ca0d1f7255600115c2eafdf6b5da7. Direct link to PR: https://github.com/rust-lang/rust/pull/77187

💔 miri on windows: test-pass → test-fail (cc @oli-obk @eddyb @RalfJung). 💔 miri on linux: test-pass → test-fail (cc @oli-obk @eddyb @RalfJung).

TimDiekmann

comment created time in 27 minutes

issue openedrust-lang/rust

`miri` no longer builds after rust-lang/rust#77187

Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust#77187, I observed that the tool miri has failing tests. A follow-up PR to the repository https://github.com/rust-lang/miri is needed to fix the fallout.

cc @TimDiekmann, do you think you would have time to do the follow-up work? If so, that would be great!

created time in 27 minutes

Pull request review commentrust-lang/rfcs

RFC: Plan to make core and std's panic identical.

+- Start Date: 2020-10-25+- RFC PR: [rust-lang/rfcs#3007](https://github.com/rust-lang/rfcs/pull/3007)+- Rust Issue: -++# Summary++This RFC proposes to make `core::panic!` and `std::panic!` identical and consistent in Rust 2021,+and proposes a way to deal with the differences in earlier editions without breaking code.++# Problems++`core::panic!` and `std::panic!` behave mostly the same, but have their own incompatible quirks for the single-argument case.++This leads to several different problems, which would all be solved if they didn't special-case `panic!(one_argument)`.++For multiple-arguments (e.g. `panic!("error: {}", e)`), both already behave identical.++## Panic++Both do not use `format_args!("..")` for `panic!("..")` like they do for multiple arguments, but use the string literally.++*💔 **Problem 1:** `panic!("error: {}")` is probably a mistake, but compiles fine.*++*💔 **Problem 2:** `panic!("Here's a brace: {{")` outputs two braces (`{{`), not one (`{`).*++In the case of `std::panic!(x)`, `x` does not have to be a string literal, but can be of any (`Any + Send`) type.+This means that `std::panic!("{}")` and even `std::panic!(&"hi")` compile without errors or warnings, even though these are most likely mistakes.++*💔 **Problem 3:** `panic!(123)`, `panic!(&"..")`, `panic!(b"..")`, etc. are probably mistakes, but compile fine with `std`.*++In the case of `core::panic!(x)`, `x` must be a `&str`, but does not have to be a string literal, nor does it have to be `'static`.+This means that `core::panic!("{}")` and `core::panic!(string.as_str())` compile fine.++*💔 **Problem 4:** `let error = String::from("error"); panic!(&error);` works fine in `no_std` code, but no longer compiles when switching `no_std` off.*++*💔 **Problem 5:** `panic!(CustomError::Error);` works with std, but no longer compiles when switching `no_std` on.*++## Assert++`assert!(expr, args..)` and `assert_debug(expr, args..)` expand to `panic!(args..)` and therefore will have all the same problems.+In addition, these can result in confusing mistakes:++```rust+assert!(v.is_empty(), false); // runs panic!(false) if v is not empty  😕+```++*💔 **Problem 6:** `assert!(expr, expr)` should probably have been a `assert_eq!`, but compiles fine and gives no useful panic message.*++Because `core::panic!` and `std::panic!` are different, `assert!` and related macros expand to `panic!(..)`, not to `$crate::panic!(..)`,+making these macros not work with `#![no_implicit_prelude]`, as reported in [#78333](https://github.com/rust-lang/rust/issues/78333).+This also means that the panic of an assert can be accidentally 'hijacked' by a locally defined `panic!` macro.++*💔 **Problem 7:** `assert!` and related macros need to choose between `core::panic!` and `std::panic!`, and can't use `$crate::panic!` for proper hygiene.*++## Implicit formatting arguments++[RFC 2795] adds implicit formatting args, as follows:++```rust+let a = 4;+println!("a is {a}");+```++It modifies `format_args!()` to automatically capture variables that are named in a formatting placeholder.++With the current implementations of `panic!()` (both core's and std's), this would not work if there are no additional explicit arguments:++```rust+let a = 4;++println!("{}", a); // prints `4`+panic!("{}", a); // panics with `4`++println!("{a}"); // prints `4`+panic!("{a}"); // panics with `{a}`  😕++println!("{a} {}", 4); // prints `4 4`+panic!("{a} {}", 4); // panics with `4 4`+```++*💔 **Problem 8:** `panic!("error: {error}")` will silently not work as expected, after [RFC 2795] is implemented.*++## Bloat++`core::panic!("hello {")` produces the same `fmt::Arguments` as `format_args!("hello {{")`, not `format_args!("{}", "hello {")` to avoid pulling in string's `Display` code,+which can be quite big.++However, `core::panic!(non_static_str)` does need to expand to `format_args!("{}", non_static_str)`, because `fmt::Arguments` requires a `'static` lifetime+for the non-formatted pieces. Because the `panic!` `macro_rules` macro can't distinguish between non-`'static` and `'static` values,+this optimization is only applied to what macro_rules consider a `$_:literal`, which does not include `concat!(..)` or `CONST_STR`.++*💔 **Problem 9:** `const CONST_STR: &'static str = "hi"; core::panic!(CONST_STR)` works,+but will silently result in a lot more generated code than `core::panic!("hi")`.+(And also needs [special handling](https://github.com/rust-lang/rust/pull/78069) to make `const_panic` work.)*++# Solution if we could go back in time++None of these these problems would have existed if+1\) `panic!()` did not handle the single-argument case differently, and+2\) `std::panic!` was no different than `core::panic!`:++```rust+// core+macro_rules! panic {+    () => (+        $crate::panic!("explicit panic")+    );+    ($($t:tt)*) => (+        $crate::panicking::panic_fmt($crate::format_args!($($t)+))+    );+}++// std+use core::panic;+```++The examples from problems 1, 2, 3, 4, 5, 6 and 9 would simply not compile, and problems 7 and 8 would not occur.++However, that would break too much existing code.++# Proposed solution++Considering we should not break existing code, I propose we gate the breaking changs on the 2021 edition.++In addition, we add a lint that *warns* about the problems in Rust 2015/2018, while not giving errors or changing the behaviour.++Specifically:++- Only for Rust 2021, we apply the breaking changes as in the previous section.

That's a good question. We could either look at the edition of the span of panic or at the edition of the span of "Weird format: {}".

I think the former would make most sense. Then the macro doesn't change its behaviour until it is updated to Rust 2021 itself.

What do you think?

m-ou-se

comment created time in 27 minutes

PullRequestReviewEvent

pull request commentrust-lang/rust

Remove unused set-discriminant statements and assignments regardless of rvalue

:hourglass: Testing commit 4c3e06a0ba557c5915d8c00f23455461549f07f6 with merge a4d30a7b490065f0aa56f58e508a11546445aea9... <!-- homu: {"type":"BuildStarted","head_sha":"4c3e06a0ba557c5915d8c00f23455461549f07f6","merge_sha":"a4d30a7b490065f0aa56f58e508a11546445aea9"} -->

tmiasko

comment created time in 28 minutes

pull request commentrust-lang/rust

Support custom allocators in `Box`

Error: Only Rust team members can ping teams.

Please let @rust-lang/release know if you're having trouble with this bot.

TimDiekmann

comment created time in 28 minutes

pull request commentrust-lang/rust

Support custom allocators in `Box`

@rustbot ping infra

The merged succeeded, but a CI job failed. I don't know, what the job is about, but the fail is unrelated to this PR.

TimDiekmann

comment created time in 28 minutes

push eventrust-lang/rust

Tim Diekmann

commit sha f288cd2e179f600fa00c2a407206a12f6c5a91e0

Support custom allocators in `Box` Remove `Box::leak_with_alloc` Add leak-test for box with allocator Rename `AllocErr` to `AllocError` in leak-test Add `Box::alloc` and adjust examples to use the new API

view details

Tim Diekmann

commit sha d5720bba8f5b278616a2fbd0da39478879a3f68b

Fix mir-opt output for 32 bit

view details

Tim Diekmann

commit sha 955b37b3059a7e06842559af54e1685e33b0cf6c

Merge branch 'master' into box-alloc

view details

Tim Diekmann

commit sha 693a2bf18b7090202784f561de3dfca45c4f79be

Rename `Box::alloc` to `Box::alloc_ref`

view details

Tim Diekmann

commit sha 06e4497a04615ad95dff4240ca9980f19ed364ad

Merge remote-tracking branch 'upstream/master' into box-alloc

view details

bors

commit sha fd542592f08ca0d1f7255600115c2eafdf6b5da7

Auto merge of #77187 - TimDiekmann:box-alloc, r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~

view details

push time in 28 minutes

pull request commentrust-lang/rust

Support custom allocators in `Box`

:sunny: Test successful - checks-actions Approved by: Amanieu Pushing fd542592f08ca0d1f7255600115c2eafdf6b5da7 to master... <!-- homu: {"type":"BuildCompleted","approved_by":"Amanieu","base_ref":"master","builders":{"checks-actions":"https://github.com/rust-lang-ci/rust/runs/1311811632"},"merge_sha":"fd542592f08ca0d1f7255600115c2eafdf6b5da7"} -->

TimDiekmann

comment created time in 28 minutes

push eventrust-lang/crates.io-index

bors

commit sha b3e0d158abfc57f2436686b915d862699c3f15ee

Updating crate `gfx-auxil#0.7.0`

view details

push time in 28 minutes

pull request commentrust-lang/rfcs

RFC: Plan to make core and std's panic identical.

If progress is made on implementing future-incompat-report, we could enable it for the lint referenced by this RFC.

m-ou-se

comment created time in 29 minutes

pull request commentrust-lang/rust

Implement -Z function-sections=yes|no

:pushpin: Commit 056942215cf8dc39686fa80e42b4e73657d4fed5 has been approved by nagisa,bjorn3

<!-- @bors r=nagisa,bjorn3 056942215cf8dc39686fa80e42b4e73657d4fed5 --> <!-- homu: {"type":"Approved","sha":"056942215cf8dc39686fa80e42b4e73657d4fed5","approver":"nagisa,bjorn3"} -->

nox

comment created time in 29 minutes

pull request commentrust-lang/rust

Implement -Z function-sections=yes|no

@bors r=nagisa,bjorn3

nox

comment created time in 29 minutes

issue openedrust-lang/rust.vim

:Cargo commands runs ! cargo run as the prefix

<!--

Hi, and thanks for reporting an issue with rust.vim.

Details about your environment will help us assist you.

Please edit this template!

-->

  • rust.vim version: Using vim-plug with neovim, latest rust.vim version from master<!-- Describe if you use a Vim plugin manager, and you can use it to tell which version of rust.vim you are running. -->

Steps to reproduce:

<!-- It's best to try to reproduce the issue with the master version of rust.vim. The issue may already be fixed! -->

  1. Install rust.vim in vim-plug
  2. Add let g:cargo_shell_command_runner = '!' to your init.vim to see the verbose commands
  3. Open a rust file and use any :Cargo[X] command

Expected vs. actual behavior:

Expected: :CargoRun runs cargo run and shows it in the buffer Actual: :CargoRun runs cargo run run, Cargo[X] commands all have the ! cargo run prefix, :Crun and related commands works fine https://imgur.com/a/C4yac7g

Paste debugging info from the Rust Vim plugin via one of the following commands: :RustInfo, :RustInfoToClipboard, or :RustInfoToFile <filename>.

https://pastebin.com/BErZ7Q3E

created time in 29 minutes

push eventrust-lang/crates.io-index

bors

commit sha 1d3d783bfce5ad7db652ace30a9ebae8671adec3

Updating crate `audiotags#0.2.1`

view details

push time in 30 minutes

Pull request review commentrust-lang/rfcs

RFC: Plan to make core and std's panic identical.

+- Start Date: 2020-10-25+- RFC PR: [rust-lang/rfcs#3007](https://github.com/rust-lang/rfcs/pull/3007)+- Rust Issue: -++# Summary++This RFC proposes to make `core::panic!` and `std::panic!` identical and consistent in Rust 2021,+and proposes a way to deal with the differences in earlier editions without breaking code.++# Problems++`core::panic!` and `std::panic!` behave mostly the same, but have their own incompatible quirks for the single-argument case.++This leads to several different problems, which would all be solved if they didn't special-case `panic!(one_argument)`.++For multiple-arguments (e.g. `panic!("error: {}", e)`), both already behave identical.++## Panic++Both do not use `format_args!("..")` for `panic!("..")` like they do for multiple arguments, but use the string literally.++*💔 **Problem 1:** `panic!("error: {}")` is probably a mistake, but compiles fine.*++*💔 **Problem 2:** `panic!("Here's a brace: {{")` outputs two braces (`{{`), not one (`{`).*++In the case of `std::panic!(x)`, `x` does not have to be a string literal, but can be of any (`Any + Send`) type.+This means that `std::panic!("{}")` and even `std::panic!(&"hi")` compile without errors or warnings, even though these are most likely mistakes.++*💔 **Problem 3:** `panic!(123)`, `panic!(&"..")`, `panic!(b"..")`, etc. are probably mistakes, but compile fine with `std`.*++In the case of `core::panic!(x)`, `x` must be a `&str`, but does not have to be a string literal, nor does it have to be `'static`.+This means that `core::panic!("{}")` and `core::panic!(string.as_str())` compile fine.++*💔 **Problem 4:** `let error = String::from("error"); panic!(&error);` works fine in `no_std` code, but no longer compiles when switching `no_std` off.*++*💔 **Problem 5:** `panic!(CustomError::Error);` works with std, but no longer compiles when switching `no_std` on.*++## Assert++`assert!(expr, args..)` and `assert_debug(expr, args..)` expand to `panic!(args..)` and therefore will have all the same problems.+In addition, these can result in confusing mistakes:++```rust+assert!(v.is_empty(), false); // runs panic!(false) if v is not empty  😕+```++*💔 **Problem 6:** `assert!(expr, expr)` should probably have been a `assert_eq!`, but compiles fine and gives no useful panic message.*++Because `core::panic!` and `std::panic!` are different, `assert!` and related macros expand to `panic!(..)`, not to `$crate::panic!(..)`,+making these macros not work with `#![no_implicit_prelude]`, as reported in [#78333](https://github.com/rust-lang/rust/issues/78333).+This also means that the panic of an assert can be accidentally 'hijacked' by a locally defined `panic!` macro.++*💔 **Problem 7:** `assert!` and related macros need to choose between `core::panic!` and `std::panic!`, and can't use `$crate::panic!` for proper hygiene.*++## Implicit formatting arguments++[RFC 2795] adds implicit formatting args, as follows:++```rust+let a = 4;+println!("a is {a}");+```++It modifies `format_args!()` to automatically capture variables that are named in a formatting placeholder.++With the current implementations of `panic!()` (both core's and std's), this would not work if there are no additional explicit arguments:++```rust+let a = 4;++println!("{}", a); // prints `4`+panic!("{}", a); // panics with `4`++println!("{a}"); // prints `4`+panic!("{a}"); // panics with `{a}`  😕++println!("{a} {}", 4); // prints `4 4`+panic!("{a} {}", 4); // panics with `4 4`+```++*💔 **Problem 8:** `panic!("error: {error}")` will silently not work as expected, after [RFC 2795] is implemented.*++## Bloat++`core::panic!("hello {")` produces the same `fmt::Arguments` as `format_args!("hello {{")`, not `format_args!("{}", "hello {")` to avoid pulling in string's `Display` code,+which can be quite big.++However, `core::panic!(non_static_str)` does need to expand to `format_args!("{}", non_static_str)`, because `fmt::Arguments` requires a `'static` lifetime+for the non-formatted pieces. Because the `panic!` `macro_rules` macro can't distinguish between non-`'static` and `'static` values,+this optimization is only applied to what macro_rules consider a `$_:literal`, which does not include `concat!(..)` or `CONST_STR`.++*💔 **Problem 9:** `const CONST_STR: &'static str = "hi"; core::panic!(CONST_STR)` works,+but will silently result in a lot more generated code than `core::panic!("hi")`.+(And also needs [special handling](https://github.com/rust-lang/rust/pull/78069) to make `const_panic` work.)*++# Solution if we could go back in time++None of these these problems would have existed if+1\) `panic!()` did not handle the single-argument case differently, and+2\) `std::panic!` was no different than `core::panic!`:++```rust+// core+macro_rules! panic {+    () => (+        $crate::panic!("explicit panic")+    );+    ($($t:tt)*) => (+        $crate::panicking::panic_fmt($crate::format_args!($($t)+))+    );+}++// std+use core::panic;+```++The examples from problems 1, 2, 3, 4, 5, 6 and 9 would simply not compile, and problems 7 and 8 would not occur.++However, that would break too much existing code.++# Proposed solution++Considering we should not break existing code, I propose we gate the breaking changs on the 2021 edition.++In addition, we add a lint that *warns* about the problems in Rust 2015/2018, while not giving errors or changing the behaviour.++Specifically:++- Only for Rust 2021, we apply the breaking changes as in the previous section.

How will this interact with macro expansion? For example, if I have the following code:

// crate2018 (2018 edition):

macro_rules! custom_panic {
    ($($arg:tt),*) => {
        panic!($($arg),*)
    }
}

fn foo() {
	custom_panic!("Weird format: {}");
}


// crate2021 (2021 edition)

fn bar() { custom_panic!("Weird format: {}"); }

m-ou-se

comment created time in 32 minutes

PullRequestReviewEvent
PullRequestReviewEvent

startedrust-lang/rust.vim

started time in 33 minutes

issue openedrust-lang/rust-clippy

`while_let_on_iterator` does not consider the borrow checker

This output is from running clippy on https://github.com/rust-lang/stdarch/blob/598e632e8f62ff5054dfe0d0fabb2a03ecee0a3d/crates/stdarch-test/src/disassembly.rs#L102-L116. The relevant snippet is

    while let Some(header) = cached_header.take().or_else(|| lines.next()) {
        while let Some(instruction) = lines.next() {
        }
    }

$ cargo clippy --fix -Z unstable-options after fixes were automatically applied the compiler reported errors within these files:

  • crates/stdarch-test/src/disassembly.rs

This likely indicates a bug in either rustc or cargo itself, and we would appreciate a bug report! You're likely to see a number of compiler warnings after this message which cargo attempted to fix but failed. If you could open an issue at https://github.com/rust-lang/rust/issues quoting the full output of this command we'd be very appreciative! Note that you may be able to make some more progress in the near-term fixing code with the --broken-code flag

The following errors were reported: error[E0382]: borrow of moved value: lines --> crates/stdarch-test/src/disassembly.rs:117:59 | 105 | let mut lines = output.lines(); | --------- move occurs because lines has type std::str::Lines<'_>, which does not implement the Copy trait ... 117 | while let Some(header) = cached_header.take().or_else(|| lines.next()) { | ^^ ----- borrow occurs due to use in closure | | | value borrowed here after move ... 125 | for instruction in lines { | ----- | | | value moved here, in previous iteration of loop | help: consider borrowing to avoid moving into the for loop: &lines

error: aborting due to previous error

For more information about this error, try rustc --explain E0382. Original diagnostics will follow.

warning: this loop could be written as a for loop --> crates/stdarch-test/src/disassembly.rs:125:9 | 125 | while let Some(instruction) = lines.next() { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: try: for instruction in lines | = note: #[warn(clippy::while_let_on_iterator)] on by default = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#while_let_on_iterator

warning: this loop could be written as a for loop --> crates/stdarch-test/src/disassembly.rs:125:9 | 125 | while let Some(instruction) = lines.next() { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: try: for instruction in lines | = note: #[warn(clippy::while_let_on_iterator)] on by default = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#while_let_on_iterator

created time in 34 minutes

push eventrust-lang/discord-mods-bot

technetos

commit sha 66de16539acfecc23e89c4da54710433f4682d7f

fmt

view details

push time in 36 minutes

push eventrust-lang/discord-mods-bot

technetos

commit sha ee30bb1c65c795c5afaec5e0ad85acdb82cb03cc

Fix welcome message logic

view details

push time in 38 minutes

issue openedrust-lang/rust-clippy

`unused_unit` adds whitespaces after function declarations

<!-- Thank you for filing a bug report! 🐛 Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. -->

I tried this code (https://github.com/rust-lang/stdarch/blob/598e632e8f62ff5054dfe0d0fabb2a03ecee0a3d/crates/core_arch/src/x86_64/xsave.rs#L8-L11):

extern "C" {
    fn xsave64(p: *mut u8, hi: u32, lo: u32) -> ();
}

I expected to see this happen: cargo clippy --fix converts it to fn xsave64(p: *mut u8, hi: u32, lo: u32);

Instead, this happened: --fix converts it to fn xsave64(p: *mut u8, hi: u32, lo: u32) ;

Meta

  • cargo clippy -V: clippy 0.0.212 (ffa2e7a 2020-10-24)
  • rustc -Vv:

rustc 1.49.0-nightly (ffa2e7ae8 2020-10-24) binary: rustc commit-hash: ffa2e7ae8fbf9badc035740db949b9dae271c29f commit-date: 2020-10-24 host: x86_64-unknown-linux-gnu release: 1.49.0-nightly LLVM version: 11.0

created time in 38 minutes

pull request commentrust-lang/cargo

Remove redundant "For example, "

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

sean-hut

comment created time in 38 minutes

PR opened rust-lang/cargo

Remove redundant "For example, "
+1 -1

0 comment

1 changed file

pr created time in 38 minutes

fork njasm/monitorbot

Monitoring of external API services Rust infrastructure relies upon

fork in 39 minutes

pull request commentrust-lang/rust

Fix `x.py clippy`

This is ready for review. Both the latest nightly and beta clippy work, and the error message no longer suggests installing nightly.

jyn514

comment created time in 40 minutes

push eventrust-lang/crates.io-index

bors

commit sha aded865b5883567575824b5add4de537bf67790d

Updating crate `cortex-m#0.6.4`

view details

push time in 42 minutes

push eventrust-lang/crates.io-index

bors

commit sha 95b27083d92c33a1eb5aa40342a4e34fa5b2910f

Updating crate `fastly-sys#0.3.6`

view details

push time in an hour

issue commentrust-lang/rust

Tracking issue for RFC 2033: Experimentally add coroutines to Rust

@tommythorn : Some of the confusion might be that while async/await use a trampoline, the coroutines/generators described by this issue are a lower level building block (for which there is no stable syntax: can see examples of the unstable API in https://github.com/rust-lang/rust/pull/68524/files?file-filters%5B%5D=.md&file-filters%5B%5D=.stderr) that work the way @Diggsey describes. The async/await transform consumes that low level building block to add a high level interface that is amenable to concurrent/multi-core schedulers.

aturon

comment created time in an hour

pull request commentrust-lang/rust

Move CloudABI to tier 3.

Given https://github.com/NuxiNL/cloudabi#note-this-project-is-unmaintained , I think it'd be OK to drop the target entirely at this point, unless someone sees a good reason to keep it.

ehuss

comment created time in an hour

pull request commentrust-lang/rust

Compile rustc crates with the initial-exec TLS model

@bjorn3 Does the cranelift backend need to be openable via dlopen? In general, it seems like codegen backends should be able to use this, and it'd be important for them to be able to do so because they're a lot of code.

joshtriplett

comment created time in an hour

Pull request review commentrust-lang/rust

Duration::zero() -> Duration::ZERO

 fn duration_const() {     const SUB_SEC_NANOS: u32 = DURATION.subsec_nanos();     assert_eq!(SUB_SEC_NANOS, 123_456_789); -    const ZERO: Duration = Duration::zero();-    assert_eq!(ZERO, Duration::new(0, 0));--    const IS_ZERO: bool = ZERO.is_zero();+    const IS_ZERO: bool = Duration::ZERO.is_zero();     assert!(IS_ZERO); -    const ONE: Duration = Duration::new(1, 0);--    const SECONDS: u64 = ONE.as_secs();+    const SECONDS: u64 = Duration::SECOND.as_secs();     assert_eq!(SECONDS, 1);      const FROM_SECONDS: Duration = Duration::from_secs(1);-    assert_eq!(FROM_SECONDS, ONE);+    assert_eq!(FROM_SECONDS, Duration::SECOND); -    const SECONDS_F32: f32 = ONE.as_secs_f32();+    const SECONDS_F32: f32 = Duration::SECOND.as_secs_f32();     assert_eq!(SECONDS_F32, 1.0);      const FROM_SECONDS_F32: Duration = Duration::from_secs_f32(1.0);-    assert_eq!(FROM_SECONDS_F32, ONE);+    assert_eq!(FROM_SECONDS_F32, Duration::SECOND); -    const SECONDS_F64: f64 = ONE.as_secs_f64();+    const SECONDS_F64: f64 = Duration::SECOND.as_secs_f64();     assert_eq!(SECONDS_F64, 1.0);      const FROM_SECONDS_F64: Duration = Duration::from_secs_f64(1.0);-    assert_eq!(FROM_SECONDS_F64, ONE);+    assert_eq!(FROM_SECONDS_F64, Duration::SECOND); -    const MILLIS: u128 = ONE.as_millis();+    const MILLIS: u128 = Duration::SECOND.as_millis();     assert_eq!(MILLIS, 1_000);      const FROM_MILLIS: Duration = Duration::from_millis(1_000);-    assert_eq!(FROM_MILLIS, ONE);+    assert_eq!(FROM_MILLIS, Duration::SECOND); -    const MICROS: u128 = ONE.as_micros();+    const MICROS: u128 = Duration::SECOND.as_micros();     assert_eq!(MICROS, 1_000_000);      const FROM_MICROS: Duration = Duration::from_micros(1_000_000);-    assert_eq!(FROM_MICROS, ONE);+    assert_eq!(FROM_MICROS, Duration::SECOND); -    const NANOS: u128 = ONE.as_nanos();+    const NANOS: u128 = Duration::SECOND.as_nanos();     assert_eq!(NANOS, 1_000_000_000);      const FROM_NANOS: Duration = Duration::from_nanos(1_000_000_000);-    assert_eq!(FROM_NANOS, ONE);+    assert_eq!(FROM_NANOS, Duration::SECOND);      const MAX: Duration = Duration::new(u64::MAX, 999_999_999); -    const CHECKED_ADD: Option<Duration> = MAX.checked_add(ONE);+    const CHECKED_ADD: Option<Duration> = MAX.checked_add(Duration::SECOND);     assert_eq!(CHECKED_ADD, None); -    const CHECKED_SUB: Option<Duration> = ZERO.checked_sub(ONE);+    const CHECKED_SUB: Option<Duration> = (Duration::ZERO).checked_sub(Duration::SECOND);     assert_eq!(CHECKED_SUB, None); -    const CHECKED_MUL: Option<Duration> = ONE.checked_mul(1);-    assert_eq!(CHECKED_MUL, Some(ONE));+    const CHECKED_MUL: Option<Duration> = Duration::SECOND.checked_mul(1);+    assert_eq!(CHECKED_MUL, Some(Duration::SECOND)); -    const MUL_F32: Duration = ONE.mul_f32(1.0);-    assert_eq!(MUL_F32, ONE);+    const MUL_F32: Duration = Duration::SECOND.mul_f32(1.0);+    assert_eq!(MUL_F32, Duration::SECOND); -    const MUL_F64: Duration = ONE.mul_f64(1.0);-    assert_eq!(MUL_F64, ONE);+    const MUL_F64: Duration = Duration::SECOND.mul_f64(1.0);+    assert_eq!(MUL_F64, Duration::SECOND); -    const CHECKED_DIV: Option<Duration> = ONE.checked_div(1);-    assert_eq!(CHECKED_DIV, Some(ONE));+    const CHECKED_DIV: Option<Duration> = Duration::SECOND.checked_div(1);+    assert_eq!(CHECKED_DIV, Some(Duration::SECOND)); -    const DIV_F32: Duration = ONE.div_f32(1.0);-    assert_eq!(DIV_F32, ONE);+    const DIV_F32: Duration = Duration::SECOND.div_f32(1.0);+    assert_eq!(DIV_F32, Duration::SECOND); -    const DIV_F64: Duration = ONE.div_f64(1.0);-    assert_eq!(DIV_F64, ONE);+    const DIV_F64: Duration = Duration::SECOND.div_f64(1.0);+    assert_eq!(DIV_F64, Duration::SECOND); -    const DIV_DURATION_F32: f32 = ONE.div_duration_f32(ONE);+    const DIV_DURATION_F32: f32 = Duration::SECOND.div_duration_f32(Duration::SECOND);     assert_eq!(DIV_DURATION_F32, 1.0); -    const DIV_DURATION_F64: f64 = ONE.div_duration_f64(ONE);+    const DIV_DURATION_F64: f64 = Duration::SECOND.div_duration_f64(Duration::SECOND);     assert_eq!(DIV_DURATION_F64, 1.0); -    const SATURATING_ADD: Duration = MAX.saturating_add(ONE);+    const SATURATING_ADD: Duration = MAX.saturating_add(Duration::SECOND);     assert_eq!(SATURATING_ADD, MAX); -    const SATURATING_SUB: Duration = ZERO.saturating_sub(ONE);-    assert_eq!(SATURATING_SUB, ZERO);+    const SATURATING_SUB: Duration = (Duration::ZERO).saturating_sub(Duration::SECOND);

Same as above: parenthesis?

workingjubilee

comment created time in an hour

Pull request review commentrust-lang/rust

Duration::zero() -> Duration::ZERO

 fn sub() {  #[test] fn checked_sub() {-    let zero = Duration::new(0, 0);-    let one_nano = Duration::new(0, 1);-    let one_sec = Duration::new(1, 0);-    assert_eq!(one_nano.checked_sub(zero), Some(Duration::new(0, 1)));-    assert_eq!(one_sec.checked_sub(one_nano), Some(Duration::new(0, 999_999_999)));-    assert_eq!(zero.checked_sub(one_nano), None);-    assert_eq!(zero.checked_sub(one_sec), None);+    assert_eq!(Duration::NANOSECOND.checked_sub(Duration::ZERO), Some(Duration::NANOSECOND));+    assert_eq!(+        Duration::SECOND.checked_sub(Duration::NANOSECOND),+        Some(Duration::new(0, 999_999_999))+    );+    assert_eq!(Duration::ZERO.checked_sub(Duration::NANOSECOND), None);+    assert_eq!(Duration::ZERO.checked_sub(Duration::SECOND), None); }  #[test] fn saturating_sub() {-    let zero = Duration::new(0, 0);-    let one_nano = Duration::new(0, 1);-    let one_sec = Duration::new(1, 0);-    assert_eq!(one_nano.saturating_sub(zero), Duration::new(0, 1));-    assert_eq!(one_sec.saturating_sub(one_nano), Duration::new(0, 999_999_999));-    assert_eq!(zero.saturating_sub(one_nano), Duration::MIN);-    assert_eq!(zero.saturating_sub(one_sec), Duration::MIN);+    assert_eq!(Duration::NANOSECOND.saturating_sub(Duration::ZERO), Duration::NANOSECOND);+    assert_eq!(+        Duration::SECOND.saturating_sub(Duration::NANOSECOND),+        Duration::new(0, 999_999_999)+    );+    assert_eq!(Duration::ZERO.saturating_sub(Duration::NANOSECOND), Duration::MIN);+    assert_eq!(Duration::ZERO.saturating_sub(Duration::SECOND), Duration::MIN);
    assert_eq!(Duration::ZERO.saturating_sub(Duration::NANOSECOND), Duration::ZERO);
    assert_eq!(Duration::ZERO.saturating_sub(Duration::SECOND), Duration::ZERO);

The MIN constant is not stable either and it might be replaced by this ZERO constant.

workingjubilee

comment created time in an hour

Pull request review commentrust-lang/rust

Duration::zero() -> Duration::ZERO

 fn duration_const() {     const SUB_SEC_NANOS: u32 = DURATION.subsec_nanos();     assert_eq!(SUB_SEC_NANOS, 123_456_789); -    const ZERO: Duration = Duration::zero();-    assert_eq!(ZERO, Duration::new(0, 0));--    const IS_ZERO: bool = ZERO.is_zero();+    const IS_ZERO: bool = Duration::ZERO.is_zero();     assert!(IS_ZERO); -    const ONE: Duration = Duration::new(1, 0);--    const SECONDS: u64 = ONE.as_secs();+    const SECONDS: u64 = Duration::SECOND.as_secs();     assert_eq!(SECONDS, 1);      const FROM_SECONDS: Duration = Duration::from_secs(1);-    assert_eq!(FROM_SECONDS, ONE);+    assert_eq!(FROM_SECONDS, Duration::SECOND); -    const SECONDS_F32: f32 = ONE.as_secs_f32();+    const SECONDS_F32: f32 = Duration::SECOND.as_secs_f32();     assert_eq!(SECONDS_F32, 1.0);      const FROM_SECONDS_F32: Duration = Duration::from_secs_f32(1.0);-    assert_eq!(FROM_SECONDS_F32, ONE);+    assert_eq!(FROM_SECONDS_F32, Duration::SECOND); -    const SECONDS_F64: f64 = ONE.as_secs_f64();+    const SECONDS_F64: f64 = Duration::SECOND.as_secs_f64();     assert_eq!(SECONDS_F64, 1.0);      const FROM_SECONDS_F64: Duration = Duration::from_secs_f64(1.0);-    assert_eq!(FROM_SECONDS_F64, ONE);+    assert_eq!(FROM_SECONDS_F64, Duration::SECOND); -    const MILLIS: u128 = ONE.as_millis();+    const MILLIS: u128 = Duration::SECOND.as_millis();     assert_eq!(MILLIS, 1_000);      const FROM_MILLIS: Duration = Duration::from_millis(1_000);-    assert_eq!(FROM_MILLIS, ONE);+    assert_eq!(FROM_MILLIS, Duration::SECOND); -    const MICROS: u128 = ONE.as_micros();+    const MICROS: u128 = Duration::SECOND.as_micros();     assert_eq!(MICROS, 1_000_000);      const FROM_MICROS: Duration = Duration::from_micros(1_000_000);-    assert_eq!(FROM_MICROS, ONE);+    assert_eq!(FROM_MICROS, Duration::SECOND); -    const NANOS: u128 = ONE.as_nanos();+    const NANOS: u128 = Duration::SECOND.as_nanos();     assert_eq!(NANOS, 1_000_000_000);      const FROM_NANOS: Duration = Duration::from_nanos(1_000_000_000);-    assert_eq!(FROM_NANOS, ONE);+    assert_eq!(FROM_NANOS, Duration::SECOND);      const MAX: Duration = Duration::new(u64::MAX, 999_999_999); -    const CHECKED_ADD: Option<Duration> = MAX.checked_add(ONE);+    const CHECKED_ADD: Option<Duration> = MAX.checked_add(Duration::SECOND);     assert_eq!(CHECKED_ADD, None); -    const CHECKED_SUB: Option<Duration> = ZERO.checked_sub(ONE);+    const CHECKED_SUB: Option<Duration> = (Duration::ZERO).checked_sub(Duration::SECOND);

Why are the parenthesis required here?

workingjubilee

comment created time in an hour

PullRequestReviewEvent
PullRequestReviewEvent

fork sean-hut/cargo

The Rust package manager

https://doc.rust-lang.org/cargo

fork in an hour

more