profile
viewpoint
David Tolnay dtolnay 0xF9BA143B95FF6D82 Menlo Park, CA

dtolnay/cxx 1968

Safe interop between Rust and C++

brson/stdx 1361

The missing batteries of Rust

dtolnay/anyhow 1325

Flexible concrete Error type built on std::error::Error

dtolnay/case-studies 846

Analysis of various tricky Rust code

dtolnay/cargo-expand 757

Subcommand to show result of macro expansion

dtolnay/async-trait 582

Type erasure for async trait methods

chyh1990/yaml-rust 400

A pure rust YAML implementation.

dtolnay/erased-serde 162

Type-erased Serialize, Serializer and Deserializer traits

dtolnay/cargo-llvm-lines 134

Count lines of LLVM IR per generic function

issue closeddtolnay/anyhow

The trait `wasm_bindgen::convert::IntoWasmAbi` is not implemented for `std::result::Result<(), anyhow::Error>`

error[E0277]: the trait bound `std::result::Result<(), anyhow::Error>: wasm_bindgen::convert::IntoWasmAbi` is not satisfied
   --> src/lib.rs:183:1
    |
183 | #[wasm_bindgen]
    | ^^^^^^^^^^^^^^^ the trait `wasm_bindgen::convert::IntoWasmAbi` is not implemented for `std::result::Result<(), anyhow::Error>`
    |
    = note: required because of the requirements on the impl of `wasm_bindgen::convert::ReturnWasmAbi` for `std::result::Result<(), anyhow::Error>`
    = note: this error originates in an attribute macro (in Nightly builds, run with -Z macro-backtrace for more info)

error: aborting due to previous error; 1 warning emitted

For more information about this error, try `rustc --explain E0277`.
error: could not compile `wgpu-multiplatform`.

To learn more, run the command again with --verbose.
Error: Compiling your crate to WebAssembly failed
Caused by: failed to execute `cargo build`: exited with exit code: 101
  full command: "cargo" "build" "--lib" "--release" "--target" "wasm32-unknown-unknown"

<!-- ❤️ -->

closed time in 3 hours

sotrh

issue commentdtolnay/anyhow

The trait `wasm_bindgen::convert::IntoWasmAbi` is not implemented for `std::result::Result<(), anyhow::Error>`

This does not look like an issue with the anyhow crate.

sotrh

comment created time in 3 hours

issue openedrust-lang/docs.rs

Hyphenated standard library crate does not redirect

https://docs.rs/serde-json correctly redirects to the same location as https://docs.rs/serde_json but https://docs.rs/proc-macro does not redirect to the same location as https://docs.rs/proc_macro.

created time in 6 hours

push eventserde-rs/serde

David Tolnay

commit sha 8084258a3edc1dc4007e8df7f24b022d015b5fb0

Update ui tests to nightly-2020-10-20

view details

push time in 7 hours

PullRequestReviewEvent

push eventdtolnay/rust-team

David Tolnay

commit sha 053001a5134953415010618f3023ed6137f68a4e

Add library-reviewers team with rust-lang/rust review permission Member list is taken from https://github.com/rust-lang/highfive/blob/4420ccbffd38c700dbcfd3fb943f8b5ab53ee10d/highfive/configs/rust-lang/rust.json The current list in this commit all already have at least these permissions. - via libs team: dtolnay, KodrAus, LukasKalbertodt, sfackler, withoutboats - via lang team: cramertj, joshtriplett - via infra team: kennytm, Mark-Simulacrum, shepmaster However, I am hoping to add another standard library reviewer who is not already in one of the other teams with review permission.

view details

Santiago Pastorino

commit sha c24b7cf0e8903d4b41dc3d4ad6c4826977cd6526

Remove spastorino from cleanup crew

view details

Pietro Albini

commit sha a11c345f1d30de0c767677e663288a39504044f9

Merge pull request #455 from spastorino/remove-me-from-cleanup Remove spastorino from cleanup crew

view details

Mark Rousskov

commit sha 406b9c7b211314e599afbfcd56ea85f2360d1ece

Merge pull request #456 from dtolnay/library-reviewers Add library-reviewers team with rust-lang/rust review permission

view details

David Tolnay

commit sha dd3feb21edf5b24ba46a9ac860ab3c0258a44045

Add m-ou-se to library-reviewers

view details

Mark Rousskov

commit sha d5eb868c278f660603c72388da93d7613d38225d

Merge pull request #457 from dtolnay/m-ou-se Add m-ou-se to library-reviewers

view details

push time in 9 hours

startedrust-lang/team

started time in 9 hours

delete branch dtolnay/highfive

delete branch : m-ou-se

delete time in 9 hours

pull request commentrust-lang/team

Add m-ou-se to library-reviewers

https://github.com/rust-lang/highfive/pull/294

dtolnay

comment created time in 9 hours

delete branch dtolnay/rust-team

delete branch : m-ou-se

delete time in 9 hours

PR opened rust-lang/highfive

Add m-ou-se to libs review rotation

Follow-up to https://github.com/rust-lang/team/pull/457. @m-ou-se

+1 -1

0 comment

1 changed file

pr created time in 9 hours

create barnchdtolnay/highfive

branch : m-ou-se

created branch time in 9 hours

fork dtolnay/highfive

Github hooks to provide an encouraging atmosphere for new contributors

fork in 9 hours

PR opened rust-lang/team

Add m-ou-se to library-reviewers

@m-ou-se expressed interest in helping with standard library reviews, and has already been doing a ton of terrific work on the standard library. :)

+5 -0

0 comment

2 changed files

pr created time in 9 hours

push eventdtolnay/rust-team

David Tolnay

commit sha dd3feb21edf5b24ba46a9ac860ab3c0258a44045

Add m-ou-se to library-reviewers

view details

push time in 9 hours

create barnchdtolnay/rust-team

branch : m-ou-se

created branch time in 9 hours

delete branch dtolnay/rust-team

delete branch : library-reviewers

delete time in 9 hours

pull request commentrust-lang/team

Add library-reviewers team with rust-lang/rust review permission

Yeah I'll follow up right away with the next PR.

dtolnay

comment created time in 10 hours

push eventrust-lang-nursery/rust-cookbook

Rust Cookbook

commit sha 58f3d9de775173dbd40190e74bc0464332c91489

Build cookbook at rust-lang-nursery/rust-cookbook@4789410

view details

push time in 11 hours

issue commentgz/rust-cpuid

rustversion::stable means examples don't compile on beta

#[rustversion::nightly] + #[rustversion::not(nightly)] seems to be the intention in the code.

Mark-Simulacrum

comment created time in 11 hours

pull request commentrust-lang/rust

Check for exhaustion in RangeInclusive::contains

Let's consider both as part of this FCP. I imagine we'd not want to do one without the other. But the code change for SliceIndex can go in either this PR or separate PR if easier.

cuviper

comment created time in 12 hours

pull request commentrust-lang/team

Add library-reviewers team with rust-lang/rust review permission

libs team libs FCP review rotation
Amanieu :heavy_check_mark: :heavy_check_mark:
BurntSushi :heavy_check_mark: :heavy_check_mark:
cramertj :heavy_check_mark:
dtolnay :heavy_check_mark: :heavy_check_mark: :heavy_check_mark:
joshtriplett :heavy_check_mark:
kennytm :heavy_check_mark:
KodrAus :heavy_check_mark: :heavy_check_mark: :heavy_check_mark:
LukasKalbertodt :heavy_check_mark: :heavy_check_mark:
Mark-Simulacrum :heavy_check_mark:
sfackler :heavy_check_mark: :heavy_check_mark: :heavy_check_mark:
shepmaster :heavy_check_mark:
SimonSapin :heavy_check_mark:
withoutboats :heavy_check_mark: :heavy_check_mark: :heavy_check_mark:
dtolnay

comment created time in 12 hours

PR opened rust-lang/team

Add library-reviewers team with rust-lang/rust review permission

Member list is taken from: https://github.com/rust-lang/highfive/blob/4420ccbffd38c700dbcfd3fb943f8b5ab53ee10d/highfive/configs/rust-lang/rust.json#L7-L9

The current list in this commit all already have at least these permissions.

  • via libs team: dtolnay, KodrAus, LukasKalbertodt, sfackler, withoutboats
  • via lang team: cramertj, joshtriplett
  • via infra team: kennytm, Mark-Simulacrum, shepmaster

However, I am hoping to add another standard library reviewer who is not already in one of the other teams with review permission.

+25 -0

0 comment

1 changed file

pr created time in 12 hours

push eventdtolnay/rust-team

David Tolnay

commit sha 053001a5134953415010618f3023ed6137f68a4e

Add library-reviewers team with rust-lang/rust review permission Member list is taken from https://github.com/rust-lang/highfive/blob/4420ccbffd38c700dbcfd3fb943f8b5ab53ee10d/highfive/configs/rust-lang/rust.json The current list in this commit all already have at least these permissions. - via libs team: dtolnay, KodrAus, LukasKalbertodt, sfackler, withoutboats - via lang team: cramertj, joshtriplett - via infra team: kennytm, Mark-Simulacrum, shepmaster However, I am hoping to add another standard library reviewer who is not already in one of the other teams with review permission.

view details

push time in 12 hours

pull request commentrust-lang/rust

Define `fs::hard_link` to not follow symlinks.

Would we be comfortable with wording that indicates "symlink is not followed if such a thing is possible on the platform"? I think the concern motivating the PR was that even on platforms which support the behavior we prefer for fs::hard_link, you can't count on that to be the standard library's behavior.

This implies if VxWorks or Redox were to grow support for this operation later, we'd accept a change to the behavior to use it. In other words users would have the new guarantee from this PR on platforms that support it, and would continue to have the old weaker guarantee on other platforms until such time as those support it.

sunfishcode

comment created time in 12 hours

pull request commentrust-lang/rust

Check for exhaustion in RangeInclusive::contains

@rust-lang/libs: this PR changes the implementation of RangeBounds for RangeInclusive in such a way that the following assertions succeed. Previously range.contains(end) continued returning true even after range.is_empty() was true.

fn main() {
    let mut range = 0..=0;
    assert!(!range.is_empty());
    assert!(range.contains(&0));

    range.next();
    assert!(range.is_empty());
    assert!(!range.contains(&0));
}

Another example of the behavior change:

fn main() {
    let array = ['w', 'x', 'y', 'z'];
    let mut range = 0..=3;
    while let Some(i) = range.next() {
        println!(
            "after i={}, the remaining elements are {:?}",
            i, &array[range.clone()],
        );
    }
}

Old behavior:

<pre> after i=0, the remaining elements are ['x', 'y', 'z'] after i=1, the remaining elements are ['y', 'z'] after i=2, the remaining elements are ['z'] <b>after i=3, the remaining elements are ['z']</b> </pre>

New behavior:

<pre> after i=0, the remaining elements are ['x', 'y', 'z'] after i=1, the remaining elements are ['y', 'z'] after i=2, the remaining elements are ['z'] <b>after i=3, the remaining elements are []</b> </pre>

@rfcbot fcp merge

cuviper

comment created time in 12 hours

pull request commentrust-lang/rust

Define `fs::hard_link` to not follow symlinks.

@rfcbot fcp merge @rust-lang/libs:

POSIX leaves it implementation-defined whether link follows symlinks. In practice, for example, on Linux it does not and on FreeBSD it does. So, switch to linkat, so that we can pick a behavior rather than depending on OS defaults.

Pick the option to not follow symlinks. This is somewhat arbitrary, but seems the less surprising choice because hard linking is a very low-level feature which requires the source and destination to be on the same mounted filesystem, and following a symbolic link could end up in a different mounted filesystem.

sunfishcode

comment created time in 12 hours

push eventdtolnay/rust-team

David Tolnay

commit sha 41640bfcca54d0d7593bb3511941493415e4af08

Add library-reviewers team with rust-lang/rust review permission The current member list in this commit all already have at least these permissions. - via libs team: dtolnay, KodrAus, LukasKalbertodt, sfackler, withoutboats - via lang team: cramertj, joshtriplett - via infra team: kennytm, Mark-Simulacrum, shepmaster However, I am hoping to add another standard library reviewer who is not already in one of the other teams with review permission.

view details

push time in 14 hours

create barnchdtolnay/rust-team

branch : library-reviewers

created branch time in 14 hours

delete branch dtolnay/rust-team

delete branch : test-ci

delete time in 14 hours

delete branch dtolnay/rust-team

delete branch : nrc-patch-1

delete time in 14 hours

delete branch dtolnay/rust-team

delete branch : llvmicebreaker-example

delete time in 14 hours

delete branch dtolnay/rust-team

delete branch : gh-pages

delete time in 14 hours

fork dtolnay/team

Rust teams structure

fork in 15 hours

pull request commentrust-lang/rust

Add Pin::static_ref, static_mut.

@bors r+

m-ou-se

comment created time in 15 hours

PullRequestReviewEvent

pull request commentrust-lang/rust

Avoid panic_bounds_check in fmt::write.

@bors r=Mark-Simulacrum

<details> <summary>I confirmed that the new test fails without the changes in the PR.</summary>

---- [run-make] run-make/fmt-write-bloat stdout ----

error: make failed
status: exit code: 2
command: "make"
stdout:
------------------------------------------
LD_LIBRARY_PATH="/git/rust/build/x86_64-unknown-linux-gnu/test/run-make/fmt-write-bloat/fmt-write-bloat:/git/rust/build/x86_64-unknown-linux-gnu/stage1/lib:/git/rust/build/x86_64-unknown-linux-gnu/stage0-bootstrap-tools/x86_64-unknown-linux-gnu/release/deps:/git/rust/build/x86_64-unknown-linux-gnu/stage0/lib" '/git/rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc' --out-dir /git/rust/build/x86_64-unknown-linux-gnu/test/run-make/fmt-write-bloat/fmt-write-bloat -L /git/rust/build/x86_64-unknown-linux-gnu/test/run-make/fmt-write-bloat/fmt-write-bloat  main.rs -O
nm /git/rust/build/x86_64-unknown-linux-gnu/test/run-make/fmt-write-bloat/fmt-write-bloat/main | "/git/rust/src/etc/cat-and-grep.sh" -v panicking panic_fmt panic_bounds_check pad_integral Display Debug
[[[ begin stdout ]]]
00000000000020b2 R anon.ad56e829de00bb5e05e79e94a78aaeca.0.llvm.11246502207772803501
0000000000004008 B __bss_start
0000000000004008 b completed.8060
                 w __cxa_finalize@@GLIBC_2.2.5
0000000000001070 t deregister_tm_clones
00000000000010e0 t __do_global_dtors_aux
0000000000003d20 d __do_global_dtors_aux_fini_array_entry
0000000000004000 D __dso_handle
0000000000003dd8 d _DYNAMIC
0000000000004008 D _edata
0000000000004010 B _end
0000000000001d6c T _fini
0000000000001120 t frame_dummy
0000000000003d18 d __frame_dummy_init_array_entry
0000000000002524 r __FRAME_END__
0000000000003f98 d _GLOBAL_OFFSET_TABLE_
                 w __gmon_start__
000000000000217c r __GNU_EH_FRAME_HDR
0000000000001000 t _init
0000000000003d20 d __init_array_end
0000000000003d18 d __init_array_start
                 w _ITM_deregisterTMCloneTable
                 w _ITM_registerTMCloneTable
0000000000001290 T __libc_csu_fini
0000000000001220 T __libc_csu_init
                 U __libc_start_main@@GLIBC_2.2.5
00000000000011c0 T main
00000000000010a0 t register_tm_clones
00000000000011b0 T rust_begin_unwind
0000000000001040 T _start
0000000000004008 D __TMC_END__
0000000000001d60 T _ZN36_$LT$T$u20$as$u20$core..any..Any$GT$7type_id17hec09389da73b5e7cE
0000000000001c30 T _ZN4core3fmt3num3imp52_$LT$impl$u20$core..fmt..Display$u20$for$u20$u64$GT$3fmt17h54377f781f7a5c8fE
0000000000001c30 T _ZN4core3fmt3num3imp54_$LT$impl$u20$core..fmt..Display$u20$for$u20$usize$GT$3fmt17h4fa1341a9dac6525E
00000000000012c0 T _ZN4core3fmt5write17h100dc89493224d93E
0000000000001a80 t _ZN4core3fmt9Formatter12pad_integral12write_prefix17h204c271bcefaaa8cE
00000000000015b0 T _ZN4core3fmt9Formatter12pad_integral17hb075f5592a5d8a70E
00000000000012a0 T _ZN4core3ops8function6FnOnce9call_once17hd1e4d320fcc785faE.llvm.14856878211942904523
0000000000001130 t _ZN4core3ptr13drop_in_place17h8d4e61ec59d31a0eE
0000000000001ad0 t _ZN4core3ptr13drop_in_place17hd5cc673701fb5dfbE
0000000000001ba0 t _ZN4core4iter8adapters3zip16Zip$LT$A$C$B$GT$3new17h5f4b1cffaf34d111E
0000000000001be0 t _ZN4core4iter8adapters3zip16Zip$LT$A$C$B$GT$3new17hf19b0aefdc63476aE
0000000000001ae0 T _ZN4core9panicking18panic_bounds_check17ha31d9d2fa83bb84dE
0000000000001b60 T _ZN4core9panicking9panic_fmt17he9332856f0d02b11E
0000000000001140 t _ZN50_$LT$$RF$mut$u20$W$u20$as$u20$core..fmt..Write$GT$10write_char17h3bc2d3f42fbd7666E
0000000000001150 t _ZN50_$LT$$RF$mut$u20$W$u20$as$u20$core..fmt..Write$GT$9write_fmt17h0fd2e1dfd6fb1e2aE
00000000000011a0 t _ZN50_$LT$$RF$mut$u20$W$u20$as$u20$core..fmt..Write$GT$9write_str17h46dc1af754709fa5E

[[[ end stdout ]]]
Error: should not match: panicking
Error: should not match: panic_fmt
Error: should not match: panic_bounds_check
Error: should not match: pad_integral
Error: should not match: Displayconsole

</details>

m-ou-se

comment created time in 15 hours

PullRequestReviewEvent

pull request commentrust-lang/rust

Avoid panic_bounds_check in fmt::write.

src/test/run-make/fmt-write-bloat/main doesn't need to be checked in, right?

m-ou-se

comment created time in 15 hours

pull request commentrust-lang/rust

BTreeMap: split off most code of remove and split_off

@bors r+

ssomers

comment created time in 15 hours

PullRequestReviewEvent
PullRequestReviewEvent

push eventdtolnay/bootstrap

David Tolnay

commit sha cdbd16975fb4b26bd4fbfe38443a079310619631

Add rustc 1.47.0

view details

push time in 16 hours

issue closeddtolnay/quote

Getting struct members in quote macro

Simply this:

struct Bar { ... }

impl ToTokens for Bar { ... }

struct Foo {
    pub bar: Bar,
}

// ...

let foo: Foo = ...;

let q = quote! {
    blah blah #{foo.bar}.baz
};

This isn't possible it seems. Instead, we have to do something like this:

let foo: Foo = ...;
let bar: Bar = foo.bar.clone();

let q = quote! {
    blah blah #bar.baz
};

Which is very messy and for large quotes requires a lot of doing that. Plus it's expensive as we have to clone a lot of things. And finally it only works if Bar is Clone.

closed time in 16 hours

thorlucas

issue commentdtolnay/quote

Getting struct members in quote macro

Yes -- please write this using a reference as shown in the previous comment.

thorlucas

comment created time in 16 hours

release dtolnay/cargo-llvm-lines

0.4.9

released time in 17 hours

issue commentdtolnay/cargo-llvm-lines

0.4.7 broke support for passing extra arguments through llvm-lines

Sorry about the breakage. This was not intentional. Fixed in 0.4.9.

Mark-Simulacrum

comment created time in 17 hours

push eventdtolnay/cargo-llvm-lines

David Tolnay

commit sha 4252785bc513e74b7ff7ab7fc995b6451eb1bc59

Lockfile update

view details

David Tolnay

commit sha b5b494830ec47954ef1340ef920866051bf018ea

Release 0.4.9

view details

push time in 17 hours

created tagdtolnay/cargo-llvm-lines

tag0.4.9

Count lines of LLVM IR per generic function

created time in 17 hours

delete branch dtolnay/cargo-llvm-lines

delete branch : last

delete time in 17 hours

push eventdtolnay/cargo-llvm-lines

David Tolnay

commit sha f54d7c6cb4787de32da88ac7e805dcf47f5064ca

Accept trailing extra rustc options after `--`

view details

David Tolnay

commit sha 93134b0fa5a97630a67669be06a392a86e1145cf

Update usage string to show rustc options

view details

David Tolnay

commit sha f60c96e17a66ca85b64d41400da28f04727392c8

Fix pre-1.45 build which doesn't have FromStr for OsString

view details

David Tolnay

commit sha 5b0c077166d5d410886aadd8337897dce1920a66

Merge pull request #41 from dtolnay/last Accept trailing extra rustc options after `--`

view details

push time in 17 hours

issue closeddtolnay/cargo-llvm-lines

0.4.7 broke support for passing extra arguments through llvm-lines

There's quite a bit of argument refactoring in the 0.4.6 to 0.4.7 diff, so I'm not sure of the precise commit, but previously cargo llvm-lines -- -Zverbose for example would've worked, passing the -Zverbose to rustc (like cargo rustc does). perf.rust-lang.org used this support.

I think this was likely unintentional -- perhaps we could re-add that support?

closed time in 17 hours

Mark-Simulacrum

push eventdtolnay/cargo-llvm-lines

David Tolnay

commit sha f60c96e17a66ca85b64d41400da28f04727392c8

Fix pre-1.45 build which doesn't have FromStr for OsString

view details

push time in 17 hours

PR opened dtolnay/cargo-llvm-lines

Accept trailing extra rustc options after `--`

Fixes #39.

+5 -1

0 comment

1 changed file

pr created time in 17 hours

create barnchdtolnay/cargo-llvm-lines

branch : last

created branch time in 17 hours

delete branch dtolnay/cargo-llvm-lines

delete branch : --

delete time in 17 hours

pull request commentdtolnay/cargo-llvm-lines

Accept trailing extra rustc options after `--`

GitHub Actions does not like my branch name. :(

  /usr/bin/git checkout --progress --force -B -- refs/remotes/origin/--
  Error: fatal: '--' is not a valid branch name.
  Error: The process '/usr/bin/git' failed with exit code 128
dtolnay

comment created time in 17 hours

PR opened dtolnay/cargo-llvm-lines

Accept trailing extra rustc options after `--`

Fixes #39.

+5 -1

0 comment

1 changed file

pr created time in 17 hours

create barnchdtolnay/cargo-llvm-lines

branch : --

created branch time in 17 hours

push eventdtolnay/cargo-llvm-lines

David Tolnay

commit sha 016de8e5ee2737f932d09b5b17c907df625f80be

No need to treat rustc as code in comment

view details

David Tolnay

commit sha 20a7985c26fc4cc36d26282084c67ec22225f604

Set help text template for clap

view details

push time in 17 hours

issue commentgoogle/autocxx

Nicer syntax for `include_cpp`

Ah I see, good call.

I found it's possible to make it work as follows, but this gets pretty deep into workaround territory so isn't necessarily advisable. But it supports both hover documentation and click-through on both include and inner with rust-analyzer.

use testing::outer;

outer! {
    #include "test.h"

    inner!(...)
    inner!(...)
}
// lib.rs

/// (DOCUMENTATION OF OUTER...)
#[macro_export]
macro_rules! outer {
    (
        $(#$include:ident $lit:literal)*
        $($mac:ident!($($arg:tt)*))*
    ) => {
        $($crate::$include!{__docs})*
        $($crate::$mac!{__docs})*
        $crate::do_the_work! {
            $(#include $lit)*
            $($mac!($($arg)*))*
        }
    };
}

/// (DOCUMENTATION OF INCLUDE...)
#[macro_export]
macro_rules! include {
    ($($tt:tt)*) => { $crate::usage!{$($tt)*} };
}

/// (DOCUMENTATION OF INNER...)
#[macro_export]
macro_rules! inner {
    ($($tt:tt)*) => { $crate::usage!{$($tt)*} };
}

#[doc(hidden)]
#[macro_export]
macro_rules! usage {
    (__docs) => {};
    ($($tt:tt)*) => {
        compile_error! {r#"usage:  outer! {
                   #include "path/to/header.h"
                   inner!(...)
               }
"#}
    };
}

#[doc(hidden)]
#[macro_export]
macro_rules! do_the_work { // FIXME: this is a procedural macro
    ($($tt:tt)*) => {};
}
adetaylor

comment created time in a day

issue commentgoogle/autocxx

Nicer syntax for `include_cpp`

Dare I say, that feels like a bug?

Yeah -- sadly the implementation of procedural macros is pretty awful and this isn't among the biggest things wrong with it. :(

adetaylor

comment created time in 2 days

issue commentgoogle/autocxx

Nicer syntax for `include_cpp`

Do you mean (looking at the snippet at the top of the thread) documentation of allow! and similar macros? If so, wouldn't that work exactly the same whether or not the outer macro invocation is an attribute? Either way you'd still expose allow! as a macro that if ever invoked by rustc would print a compile_error showing the intended use of include_cxx.

adetaylor

comment created time in 2 days

created tagdtolnay/dyn-clone

tag1.0.3

Clone trait that is object-safe

created time in 2 days

push eventdtolnay/dyn-clone

David Tolnay

commit sha cd46505e869a2ae566ec72d144454bed12d63692

Release 1.0.3

view details

push time in 2 days

push eventdtolnay/dyn-clone

David Tolnay

commit sha 8080b132cad42458ee2e0c61d4cc301a645d95bf

Seal trait and method Closes #9.

view details

David Tolnay

commit sha 170afb75709a94f7d83ad2e9db50c2d94ec71e1d

Hide trait method from autocompleters

view details

push time in 2 days

issue closeddtolnay/dyn-clone

API Design Feedback

First of all, thanks for creating this lib. I just found out about its existence and I really like the solution you got there! The lib does one thing and it does it well. 🙂

There are some API design choices I think could be slightly improved upon. The intention of how it's supposed to be used is clear, nothing to complain here. There are just some small changes, that could be made to ensure, that it's impossible to misuse, rather than just communicating what not to do.

  1. DynClone is implemented for every T where T: Clone. However, DynClone could just be implemented by any public user for any type. It's totally useless, of course. Changing pub trait DynClone { … } to pub trait DynClone: Clone { … } will outright prevent any attempt at user implementation. I do not know if specialization will change this property in the future. I guess, one could also use the following which would be future-proof:
mod private {
    pub trait Sealed {};
}

pub trait DynClone: private::Sealed { … }
  1. Hiding the trait method from the public API is good. Making it impossible to use is better. If you create the struct
#[non_exhaustive]
pub struct Private;

and change the function declaration to

unsafe fn clone_box(&self, _: Private) -> *mut ();

it's possible to deny any usage from the outside at no runtime cost.

P.S.: You can remove the unsafe from unsafe fn clone_box, too.

closed time in 2 days

phlopsi

push eventdtolnay/dyn-clone

David Tolnay

commit sha 914e969a3a3d239a00bcd9334e6b0228afc9e50a

Format with rustfmt 1.4.22-nightly

view details

push time in 2 days

push eventdtolnay/dyn-clone

David Tolnay

commit sha 6f28c61f2ee76c5acb955d3c3a673abf87b01196

Use Clone from core prelude

view details

David Tolnay

commit sha 1f7f509f366aaff378d29650da9879a50a9e4efe

Clean trailing whitespace from doc comment block

view details

push time in 2 days

issue commentdtolnay/cxx

Expose a way to bypass is_trivially_destructible/_move_constructible check on extern types passed by value

That is the intended behavior!

ImplCopy is extra wacky as far as C++ type go because it can only be copy constructed -- the user-defined copy constructor implicitly deletes the default constructor and disables aggregate initialization. A hypothetical use for such a type would for library-level capabilities: code having possession of an ImplCopy has "permission" to call certain APIs, can share that same permission to other code by passing a copy of its ImplCopy, and library code can require that its callers prove they've received "permission" by taking an ImplCopy argument back in. Where it gets great is the ImplCopy library can use the copy constructor to track the entire chain of who gave permission to whom, all the way from when the permission was originally given out by the library to when it was proven later by a caller.

Letting Rust move one of them around with no constructor call would defeat this.

class CapabilityLog {
  friend struct ImplCopy;
  static std::vector<std::tuple<const ImplCopy*, const ImplCopy*>> log_;
};

struct ImplCopy {
  int32_t x;
  ImplCopy(const ImplCopy &obj) {
    CapabilityLog::log_.emplace_back(&obj, this);
  }
};

The opt out required in the proof of concept (https://github.com/dtolnay/cxx/issues/359#issuecomment-706793442) is:

  // if you own the type
  struct ImplCopy {
    int32_t x;
    ImplCopy(const ImplCopy &obj);
+   using IsRelocatable = std::true_type;
  };
  // otherwise
+ template <> struct rust::IsRelocatable<ImplCopy> : std::true_type {};
dtolnay

comment created time in 2 days

push eventdtolnay/syn

David Tolnay

commit sha 8c8121906d48d6677430126b4893e73f63c928d8

Update test suite to nightly-2020-10-18

view details

push time in 2 days

push eventdtolnay/thiserror

David Tolnay

commit sha 3ed6e38cc8d3f3063b899053c1d0ddbfbea2b419

Add ui test of unexpected display expression

view details

David Tolnay

commit sha 04d2e6c998fe6790c9a32c64ce29682fc0159a01

Pick up more specific string literal error message

view details

David Tolnay

commit sha fbe98044768421f6f7d15a53b9fbd0ddcf6281ae

Provide suggestion for anyone grepping for concat

view details

push time in 4 days

release dtolnay/syn

1.0.45

released time in 4 days

push eventdtolnay/syn

David Tolnay

commit sha 41622dafbebbe2d724e073a22fd0795844c68d18

Release 1.0.45

view details

push time in 4 days

created tagdtolnay/syn

tag1.0.45

Parser for Rust source code

created time in 4 days

delete branch dtolnay/syn

delete branch : expectliteral

delete time in 4 days

push eventdtolnay/syn

David Tolnay

commit sha 18ccb5b7756ea973d548f64866aeba0bd3d73755

Provide more detailed error when parsing specific literal kind

view details

David Tolnay

commit sha 0db160e42efecfc261b89df4e3cd5ad41a7cfc74

Merge pull request #908 from dtolnay/expectliteral Provide more detailed error when parsing specific literal kind

view details

push time in 4 days

issue commentdtolnay/thiserror

#[error(concat!("foo ", $param))] silently ignored

I think it should be sufficient that we support fmt expressions already. #[error("invalid {}", $what)]

Kixunil

comment created time in 4 days

issue closeddtolnay/thiserror

#[error(concat!("foo ", $param))] silently ignored

Consider this code:

macro_rules! error_type {
    ($name:ident, $what:expr) => {
        #[derive(Debug, thiserror::Error)]
        // This doesn't work
        #[error(concat!("invalid ", $what))]
        // This does work
        // #[error("invalid")]
        struct Error;
    }
}

error_type!(Error, "foo");

fn main() {
    println!("error: {}", Error);
}

The compiler complains about Error not implementing Display but has no problem with concat!() being in the attribute. My understanding is that the macro call tokens are passed into thiserror which then ignores it instead of complaining or implementing Display.

I'd very much like to see thiserror supporting concat! as it makes creating new error types much easier. If that's not possible, then there should be a proper error message explaining it.

Since thiserror is not available in playground I've created a repository demonstrating this bug for your convenience.

closed time in 4 days

Kixunil

PR opened dtolnay/syn

Provide more detailed error when parsing specific literal kind
+15 -15

0 comment

2 changed files

pr created time in 4 days

create barnchdtolnay/syn

branch : expectliteral

created branch time in 4 days

push eventdtolnay/syn

David Tolnay

commit sha 1e4e050bb0a73adb1edc632af43ea4353c9fc402

Add test of Lit parsing error message

view details

push time in 4 days

issue commentdtolnay/thiserror

#[error(concat!("foo ", $param))] silently ignored

I am not able to reproduce this. I cloned the repo you gave and ran cargo check, but it shows the attribute containing concat as a parse error, not silently ignored.

Could you provide the Rust toolchain version and target on which you're observing it silently ignored?

<pre> $ <b>cargo check</b>

error: expected literal --> src/main.rs:5:17 | 5 | #[error(concat!("invalid ", $what))] | ^^^^^^ ... 12 | error_type!(Error, "foo"); | -------------------------- in this macro invocation | = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info) </pre>

Kixunil

comment created time in 4 days

release dtolnay/cargo-llvm-lines

0.4.8

released time in 4 days

issue commentdtolnay/cargo-llvm-lines

Provide Cargo.lock for downstream Linux packages

Published one in 0.4.8.

jonasmalacofilho

comment created time in 4 days

push eventdtolnay/cargo-llvm-lines

David Tolnay

commit sha 95f1972c12e98c3cb0250cdd95554232aa78a214

Release 0.4.8

view details

push time in 4 days

created tagdtolnay/cargo-llvm-lines

tag0.4.8

Count lines of LLVM IR per generic function

created time in 4 days

delete branch dtolnay/cargo-llvm-lines

delete branch : lock

delete time in 4 days

push eventdtolnay/cargo-llvm-lines

David Tolnay

commit sha 9b746b48306e94be7ae43098f12ea2c66d878b57

Provide Cargo.lock for reproducible packaging

view details

David Tolnay

commit sha f57802b65ae2b621554ccc15d0180392777f5d49

Raise minimum CI version to rust 1.38 to support new lockfile format

view details

David Tolnay

commit sha cbe11723a8eb4492b043b1b3ae9ed2b60551ad6f

Raise minimum CI version to 1.40 for cfg(doctest) in remove_dir_all crate

view details

David Tolnay

commit sha 3cc005541530bac7c5b0fea98e52ae28883ec9af

Merge pull request #38 from dtolnay/lock Provide Cargo.lock for reproducible packaging

view details

push time in 4 days

issue closeddtolnay/cargo-llvm-lines

Provide Cargo.lock for downstream Linux packages

Hi,

Could a Cargo.lock file be included in future releases so that downstream Linux packages can be reproducible<sup>[1]</sup> and, potentially, more reliable?

P.S. Just packaged this for ArchLinux: cargo-llvm-lines<sup>AUR</sup>.

closed time in 4 days

jonasmalacofilho

push eventdtolnay/cargo-llvm-lines

David Tolnay

commit sha cbe11723a8eb4492b043b1b3ae9ed2b60551ad6f

Raise minimum CI version to 1.40 for cfg(doctest) in remove_dir_all crate

view details

push time in 4 days

push eventdtolnay/cargo-llvm-lines

David Tolnay

commit sha f57802b65ae2b621554ccc15d0180392777f5d49

Raise minimum CI version to rust 1.38 to support new lockfile format

view details

push time in 4 days

PR opened dtolnay/cargo-llvm-lines

Provide Cargo.lock for reproducible packaging

Closes #37.

+307 -1

0 comment

2 changed files

pr created time in 4 days

create barnchdtolnay/cargo-llvm-lines

branch : lock

created branch time in 4 days

issue commentdtolnay/paste

Feature requests: Concatenate integer literals & create identifiers based on a given range

This is in scope for the https://github.com/dtolnay/seq-macro crate more than this one. You'll want to do something like:

// [dependencies]
// seq-macro = "0.2"

use seq_macro::seq;

pub trait PinId {
    const NUM: u8;
}

seq!(G in 'A'..='D' {
    seq!(N in 00..=31 {
        pub enum P#G#N {}
        impl PinId for P#G#N {
            const NUM: u8 = N;
        }
    });
});
bradleyharden

comment created time in 4 days

release dtolnay/seq-macro

0.2.1

released time in 4 days

more