profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/dtolnay/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
David Tolnay dtolnay 0xF9BA143B95FF6D82 Menlo Park, CA

dtolnay/cxx 3142

Safe interop between Rust and C++

dtolnay/anyhow 2154

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

brson/stdx 1486

The missing batteries of Rust

bincode-org/bincode 1290

A binary encoder / decoder implementation in Rust.

dtolnay/cargo-expand 1109

Subcommand to show result of macro expansion

dtolnay/case-studies 962

Analysis of various tricky Rust code

dtolnay/async-trait 863

Type erasure for async trait methods

chyh1990/yaml-rust 467

A pure rust YAML implementation.

dtolnay/erased-serde 243

Type-erased Serialize, Serializer and Deserializer traits

dtolnay/cargo-llvm-lines 182

Count lines of LLVM IR per generic function

PR closed rust-lang/rust

Add Result::check, analogous to Option::filter T-libs-api S-waiting-on-review
+30 -0

8 comments

1 changed file

SoniEx2

pr closed time in 4 hours

pull request commentrust-lang/rust

Add Result::check, analogous to Option::filter

I agree with @kennytm's rebuttal and I would prefer not to build this into the Result type.

Thanks anyway SoniEx2!

SoniEx2

comment created time in 4 hours

issue openedrust-lang/rust-clippy

Improve explanation of not_unsafe_ptr_arg_deref

I pointed out in https://github.com/rust-lang/rust-clippy/issues/7666#issuecomment-919006725 that the use of allow(clippy::not_unsafe_ptr_arg_deref) on crates.io is shockingly high.

Here is the list: https://dtolnay.github.io/noisy-clippy/not_unsafe_ptr_arg_deref.html

I spot checked some of these and pretty much every case is unsound.

  • https://github.com/dtn7/bp7-rs/issues/2
  • https://github.com/UnitedTraders/aeron-rs/issues/14
  • https://github.com/drogue-iot/drogue-ffi-compat/issues/1
  • https://github.com/jni-rs/jni-rs/issues/331
  • https://github.com/wiomoc/mosquitto-jwt-auth/issues/11
  • https://github.com/pact-foundation/pact-reference/issues/148
  • https://github.com/EmbarkStudios/spirv-tools-rs/issues/27
  • https://github.com/JoNil/tm-rs/issues/1
  • https://github.com/zombodb/pgx/issues/196
  • https://github.com/zombodb/pgx/issues/215

If people are not understanding what this lint is attempting to tell them, it seems like the lint isn't doing its job. We should look into whether the lint's documentation or the lint's diagnostic output can be improved in a way that better comes across to people. It may be worth looping in some of the maintainers of some of the crates above about what might have been helpful for them to understand the lint.

created time in 6 hours

issue commentdtolnay/cxx

Allow overriding receiver to be `&const Self` for non-const C++ member functions

The closest C++ equivalent of the Rust implementation you wrote:

pub struct Foo {
    data: Mutex<i32>,
}

impl Foo {
    pub fn doThing(&self) {
        *self.data.lock() += 1
    }
}

is:

class Foo {
  mutable Mutex mutex;
  mutable int data;

public:
  Foo() : data(0) {}

  void doThing() const {
    std::lock_guard<std::mutex> guard(mutex);
    data++;
  }
};

which is perfectly fine to bind via cxx. That is the recommended implementation if this is first party code. The interpretation of const == threadsafe is common, well known, and is a design pattern in the C++ standard library.

Eadword

comment created time in 8 hours

issue openeddtolnay/syn

Change syntax of where clauses on type aliases

https://github.com/rust-lang/rust/issues/89122, which is in FCP, proposes that:

type StringMap<K> where K: PartialOrd = BTreeMap<K, String>;

should instead be spelled as:

type StringMap<K> = BTreeMap<K, String>
where
    K: PartialOrd;

If the proposal passes, we'll need to implement this in syn.

created time in 8 hours

issue commentrust-lang/rust

Proposal: Change syntax of where clauses on type aliases

Separately, I feel that https://github.com/rust-lang/rust/issues/89122#issuecomment-923266388 is going to require a response/consensus before completing the FCP.

Here is a concrete example to consider:

#![feature(trait_alias)]

trait Alias<T: Clone> = where T: Default;

// okay, equivalent to `where T: Clone + Default`
fn clone<T: Alias<T> + Clone>() {}

// ERROR, trait bound `T: Clone` not satisfied
fn default<T: Alias<T> + Default>() {}

In this situation, what is proposed to be the where equivalent of the T: Clone bound on Alias? Prior to this proposal, it's natural to expect that it would be:

trait Alias<T> where T: Clone = where T: Default;

This proposal throws a wrench in the works, as @petrochenkov called attention to. It would now seem to be the somewhat bizarre:

trait Alias<T> = where T: Default where T: Clone;

Relatedly, what does the following mean?

trait Alias<T> = Default
where
    T: Clone;

Is this equivalent to trait Alias<T: Clone> = Default, or to (the old interpretation of) trait Alias<T> = Default where T: Clone, which are not the same thing?

trait_alias is unstable (cc tracking issue https://github.com/rust-lang/rust/issues/41517) but since the syntax is heavily inspired by type alias syntax, I think it's worth acknowledging the implications that type alias syntax changes would have on it, and maybe loop in people involved in that proposal if there are specific people.

nikomatsakis

comment created time in 8 hours

issue commentrust-lang/rust

Proposal: Change syntax of where clauses on type aliases

In the context of the FCP proposed in https://github.com/rust-lang/rust/issues/89122#issuecomment-923104269, what behavior is proposed if where is given in both places?

type Thing<T> where T: IntoIterator = T::IntoIter
where
    T::Item: Clone;

Does this union the clauses, or does it reject? From the discussion above I'm unable to tell whether a concrete behavior was proposed. Asking as someone who will need to implement this in a Rust parser.

nikomatsakis

comment created time in 8 hours

release dtolnay/syn

1.0.77

released time in 9 hours

push eventdtolnay/syn

David Tolnay

commit sha e91c00e0d9d7246cb8168540d5c82c8cda56e5da

Release 1.0.77

view details

push time in 9 hours

created tagdtolnay/syn

tag1.0.77

Parser for Rust source code

created time in 9 hours

delete branch dtolnay/syn

delete branch : bracedmacstmt

delete time in 9 hours

push eventdtolnay/syn

David Tolnay

commit sha 13b7dba1739807ad47dc38fa4dbd2ec143643d11

Parse trailing dot or question on braced macro invocation

view details

David Tolnay

commit sha d6ddb79f6191a73ad0c7f80104a6fff2358b9909

Merge pull request #1070 from dtolnay/bracedmacstmt Parse trailing dot or question on braced macro invocation

view details

push time in 9 hours

PR merged dtolnay/syn

Parse trailing dot or question on braced macro invocation

Closes #1068.

+5 -5

0 comment

2 changed files

dtolnay

pr closed time in 9 hours

issue closeddtolnay/syn

Parse dot and question mark after curly braced macro invocation

The legality of this syntax changed in https://github.com/rust-lang/rust/pull/88690.

Example upstream test case: https://github.com/rust-lang/rust/blob/bf642323d621dcefeef1d8ab4711aae36e357615/src/test/ui/parser/macro-braces-dot-question.rs

vec! { 1, 2, 3 }.len();
write! { vec![], "" }?;
println!{""}
[0]; // separate statement, not indexing into the result of println.

Currently fails to parse with syn because we consider the braced macro expression a statement terminator, same as rustc <=1.56.

error: expected expression
 --> dev/main.rs:6:21
  |
6 |     vec! { 1, 2, 3 }.len();
  |                     ^

closed time in 9 hours

dtolnay

PR opened dtolnay/syn

Parse trailing dot or question on braced macro invocation

Closes #1068.

+5 -5

0 comment

2 changed files

pr created time in 10 hours

create barnchdtolnay/syn

branch : bracedmacstmt

created branch time in 10 hours

delete branch dtolnay/syn

delete branch : up

delete time in 10 hours

push eventdtolnay/syn

David Tolnay

commit sha 9aeb5881944c8fa279d7d63f4568b25a612eefe0

Update test suite to nightly-2021-09-22

view details

David Tolnay

commit sha 4f37c14181ff20318723a83e58020e9befc8098a

Categorize new test suite parse failures

view details

David Tolnay

commit sha 912219740c8fa8ce299d7c5ab53a1f79575eac7f

Merge pull request #1069 from dtolnay/up Update test suite to nightly-2021-09-22

view details

push time in 10 hours

PR merged dtolnay/syn

Update test suite to nightly-2021-09-22

Notably https://github.com/rust-lang/rust/pull/84571 has been reverted upstream in https://github.com/rust-lang/rust/pull/88775, and https://github.com/rust-lang/rust/pull/88690 needs to be implemented in syn which I've filed https://github.com/dtolnay/syn/issues/1068 to track.

+6 -5

0 comment

1 changed file

dtolnay

pr closed time in 10 hours

PR opened dtolnay/syn

Update test suite to nightly-2021-09-22

Notably https://github.com/rust-lang/rust/pull/84571 has been reverted upstream in https://github.com/rust-lang/rust/pull/88775, and https://github.com/rust-lang/rust/pull/88690 needs to be implemented in syn which I've filed https://github.com/dtolnay/syn/issues/1068 to track.

+6 -5

0 comment

1 changed file

pr created time in 10 hours

create barnchdtolnay/syn

branch : up

created branch time in 10 hours

issue openeddtolnay/syn

Parse dot and question mark after curly braced macro invocation

The legality of this syntax changed in https://github.com/rust-lang/rust/pull/88690.

Example upstream test case: https://github.com/rust-lang/rust/blob/bf642323d621dcefeef1d8ab4711aae36e357615/src/test/ui/parser/macro-braces-dot-question.rs

vec! { 1, 2, 3 }.len();
write! { vec![], "" }?;
println!{""}
[0]; // separate statement, not indexing into the result of println.

Currently fails to parse with syn because we consider the braced macro expression a statement terminator, same as rustc <=1.56.

error: expected expression
 --> dev/main.rs:6:21
  |
6 |     vec! { 1, 2, 3 }.len();
  |                     ^

created time in 10 hours

issue openedzombodb/pgx

`is_a` is unsound

Similar to #196. This exposes UB to safe code. In general it is unsound for a safe API to result in UB.

fn main() {
    pgx::nodes::is_a(0xdeadbeefusize as _, 1000);
}
Segmentation fault (core dumped)

created time in 10 hours

PR closed dtolnay/syn

Switch non exhaustive syntax tree enums to use #[non_exhaustive]

This follows through on the comments on the __TestExhaustive variants promising that their purpose will be substituted with a deny(reachable) rustc lint once one is available.

https://github.com/dtolnay/syn/blob/ac68efab9576ab0f79633a48ebee5cca7321ddde/src/expr.rs#L247-L251

That lint is now landing as non_exhaustive_omitted_patterns in Rust 1.57. The correct way to use it for checking exhaustivity of a match is:

match expr {
    Expr::Array(e) => {...}
    Expr::Assign(e) => {...}
    ...
    Expr::Yield(e) => {...}

    #[cfg(test, deny(non_exhaustive_omitted_patterns))]
    _ => { /* some sane fallback */ }
}
+155 -209

1 comment

18 changed files

dtolnay

pr closed time in 2 days

pull request commentdtolnay/syn

Switch non exhaustive syntax tree enums to use #[non_exhaustive]

Closing, to be reopened when 1.57.0 stable is out.

dtolnay

comment created time in 2 days

PR opened dtolnay/syn

Switch non exhaustive syntax tree enums to use #[non_exhaustive]

This follows through on the comments on the __TestExhaustive variants promising that their purpose will be substituted with a deny(reachable) rustc lint once one is available.

https://github.com/dtolnay/syn/blob/ac68efab9576ab0f79633a48ebee5cca7321ddde/src/expr.rs#L247-L251

That lint is now landing as non_exhaustive_omitted_patterns in Rust 1.57. The correct way to use it for checking exhaustivity of a match is:

match expr {
    Expr::Array(e) => {...}
    Expr::Assign(e) => {...}
    ...
    Expr::Yield(e) => {...}

    #[cfg(test, deny(non_exhaustive_omitted_patterns))]
    _ => { /* some sane fallback */ }
}
+155 -209

0 comment

18 changed files

pr created time in 2 days

push eventdtolnay/syn

David Tolnay

commit sha c1ff3b724382878cc1dfc27bf7763521288bcb5c

Switch non exhaustive syntax tree enums to use #[non_exhaustive] This follows through on the comments on the __TestExhaustive variants promising that their purpose will be substituted with a deny(reachable) rustc lint once one is available. That lint is now landing as non_exhaustive_omitted_patterns in Rust 1.57. The correct way to use it for checking exhaustivity of a match is: match expr { Expr::Array(e) => {...} Expr::Assign(e) => {...} ... Expr::Yield(e) => {...} #[cfg(test, deny(non_exhaustive_omitted_patterns))] _ => { /* some sane fallback */ } }

view details

push time in 2 days

push eventdtolnay/syn

David Tolnay

commit sha 5c660f71419ef6a4a1a2df4baaa0a83ef17c0914

Switch non exhaustive syntax tree enums to use #[non_exhaustive] This follows through on the comments on the __TestNonexhaustive variants promising that their purpose will be substituted with a deny(reachable) rustc lint once one is available. That lint is now landing as non_exhaustive_omitted_patterns in Rust 1.57. The correct way to use it for checking exhaustivity of a match is: match expr { Expr::Array(e) => {...} Expr::Assign(e) => {...} ... Expr::Yield(e) => {...} #[cfg(test, deny(non_exhaustive_omitted_patterns))] _ => { /* some sane fallback */ } }

view details

push time in 2 days

push eventdtolnay/syn

David Tolnay

commit sha c5d43267d77a5e2f677591ab8a2e4ca9709524a1

tests/debug/gen.rs too

view details

David Tolnay

commit sha ac68efab9576ab0f79633a48ebee5cca7321ddde

Merge pull request #1066 from dtolnay/generated Set src/gen to be considered generated by linguist

view details

David Tolnay

commit sha 495ccddfadc71e016fba232e61a02301b353dae4

Switch non exhaustive syntax tree enums to use #[non_exhaustive]

view details

push time in 2 days

delete branch dtolnay/syn

delete branch : generated

delete time in 2 days