profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/danielhenrymantilla/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.
Daniel Henry-Mantilla danielhenrymantilla https://www.ditto.live/ France - Spain linkedin.com/in/danielhenrymantilla https://danielhenrymantilla.github.io

danielhenrymantilla/fstrings-rs 72

Python3 fstrings in Rust

danielhenrymantilla/inheritance-rs 23

Avoiding code reuse in Rust with OOP inheritance

danielhenrymantilla/byte-strings-rs 6

Rust byte strings manipulation, for a better and safer C FFI

beschmi/lean-ocaml-bindings 3

Ocaml bindings for the Lean Theorem Prover http://leanprover.github.io/

danielhenrymantilla/candy-rs 2

Syntaxic sugar for Rust: macros for lighter error handling code, and more.

danielhenrymantilla/dyn_safe.rs 2

Take control of the Semver hazard of the `dyn` safety of your traits!

danielhenrymantilla/easy-pin-rs 2

Using Pin made easy

danielhenrymantilla/heaptrace 2

Tool to (l)trace malloc/free/calloc/realloc calls and print heap status (arena) and (memory) contents

danielhenrymantilla/fix_hidden_lifetime_bug.rs 1

Proc-macro to write an automatic fix for the "hidden lifetime in impl Trait" issue

issue commentrust-lang/rust

Async fn does not compile if lifetime does not appear in bounds (sometimes)

That would certainly be a breaking change

When I thought about this I struggled to come up with an instance of this, so I'm genuinely curious about it. In other words: could annotating a function with #[fix_hidden_lifetime_bug] lead to breakage somewhere along the way? If so, such an example could help us evaluate the different options at our disposal 🙂

dtolnay

comment created time in 11 hours

issue openedrust-lang/rust

A Lifetime-generic `Copy` impl can allow fields which are only `Copy` when `'static`

<!-- 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:

#[derive(Clone)]
struct Foo<'lt>(&'lt ());

impl Copy for Foo<'static> {}

#[derive(Clone)]
struct Bar<'lt>(Foo<'lt>);

impl<'any> Copy for Bar<'any> {}

fn check(b: Bar<'_>) -> (Bar<'_>, Bar<'_>) {
    (b, b)
}
  • <sub><sup>(Note about #[derive(Clone)]: while this simple snippet features a Clone impl for all lifetimes, it is possible to restrict the impl of Clone for Foo to 'static as well, and yet offer a Bar<'any> which is Cloneable (thanks to it being Copyable). See below for a more detailed example about that).</sup></sub>

I expected to see this happen:

  • Either the impl Copy for Bar<'_> {} should have failed, or, at the very least, the borrow checker ought to have complained about the actual copy of b (from looking at the old related issue, a "late" / on-use borrow-checker issue was deemed good enough since such a check does prevent unsoundness).

    Alas, we can see here that that check can be dodged by using a wrapper type.

Instead, this happened:

  • the code compiled fine.

Meta

stable, beta and nightly are affected by this, and I suspect all versions of Rust do.

Impact

While contrived, this ought to be a I-unsound issue, since a library could feature a lifetime-generic type Foo<'lt> with an exploited safety invariant of Foo<'not_static> not being cloneable. Demo

@rustbot modify labels +I-unsound

Bonus / tangential issue 🎁

A type which is only Copy when 'static becomes, in practice / in non-generic context, unmoveable when non-'static:

#[derive(Clone)]
struct Foo<'lt>(&'lt ());

impl Copy for Foo<'static> {}

fn check(f: Foo<'_>) {
    assert!(Some(f).is_some()); // Error, lifetime `'static` required
}
  • Indeed, the move_or_copy heuristic decides to go for copy since the type is indeed copy_modulo_regions, but then the borrow checker (correctly) forbids the Copy operation since it can't prove it's 'static.

@rustbot modify labels +A-traits

created time in 4 days

push eventdanielhenrymantilla/with_locals.rs

Daniel Henry-Mantilla

commit sha 7bcda3beb8018eeeafa68fefac6803bd190a370e

Bump `bat` dependency (RUSTSEC-2021-0106) and commit to 0.3.0 release

view details

push time in 7 days

delete branch danielhenrymantilla/with_locals.rs

delete branch : bump_bat

delete time in 7 days

create barnchdanielhenrymantilla/with_locals.rs

branch : bump_bat

created branch time in 7 days

PullRequestReviewEvent

issue openedkillercup/cargo-edit

`crate_name.attr_name = …`-like entries are not supported

While

[dependencies]
foo = "x.y.z"
bar  = { version = "x.y.z", features = ["…"] }
[dependencies.baz]
version = "x.y.z"
features = ["…"]

is obviously supported by cargo-edit, something like:

[dependencies]
quux.version = "x.y.z"
quux.features = ["…"]

isn't (it fails with <code>Unexpected `.` Expected `=`</code>). Since the rest of the cargo ecosystem supports this syntax (handy, for instance, to reduce git diffs when adding features and so-on), I'd expect cargo edit to support it as well.

  • (I suspect this may be an incosistency between the TOML spec and the reality of Cargo.toml files, and may thus be an issue of the underlying ::toml_edit crate: https://github.com/ordian/toml_edit/issues/130)

created time in 8 days

push eventgetditto/safer_ffi

Daniel Henry-Mantilla

commit sha 1b67865056cc65c9698d8f8b0f7da47bb85c4efe

Fix a typo in C#'s header generation for i64

view details

push time in 9 days

push eventgetditto/safer_ffi

Daniel Henry-Mantilla

commit sha c2c9c811b45e4dd520f6b165fa5894996faf973c

Add missing `ReprC` impl for `bool::CLayout`

view details

push time in 12 days

startedeupn/macrotest

started time in 15 days

push eventgetditto/safer_ffi

Daniel Henry-Mantilla

commit sha df6dd9d9c285c27815cd990491d0bd227f980757

[js] Make proper support for 64-bit ints through js `BigInt`s

view details

push time in 15 days

delete branch getditto/safer_ffi

delete branch : dhm/js/add_bigint_support

delete time in 15 days

PR merged getditto/safer_ffi

[js] Make proper support for 64-bit ints through js `BigInt`s enhancement

While we had stuff such as i64 : ReprNapi, this property was actually a (runtime) lie: for values beyond the ±Number.MAX_SAFE_INTEGER (2 ** 53 - 1) range, the Wasm side was silently yielding absurd value, and the Node.js / N-API side was throwing an error.

  • For Node.js, through N-API, proper support for the remaining range has been added through BigInts;
  • For Wasm, since, it doesn't support BigInts yet (it cannot interface with them), the out-of-range values cross the FFI boundary through a "stringified ABI", and support for the remaining range is this way achieved.
+337 -13

0 comment

6 changed files

danielhenrymantilla

pr closed time in 15 days

PR opened getditto/safer_ffi

[js] Make proper support for 64-bit ints through js `BigInt`s enhancement

While we had stuff such as i64 : ReprNapi, this property was actually a (runtime) lie: for values beyond the ±Number.MAX_SAFE_INTEGER (2 ** 53 - 1) range, the Wasm side was silently yielding absurd value, and the Node.js / N-API side was throwing an error.

  • For Node.js, through N-API, proper support for the remaining range has been added through BigInts;
  • For Wasm, since, it doesn't support BigInts yet (it cannot interface with them), the out-of-range values cross the FFI boundary through a "stringified ABI", and support for the remaining range is this way achieved.
+337 -13

0 comment

6 changed files

pr created time in 15 days

create barnchgetditto/safer_ffi

branch : dhm/js/add_bigint_support

created branch time in 15 days

issue commentrust-lang/rust

error[E0391]: cycle detected when computing type of async fn

Posting it here for the sake of visibility: in #87850 I showcase a minimal repro of actually the issue here: featuring an auto-trait constraint on an existential type triggers this error.

Diggsey

comment created time in 23 days

issue commentrust-lang/rust

Cycle when computing type of recursive opaque type

Potentially related:

use Send as SomeAutoTrait;
macro_rules! SomeExistential {() => ( impl Sized )}

fn foo() -> SomeExistential!() {
    // check if `typeof![foo()] : SomeAutoTrait`
    let _: &dyn SomeAutoTrait = &foo();
}
LeSeulArtichaut

comment created time in 23 days

pull request commentrust-lang/rfcs

RFC: Supertrait item shadowing

I believe the case of breakage because of name collision is good enough of a motivation to avoid the hard error on that very case; but there are a bunch of legitimate drawbacks with the shadowing as well:

  • T : Sub and T : Sub + Super behaving different does not feel right, at all. In that regard, saying that "the user of Sub may not be aware of Super" is actually factually wrong, or else we could have things like pub trait Sub : PrivateSuper. That is, a super trait is very much part of the API of the sub-trait. T : Sub thus means exactly the same as T : Sub + Super. So, if anything, the Sub + Super behavior ought not to fail either.
  • @Nemo157's concern still stands, as well as any other comments here where it wasn't clear which method was gonna be used. This makes me think that removing the hard error is necessary to avoid "silly breakage", I believe that instances of such method shadowing ought to trigger a warn-by-default lint about it. This would solve the silly breakage, while still disincentivizing any form of shadowing, as per the many pitfalls and surprising behaviors it entails.

On the other hand, there is a super silly case of actually-no-shadowing which I would love to see resolved with this attempt:

trait Trait {
    fn method(&self) where Self : Sized {}
}

impl dyn Trait + '_ {
    fn method(&self) {}
}

fn f(obj: &(dyn Trait + '_)) {
    obj.method(); // multiple applicable items in scope???
}
lcdr

comment created time in 23 days

fork danielhenrymantilla/sdleffler.github.io

Build a Jekyll blog in minutes, without touching the command line.

fork in a month

startedGoogleChromeLabs/wasm-bindgen-rayon

started time in a month

issue commentdanielhenrymantilla/visibility.rs

Compilation error

Hey, thanks for the report. I've initially been unable to reproduce this with the examples showcased in the documentation, but after searching for the error message a bit, I've found that you might have tried to write something like:

struct SomeStruct {
    #[cfg_attr(…, visibility::make(pub))]
    some_field: SomeType,
    …
}

In that case, indeed, Rust will complain since we are not allowed to put a procedural macro in that position.


Truth be told, I didn't think of this use case, but I can see how it might be useful. In order to support this use case, the best / least unergonomic API I can offer is the following:

#[visibility::with_field_granularity] // or some other name
struct SomeStruct {
    #[cfg_attr(…, visibility::make(pub))]
    some_field: SomeType,
    …
}

If that would suit you, I can implement this within the following weeks 🙂

sander2

comment created time in a month

push eventgetditto/safer_ffi

Daniel Henry-Mantilla

commit sha e1c64b5f9ab74aaca57adb979195334a64607966

Amend `executor` support to *require* the `fn` to be `async`

view details

push time in a month

delete branch getditto/safer_ffi

delete branch : fix/amend-async-executor-support

delete time in a month

PR merged getditto/safer_ffi

Reviewers
Amend `executor` support to *require* the `fn` to be `async`

This makes a few improvements w.r.t. the ffi_await! support to require, mainly, that the annotated function be an async fn, as suggested by @hamchapman

+99 -62

0 comment

4 changed files

danielhenrymantilla

pr closed time in a month

PR opened getditto/safer_ffi

Reviewers
Amend `executor` support to *require* the `fn` to be `async`

This makes a few improvements w.r.t. the ffi_await! support to require, mainly, that the annotated function be an async fn, as suggested by @hamchapman

+99 -62

0 comment

4 changed files

pr created time in a month

create barnchgetditto/safer_ffi

branch : fix/amend-async-executor-support

created branch time in a month

pull request commentjohnthagen/min-sized-rust

Replace Xargo with build-std

Hey @johnthagen this up-to-date guide is awesome! I've always found the tweaks for build-std to be a bit too scattered around and thus hard to grasp as a whole, so this is so welcome, thanks!!

johnthagen

comment created time in a month