profile
viewpoint

crossbeam-rs/crossbeam 3371

Tools for concurrent programming in Rust

smol-rs/smol 1956

A small and fast async runtime for Rust

smol-rs/blocking 220

A thread pool for isolating blocking I/O in async programs

smol-rs/async-channel 216

Async multi-producer multi-consumer channel

smol-rs/polling 159

Portable interface to epoll, kqueue, event ports, and wepoll

smol-rs/event-listener 152

Notify async tasks or threads

smol-rs/futures-lite 133

Futures, streams, and async I/O combinators.

smol-rs/async-task 130

Task abstraction for building executors

smol-rs/async-io 125

Async I/O and timers

smol-rs/fastrand 118

A simple and fast random number generator

pull request commentrust-lang/rust

Remove doctree::Import

Rebased to fix conflicts

CraftSpider

comment created time in a minute

pull request commentrust-lang/rust

Add size hint for byte iterator over file

For a BufReader (it doesn't have to be a File) it could at least provide a lower bound that represents the currently buffered data. This would be a very rough estimate, but still a bit better than the current implementation. But I'm not sure whether that's worth it.

I agree that this is much better. Should I change the implementation here or open a new PR with the change (since it is different)?

Xavientois

comment created time in a minute

issue commentrust-lang/rust

Tracking Issue for slice::fill_with

Stabilization PR filed: https://github.com/rust-lang/rust/pull/81048

yoshuawuyts

comment created time in 2 minutes

PR opened rust-lang/rust

Stabilize `core::slice::fill_with`

Tracking issue: https://github.com/rust-lang/rust/issues/79221

This stabilizes the slice_fill_with feature 1.51, following the stabilization of slice_fill in 1.50. This was requested by libs team members in https://github.com/rust-lang/rust/pull/79213.

This PR also adds the "memset" alias for slice::fill_with, mirroring the alias set on the slice::fill sibling API. This will ensure someone looking for "memset" will find both variants.

r? @Amanieu

+2 -3

0 comment

1 changed file

pr created time in 3 minutes

pull request commentrust-lang/rust

Add size hint for byte iterator over file

For a BufReader<T> (it doesn't have to be a File) it could at least provide a lower bound that represents the currently buffered data. This would be a very rough estimate, but still a bit better than the current implementation. But I'm not sure whether that's worth it.

This one sounds potentially interesting. It'd at least help the first reallocation of a vector when collecting, and should be pretty cheap.

Xavientois

comment created time in 4 minutes

Pull request review commenttokio-rs/tokio

docs: Clarified the point about changing the file descriptor underlyi…

 use std::{task::Context, task::Poll}; /// /// The inner object is required to implement [`AsRawFd`]. This file descriptor /// must not change while [`AsyncFd`] owns the inner object. Changing the file-/// descriptor results in unspecified behavior in the IO driver, which may-/// include breaking notifications for other sockets/etc.+/// descriptor through the underlying [`AsRawFd::as_raw_fd`] results+/// in unspecified behavior in the IO driver, which may include breaking+/// notifications for other sockets/etc. That is not to say that simply using+/// a clone of the inner object would be problematic if that is a supported+/// thing to do.

It's a statement about the implementer of AsRawFd - if that does something strange, then you have a problem? I'm not sure of the right way of phrasing "done by but not done right here" which was the intention of "through the". How about "Changing the file descriptor through an unexpected implementation of AsRawFd..."?

Perhaps you could clarify the difference between unspecified behaviour and undefined behaviour...?

hgomersall

comment created time in 6 minutes

issue openedtaiki-e/futures-async-stream

Comparison to other async stream crates

How does this compare to https://crates.io/crates/async-stream.

created time in 7 minutes

Pull request review commentrust-lang/rust

Add size hint for byte iterator over file

 impl<R: Read> Iterator for Bytes<R> {             };         }     }++    default fn size_hint(&self) -> (usize, Option<usize>) {+        (0, None)+    }+}++#[unstable]+impl Iterator for Bytes<fs::File> {+    fn size_hint(&self) -> (usize, Option<usize>) {+        match self.inner.metadata() {+            Ok(metadata) => {+                let file_length = metadata.len() as usize;+                (0, Some(file_length))

This implementation will never actually help, because in practice only the .0 of the size_hint() is ever used: https://internals.rust-lang.org/t/is-size-hint-1-ever-used/8187?u=scottmcm

Xavientois

comment created time in 8 minutes

pull request commentrust-lang/rust

Improve unknown external crate error

The job x86_64-gnu-llvm-9 failed! Check out the build log: (web) (plain)

<details><summary><i>Click to see the possible cause of the failure (guessed by this bot)</i></summary>


---- [ui] ui/issues/issue-71406.rs stdout ----
diff of stderr:

- error[E0433]: failed to resolve: expected type, found function `channel` in `mpsc`
+ error[E0433]: failed to resolve: expected type, found function `channel` in ``mpsc``
3    |
3    |
4 LL |     let (tx, rx) = mpsc::channel::new(1);

-    |                          ^^^^^^^ expected type, found function `channel` in `mpsc`
+    |                          ^^^^^^^ expected type, found function `channel` in ``mpsc``
7 error: aborting due to previous error
8 



The actual stderr differed from the expected stderr.
Actual stderr saved to /checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/issues/issue-71406/issue-71406.stderr
To update references, rerun the tests and pass the `--bless` flag
To only update this specific test, also pass `--test-args issues/issue-71406.rs`
error: 1 errors occurred comparing output.
status: exit code: 1
status: exit code: 1
command: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/src/test/ui/issues/issue-71406.rs" "-Zthreads=1" "--target=x86_64-unknown-linux-gnu" "--error-format" "json" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "-Zemit-future-incompat-report" "--emit" "metadata" "-C" "prefer-dynamic" "--out-dir" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/issues/issue-71406" "-A" "unused" "-Crpath" "-O" "-Cdebuginfo=0" "-Zunstable-options" "-Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/issues/issue-71406/auxiliary"
------------------------------------------

------------------------------------------
stderr:
stderr:
------------------------------------------
error[E0433]: failed to resolve: expected type, found function `channel` in ``mpsc``
   |
   |
LL |     let (tx, rx) = mpsc::channel::new(1);
   |                          ^^^^^^^ expected type, found function `channel` in ``mpsc``
error: aborting due to previous error

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

---

Some tests failed in compiletest suite=ui mode=ui host=x86_64-unknown-linux-gnu target=x86_64-unknown-linux-gnu


command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/compiletest" "--compile-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib" "--run-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib" "--rustc-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "--src-base" "/checkout/src/test/ui" "--build-base" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui" "--stage-id" "stage2-x86_64-unknown-linux-gnu" "--suite" "ui" "--mode" "ui" "--target" "x86_64-unknown-linux-gnu" "--host" "x86_64-unknown-linux-gnu" "--llvm-filecheck" "/usr/lib/llvm-9/bin/FileCheck" "--nodejs" "/usr/bin/node" "--host-rustcflags" "-Crpath -O -Cdebuginfo=0 -Zunstable-options  -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--target-rustcflags" "-Crpath -O -Cdebuginfo=0 -Zunstable-options  -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--docck-python" "/usr/bin/python3" "--lldb-python" "/usr/bin/python3" "--gdb" "/usr/bin/gdb" "--quiet" "--llvm-version" "9.0.0" "--llvm-components" "aarch64 aarch64asmparser aarch64codegen aarch64desc aarch64disassembler aarch64info aarch64utils aggressiveinstcombine all all-targets amdgpu amdgpuasmparser amdgpucodegen amdgpudesc amdgpudisassembler amdgpuinfo amdgpuutils analysis arm armasmparser armcodegen armdesc armdisassembler arminfo armutils asmparser asmprinter avr avrasmparser avrcodegen avrdesc avrdisassembler avrinfo binaryformat bitreader bitstreamreader bitwriter bpf bpfasmparser bpfcodegen bpfdesc bpfdisassembler bpfinfo codegen core coroutines coverage debuginfocodeview debuginfodwarf debuginfogsym debuginfomsf debuginfopdb demangle dlltooldriver engine executionengine fuzzmutate globalisel hexagon hexagonasmparser hexagoncodegen hexagondesc hexagondisassembler hexagoninfo instcombine instrumentation interpreter ipo irreader jitlink lanai lanaiasmparser lanaicodegen lanaidesc lanaidisassembler lanaiinfo libdriver lineeditor linker lto mc mca mcdisassembler mcjit mcparser mips mipsasmparser mipscodegen mipsdesc mipsdisassembler mipsinfo mirparser msp430 msp430asmparser msp430codegen msp430desc msp430disassembler msp430info native nativecodegen nvptx nvptxcodegen nvptxdesc nvptxinfo objcarcopts object objectyaml option orcjit passes perfjitevents powerpc powerpcasmparser powerpccodegen powerpcdesc powerpcdisassembler powerpcinfo profiledata remarks riscv riscvasmparser riscvcodegen riscvdesc riscvdisassembler riscvinfo riscvutils runtimedyld scalaropts selectiondag sparc sparcasmparser sparccodegen sparcdesc sparcdisassembler sparcinfo support symbolize systemz systemzasmparser systemzcodegen systemzdesc systemzdisassembler systemzinfo tablegen target textapi transformutils vectorize webassembly webassemblyasmparser webassemblycodegen webassemblydesc webassemblydisassembler webassemblyinfo windowsmanifest x86 x86asmparser x86codegen x86desc x86disassembler x86info x86utils xcore xcorecodegen xcoredesc xcoredisassembler xcoreinfo xray" "--system-llvm" "--cc" "" "--cxx" "" "--cflags" "" "--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" "--android-cross-path" "" "--color" "always"


failed to run: /checkout/obj/build/bootstrap/debug/bootstrap --stage 2 test --exclude src/tools/tidy
Build completed unsuccessfully in 0:17:48

</details>

rylev

comment created time in 12 minutes

pull request commentrust-lang/rust

Add test for #59352

@oli-obk I'm not exactly sure this is what you had in mind, but I added a mir-opt test that will actually fail when the panic gets optimized away. I kept the mir-opt-level=2 in that test so that the test output directly shows the panic.

bugadani

comment created time in 13 minutes

pull request commentrust-lang/rust

Turn deprecation lint `pub_use_of_private_extern_crate` into a hard error

:construction: Experiment pr-80763 is now running

:information_source: Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

petrochenkov

comment created time in 13 minutes

pull request commentrust-lang/rust

Stabilize cmp_min_max_by

The job mingw-check failed! Check out the build log: (web) (plain)

<details><summary><i>Click to see the possible cause of the failure (guessed by this bot)</i></summary>

configure: rust.channel         := nightly
configure: rust.debug-assertions := True
configure: llvm.assertions      := True
configure: dist.missing-tools   := True
configure: build.configure-args := ['--enable-sccache', '--disable-manage-submodu ...
configure: writing `config.toml` in current directory
configure: 
configure: run `python /checkout/x.py --help`
configure: 
---
    Checking rand v0.7.3
    Checking std v0.0.0 (/checkout/library/std)
    Checking alloc v0.0.0 (/checkout/library/alloc)
    Checking core v0.0.0 (/checkout/library/core)
error: the feature `cmp_min_max_by` has been stable since 1.50.0 and no longer requires an attribute to enable
   |
   |
59 | #![feature(cmp_min_max_by)]
   |
   |
   = note: `-D stable-features` implied by `-D warnings`
error: aborting due to previous error

error: could not compile `core`


To learn more, run the command again with --verbose.
command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "check" "--target" "i686-pc-windows-gnu" "-Zbinary-dep-depinfo" "-j" "16" "--release" "--locked" "--color" "always" "--features" "panic-unwind backtrace compiler-builtins-c" "--manifest-path" "/checkout/library/test/Cargo.toml" "--all-targets" "-p" "test" "-p" "proc_macro" "-p" "panic_unwind" "-p" "alloc" "-p" "unwind" "-p" "std" "-p" "panic_abort" "-p" "term" "-p" "core" "--message-format" "json-render-diagnostics"
failed to run: /checkout/obj/build/bootstrap/debug/bootstrap check --target=i686-pc-windows-gnu --host=i686-pc-windows-gnu --all-targets
Build completed unsuccessfully in 0:00:48

</details>

glittershark

comment created time in 19 minutes

Pull request review commenttokio-rs/tokio

docs: Clarified the point about changing the file descriptor underlyi…

 use std::{task::Context, task::Poll}; /// /// The inner object is required to implement [`AsRawFd`]. This file descriptor /// must not change while [`AsyncFd`] owns the inner object. Changing the file-/// descriptor results in unspecified behavior in the IO driver, which may-/// include breaking notifications for other sockets/etc.+/// descriptor through the underlying [`AsRawFd::as_raw_fd`] results+/// in unspecified behavior in the IO driver, which may include breaking+/// notifications for other sockets/etc. That is not to say that simply using+/// a clone of the inner object would be problematic if that is a supported+/// thing to do.

To clarify, the problem happens when as_raw_fd returns different values when called multiple times, but you don't make it return different values through as_raw_fd — it doesn't provide mutable access to the fd.

hgomersall

comment created time in 20 minutes

pull request commentrust-lang/rust

Stabilize remaining integer methods as `const fn`

Looking at the page source, the bot replied at 2021-01-15T15:56:05Z. You commented at 2021-01-15T15:56:26Z. So it supposedly replied 21 seconds before you commented. I presume this is a server whose clock drifted a bit.

jhpratt

comment created time in 20 minutes

Pull request review commenttokio-rs/tokio

docs: Clarified the point about changing the file descriptor underlyi…

 use std::{task::Context, task::Poll}; /// /// The inner object is required to implement [`AsRawFd`]. This file descriptor /// must not change while [`AsyncFd`] owns the inner object. Changing the file-/// descriptor results in unspecified behavior in the IO driver, which may-/// include breaking notifications for other sockets/etc.+/// descriptor through the underlying [`AsRawFd::as_raw_fd`] results+/// in unspecified behavior in the IO driver, which may include breaking+/// notifications for other sockets/etc. That is not to say that simply using+/// a clone of the inner object would be problematic if that is a supported+/// thing to do.

I mean, the AsyncFd access the fd through as_raw_fd, but you don't change it using as_raw_fd. And the kinds of trouble are unspecified behavior, not undefined behavior. The second point was referring to "which may include breaking notifications for other sockets/etc."

hgomersall

comment created time in 24 minutes

issue commentrust-lang/rust

Windows PathBuf/Path

This is a fairly well known problem where canonicalize returns a \\?\ device path which does not support relative paths or normalization. See #59117 and #42869 and all the linked issues.

pderouen

comment created time in 28 minutes

Pull request review commenttokio-rs/tokio

docs: Clarified the point about changing the file descriptor underlyi…

 use std::{task::Context, task::Poll}; /// /// The inner object is required to implement [`AsRawFd`]. This file descriptor /// must not change while [`AsyncFd`] owns the inner object. Changing the file-/// descriptor results in unspecified behavior in the IO driver, which may-/// include breaking notifications for other sockets/etc.+/// descriptor through the underlying [`AsRawFd::as_raw_fd`] results+/// in unspecified behavior in the IO driver, which may include breaking+/// notifications for other sockets/etc. That is not to say that simply using+/// a clone of the inner object would be problematic if that is a supported+/// thing to do.

To clarify the first point, if the raw file fd wasn't exposed, would there be a problem?

hgomersall

comment created time in 29 minutes

pull request commentrust-lang/rust

Stabilize cmp_min_max_by

The job mingw-check failed! Check out the build log: (web) (plain)

<details><summary><i>Click to see the possible cause of the failure (guessed by this bot)</i></summary>

    Checking rustc_middle v0.0.0 (/checkout/compiler/rustc_middle)
    Checking rustc_ast_passes v0.0.0 (/checkout/compiler/rustc_ast_passes)
    Checking rustc_expand v0.0.0 (/checkout/compiler/rustc_expand)
    Checking rustc_builtin_macros v0.0.0 (/checkout/compiler/rustc_builtin_macros)
error: the feature `cmp_min_max_by` has been stable since 1.50.0 and no longer requires an attribute to enable
   |
   |
32 | #![feature(cmp_min_max_by)]
   |
   |
   = note: `-D stable-features` implied by `-D warnings`
error: aborting due to previous error

error: could not compile `rustc_middle`


To learn more, run the command again with --verbose.
command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "check" "--target" "x86_64-unknown-linux-gnu" "-Zbinary-dep-depinfo" "-j" "16" "--release" "--color" "always" "--features" " llvm max_level_info" "--manifest-path" "/checkout/compiler/rustc/Cargo.toml" "-p" "rustc-main" "-p" "rustc_codegen_ssa" "-p" "rustc_session" "-p" "rustc_lint_defs" "-p" "rustc_feature" "-p" "rustc_symbol_mangling" "-p" "rustc_index" "-p" "rustc_incremental" "-p" "rustc_graphviz" "-p" "rustc_hir" "-p" "rustc_ast" "-p" "rustc_lexer" "-p" "rustc_data_structures" "-p" "rustc_errors" "-p" "rustc_target" "-p" "rustc_serialize" "-p" "rustc_middle" "-p" "rustc_query_system" "-p" "rustc_arena" "-p" "rustc_type_ir" "-p" "rustc_macros" "-p" "rustc_fs_util" "-p" "rustc_apfloat" "-p" "rustc_attr" "-p" "rustc_ast_pretty" "-p" "rustc_span" "-p" "rustc_driver" "-p" "rustc_interface" "-p" "rustc_trait_selection" "-p" "rustc_infer" "-p" "rustc_parse_format" "-p" "rustc_typeck" "-p" "rustc_privacy" "-p" "rustc_mir_build" "-p" "rustc_resolve" "-p" "rustc_ast_passes" "-p" "rustc_codegen_llvm" "-p" "rustc_llvm" "-p" "rustc_ast_lowering" "-p" "rustc_builtin_macros" "-p" "rustc_ty_utils" "-p" "rustc_expand" "-p" "rustc_passes" "-p" "rustc_traits" "-p" "rustc_plugin_impl" "-p" "rustc_save_analysis" "-p" "rustc_metadata" "-p" "rustc_lint" "-p" "rustc_mir" "-p" "coverage_test_macros" "-p" "rustc_error_codes" "-p" "rustc_parse" "-p" "rustc_hir_pretty" "--message-format" "json-render-diagnostics"
failed to run: /checkout/obj/build/bootstrap/debug/bootstrap check
Build completed unsuccessfully in 0:02:33

</details>

glittershark

comment created time in 30 minutes

Pull request review commenttokio-rs/tokio

docs: Clarified the point about changing the file descriptor underlyi…

 use std::{task::Context, task::Poll}; /// /// The inner object is required to implement [`AsRawFd`]. This file descriptor /// must not change while [`AsyncFd`] owns the inner object. Changing the file-/// descriptor results in unspecified behavior in the IO driver, which may-/// include breaking notifications for other sockets/etc.+/// descriptor through the underlying [`AsRawFd::as_raw_fd`] results+/// in unspecified behavior in the IO driver, which may include breaking+/// notifications for other sockets/etc. That is not to say that simply using+/// a clone of the inner object would be problematic if that is a supported+/// thing to do.

Isn't the point that as_raw_fs exposes the actual raw file descriptor?

If clones of File might cause UB, then we have a problem (and probably new should be unsafe).

Notwithstanding the huge number of ways in which things can break, there is a definitely a need to provide more guidance around common use cases.

hgomersall

comment created time in 30 minutes

pull request commentrust-lang/rust

Stabilize cmp_min_max_by

this is my first time doing a stabilization PR, so lmk if I did anything wrong here! https://github.com/rust-lang/rust/issues/64460#issuecomment-719493088 seemed to indicate this was the proper next step.

glittershark

comment created time in 33 minutes

issue commentrust-lang/rust

Tracking issue for `cmp::{min_by, min_by_key, max_by, max_by_key}`

Stabilization PR up at #81047

timvermeulen

comment created time in 33 minutes

pull request commentrust-lang/rust

Stabilize cmp_min_max_by

r? @shepmaster

(rust-highfive has picked a reviewer for you, use r? to override)

glittershark

comment created time in 34 minutes

PR opened rust-lang/rust

Stabilize cmp_min_max_by

I would like to propose cmp::{min_by, min_by_key, max_by, max_by_key} for stabilization.

These are relatively simple and seemingly uncontroversial functions and have been unchanged in unstable for a while now.

Closes: #64460

+4 -12

0 comment

1 changed file

pr created time in 34 minutes

Pull request review commenttokio-rs/tokio

docs: Clarified the point about changing the file descriptor underlyi…

 use std::{task::Context, task::Poll}; /// /// The inner object is required to implement [`AsRawFd`]. This file descriptor /// must not change while [`AsyncFd`] owns the inner object. Changing the file-/// descriptor results in unspecified behavior in the IO driver, which may-/// include breaking notifications for other sockets/etc.+/// descriptor through the underlying [`AsRawFd::as_raw_fd`] results+/// in unspecified behavior in the IO driver, which may include breaking+/// notifications for other sockets/etc. That is not to say that simply using+/// a clone of the inner object would be problematic if that is a supported+/// thing to do.

I don't really like this wording. Some notes:

  • The fd is not changed through as_raw_fd.
  • I'm not sure we have to expand on the kinds of ways it may break.
  • I don't want to make promises around clones of the fd. Those can easily get you in trouble too.
hgomersall

comment created time in 34 minutes

pull request commentrust-lang/rust

Generate metadata by iterating on DefId instead of traversing the HIR tree 1/N

what changed compared to the state that the last perf run showed?

cjgillot

comment created time in 36 minutes

pull request commentrust-lang/rust

Improve unknown external crate error

The job mingw-check failed! Check out the build log: (web) (plain)

<details><summary><i>Click to see the possible cause of the failure (guessed by this bot)</i></summary>

configure: rust.channel         := nightly
configure: rust.debug-assertions := True
configure: llvm.assertions      := True
configure: dist.missing-tools   := True
configure: build.configure-args := ['--enable-sccache', '--disable-manage-submodu ...
configure: writing `config.toml` in current directory
configure: 
configure: run `python /checkout/x.py --help`
configure: 
---
skip untracked path src/llvm-project/ during rustfmt invocations
Diff in /checkout/compiler/rustc_resolve/src/lib.rs at line 2459:
                         }
                     } else {
                         let parent = path[i - 1].ident.name;
-                        let parent =
-                            if parent == kw::PathRoot { "crate root".to_owned() } else { format!("`{}`", parent) };
+                        let parent = if parent == kw::PathRoot {
+                            "crate root".to_owned()
+                        } else {
+                            format!("`{}`", parent)
 
 
                         let mut msg = format!("could not find `{}` in {}", ident, parent);
Running `"/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/rustfmt" "--config-path" "/checkout" "--edition" "2018" "--unstable-features" "--skip-children" "--check" "/checkout/compiler/rustc_resolve/src/lib.rs"` failed.
If you're running `tidy`, try again with `--bless`. Or, if you just want to format code, run `./x.py fmt` instead.
                         if ns == TypeNS || ns == ValueNS {
Build completed unsuccessfully in 0:00:15

</details>

rylev

comment created time in 38 minutes

PR opened tokio-rs/tracing

chore: fix deprecation and clippy warnings

This branch fixes two known warnings.

The first fixed warning was in tracing-core/src/callsite.rs, where clippy suggested using std::ptr::eq to compare addresses instead of casting &T to a *const T, which &T coerces to anyways. Below is the warning:

error: use `std::ptr::eq` when comparing raw pointers
   --> tracing-core/src/callsite.rs:238:9
    |
238 |         self.0 as *const _ as *const () == other.0 as *const _ as *const ()
    |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: try: `std::ptr::eq(self.0 as *const _, other.0 as *const _)`
    |
    = note: `-D clippy::ptr-eq` implied by `-D warnings`
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#ptr_eq

The second fixed warning is a bit more complex. As of Rust 1.50, AtomicUsize::compare_and_swap has been deprecated in favor of AtomicUsize::compare_exchange and AtomicUsize::compare_exchange_weak. I've moved tracing_core::dispatch::set_global_default to use AtomicUsize::compare_exchange as AtomicUsize::compare_exchange_weak is designed for atomic loads in loops. Here are a few notes on the differences between AtomicUsize::compare_and_swap and AtomicUsize::compare_exchange:

  • AtomicUsize::compare_exchange returns a result, where the Result::Ok(_) branch contains the prior value. This is equivalent to the now-deprecated AtomicUsize::compare_and_swap returning the current parameter upon a successful compare-and-swap operation, but success is now established through a Result, not an equality operation.
  • AtomicUsize::compare_exchange accepts an Ordering for the failure case of a compare-and-swap. The migration guide suggests using Ordering::SeqCst for both the success and failure cases and I saw no reason to depart from its guidance.

After this branch is approved, I'll backport these fixes to the v0.1.0 branch.

+9 -3

0 comment

2 changed files

pr created time in an hour

PR opened rust-lang/rust

Improve unknown external crate error

This improves error messages when unknown items in the crate root are encountered.

Fixes #63799

r? @estebank

+17 -7

0 comment

5 changed files

pr created time in an hour

issue openedrust-lang/rust-clippy

Add XOR swap algorithm detection to (existing) clippy::manual_swap

What it does

This would warn the user that there is a better alternative to using a XOR swapping algorithm to swap the values of two variables

Categories (optional)

  • Kind: clippy::complexity

The std::mem::swap function exposes the intent better without deinitializing or copying either variable (this is the same reason for the warning for swapping using a temporary variable)

For example:

  • People reading the recommended code will see that it likely swaps two variables, as opposed to if they see a XOR swap algorithm and are unfamiliar with it.

Drawbacks

None.

Example

fn main() {
    let mut a = 5;
    let mut b = 10;
    
    // Swap them.
    a ^= b;
    b ^= a;
    a ^= b;
    
    println!("a: {}, b: {}", a, b);
}

Could be written as:

fn main() {
    let mut a = 5;
    let mut b = 10;
    
    // Swap them.
    std::mem::swap(&mut a, &mut b);
    
    println!("a: {}, b: {}", a, b);
}

created time in an hour

pull request commentrust-lang/rust

Generate metadata by iterating on DefId instead of traversing the HIR tree 1/N

@oli-obk This subset is ready for review. I will work on type_of and co in a follow-up PR.

cjgillot

comment created time in an hour

more