profile
viewpoint
est31 FLOSS software. Past contributions include @minetest, @rust-lang, F-Droid.

est31/cargo-udeps 362

Find unused dependencies in Cargo.toml

est31/cargo-local-serve 25

Mirror of https://gitlab.com/est/cargo-local-serve | Serve a local, offline, clone of crates.io.

est31/csrp-gmp 5

Minimal C implementation of the Secure Remote Password protocol (version 6a)

est31/anvil 1

An anvil mod for minetest based on the cottages anvil

est31/balloc 1

Bounded allocation for Rust

est31/addr2line 0

A cross-platform `addr2line` clone written in Rust, using `gimli`

est31/alert-after 0

Get a desktop notification after a command finishes executing.

est31/amethyst 0

Data-oriented and data-driven game engine written in Rust

pull request commentrust-lang/rust

Backport LLVM apfloat commit to rustc_apfloat

Hmmm I think we should wait until this LLVM MR that @thomcc linked to is merged: https://reviews.llvm.org/D88238

Then we can backport that.

I'm not sure I agree with the suggestion to change usage sites, pointed out by @thomcc here, because the one they refer to mainly concerns floating point parsing of LLVM IR. LLVM has hexadecimal "raw" ways to specify float literals with some type inferrence, but in Rust you can only specify floats by their decimal fraction.

est31

comment created time in 26 minutes

issue commentrust-lang/rust

Miri floating point NaN conversion issue

@thomcc If the implementation shifts to the left on conversion to the wider format and back to the right on conversion to the narrower format, then the NaN payload will be the same. So I think that shifting is conformant with that rule of the standard. Otherwise hardware would be nonconformant as well. But maybe there's still some rule in the standard that LLVM afpfloat violates.

jodysankey

comment created time in 6 hours

pull request commentrust-lang/rust

Backport LLVM apfloat commit to rustc_apfloat

@thomcc it fixes the example at the top of #69532 . Maybe file a different issue for the general case? IDK.

est31

comment created time in 8 hours

issue commentrust-lang/rust

Miri floating point NaN conversion issue

Larger example that compares runtime and const eval (as of nightly master):

#![feature(test)]
#![feature(const_fn_transmute)]
extern crate test;
use test::black_box;

const fn make_nans() -> (f64, f64, f32, f32) {
    let nan1: f64 = unsafe { std::mem::transmute(0x7FF0_0201_0000_0001u64) };
    let nan2: f64 = unsafe { std::mem::transmute(0x7FF0_0000_0000_0001u64) };

    let nan1_32 = nan1 as f32;
    let nan2_32 = nan2 as f32;

    (nan1, nan2, nan1_32, nan2_32)
}

static NANS: (f64, f64, f32, f32) = make_nans();

fn main() {
    let (nan1, nan2, nan1_32, nan2_32) = NANS;

    assert!(nan1.is_nan());
    assert!(nan2.is_nan());

    println!("runtime eval:");
    {
        let nan1: f64 = black_box(f64::from_bits(0x7FF0_0201_0000_0001u64));
        let nan2: f64 = black_box(f64::from_bits(0x7FF0_0000_0000_0001u64));

        let nan1_32 = black_box(nan1 as f32);
        let nan2_32 = black_box(nan2 as f32);
            
        let nan1_32_again = black_box(nan1_32 as f64) as f32;
        let nan2_32_again = black_box(nan2_32 as f64) as f32;
        println!("{:0x} -> {:0x} {} -> {:0x} {}", nan1.to_bits(), nan1_32.to_bits(), nan1_32.is_nan(), nan1_32_again.to_bits(), nan1_32_again.is_nan());
        println!("{:0x} -> {:0x} {} -> {:0x} {}", nan2.to_bits(), nan2_32.to_bits(), nan2_32.is_nan(), nan2_32_again.to_bits(), nan2_32_again.is_nan());
    }
    println!("const eval:");
    println!("{:0x} -> {:0x} {}", nan1.to_bits(), nan1_32.to_bits(), nan2_32.is_nan());
    println!("{:0x} -> {:0x} {}", nan2.to_bits(), nan2_32.to_bits(), nan2_32.is_nan());
}

prints:

runtime eval:
7ff0020100000001 -> 7fc01008 true -> 7fc01008 true
7ff0000000000001 -> 7fc00000 true -> 7fc00000 true
const eval:
7ff0020100000001 -> 7f801008 false
7ff0000000000001 -> 7f800000 false

I guess it works on the hardware because there is an internal register set or something that says the number is NaN.

jodysankey

comment created time in 8 hours

issue commentrust-lang/rust

Miri floating point NaN conversion issue

@thomcc are you referring to this segment of your comment above?

It's also pretty wrong — IEEE wants you to truncate the payload here, not shift it out.

Can you quote the part of the IEEE 754 standard which mandates this? Or alternatively, come up with an example like the one at the top where there is a mismatch between what happens at runtime vs during miri evaluation?

Apparently hardware implementations shift out payloads as well:

#![feature(test)]
extern crate test;
use test::black_box;

fn main() {
    let nan1 = black_box(f64::from_bits(0x7FF0_0201_0000_0001u64));
    let nan2 = black_box(f64::from_bits(0x7FF0_0000_0000_0001u64));

    assert!(nan1.is_nan());
    assert!(nan2.is_nan());

    let nan1_32 = black_box(nan1 as f32);
    let nan2_32 = black_box(nan2 as f32);

    println!("{:0x} -> {:0x} {}", nan1.to_bits(), nan1_32.to_bits(), nan1_32.is_nan());
    println!("{:0x} -> {:0x} {}", nan2.to_bits(), nan2_32.to_bits(), nan1_32.is_nan());
}

prints:

7ff0020100000001 -> 7fc01008 true
7ff0000000000001 -> 7fc00000 true
jodysankey

comment created time in 8 hours

issue commentrust-lang/rust

Miri floating point NaN conversion issue

Done: #77368

jodysankey

comment created time in 9 hours

PR opened rust-lang/rust

Backport LLVM apfloat commit to rustc_apfloat

Backports LLVM commit: https://github.com/llvm/llvm-project/commit/e34bd1e0b03d20a506ada156d87e1b3a96d82fa2

Fixes #69532

+45 -0

0 comment

3 changed files

pr created time in 9 hours

create barnchest31/rust

branch : apfloat_fix

created branch time in 9 hours

pull request commentrust-lang/cargo

Correct mistake about supporting sub-makes and document CARGO_MAKEFLAGS

cc:

  • https://github.com/alexcrichton/jobserver-rs/issues/24
  • https://github.com/randombit/botan-rs/issues/22
  • https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/jobserver.20passthrough.20in.20build.2Ers
est31

comment created time in 2 days

PR opened rust-lang/cargo

Correct mistake about supporting sub-makes and document CARGO_MAKEFLAGS

Sub-makes are currently not supported as the jobserver crate only sets CARGO_MAKEFLAGS which GNU Make doesn't understand.

This might be reasonable as cargo overriding existing MAKEFLAGS variables would be weird, but also makes the statement in the reference false.

It's helpful for build script authors who want to invoke make to know how to get make subprocesses work with parallel builds.

+12 -4

0 comment

1 changed file

pr created time in 2 days

create barnchest31/cargo

branch : makeflags

created branch time in 2 days

issue commentrandombit/botan-rs

Single threaded botan-src build

Btw for reference this is how the cmake crate does it as well, it just copies over the env var: https://docs.rs/cmake/0.1.44/src/cmake/lib.rs.html#718

est31

comment created time in 2 days

issue commentalexcrichton/jobserver-rs

Client::configure can't be used to call e.g. make

I guess the main issue why @alexcrichton made 6ac9e7ca16fd792865cf16f6d2c8155dfbf299f3 is to allow outside MAKEFLAGS to get to sub-makes, which I agree is an important concern. However, I think some smart appending should be able to do it, e.g. one that parses the present MAKEFLAGS env var, removes any exant params that specify a jobserver, and re-adds the jobserver params of cargo.

glandium

comment created time in 2 days

PR opened randombit/botan-rs

Allow parallel make

Passes the right env variables to the sub-make so that it recognizes the cargo-provided jobserver.

Fixes #22

+17 -3

0 comment

1 changed file

pr created time in 2 days

issue commentrandombit/botan-rs

Single threaded botan-src build

Yeah so the issue is that cargo currently doesn't set MAKEFLAGS but only CARGO_MAKEFLAGS which make obviously has no idea what to do with. Thus to make it seems that there is no jobserver running at all, with the expectable consequences. https://github.com/alexcrichton/jobserver-rs/issues/24#issuecomment-700083933

est31

comment created time in 2 days

push eventest31/botan-rs

est31

commit sha 7ddba0ff85cad142a4c6464525ac52e082190c08

Also terminate if make failed

view details

push time in 2 days

push eventest31/botan-rs

est31

commit sha 7a76430cc12a98785b2834f3cbe8f2586f24059d

Terminate if configure.py failed

view details

est31

commit sha e17f8b446ea17201454aa1b42a156200c86b6796

Set MAKEFLAGS to enable parallel make support Cargo has a jobserver and passes it to build scripts by default, but while the jobserver can act as a make-compatible *client* (e.g. cargo build being called in a Makefile), it can't act as a make-compatible *server*, not unless we pass on MAKEFLAGS to sub-makes. TLDR: previously, the build was single-threaded, now it's multi threaded.

view details

push time in 2 days

issue commentalexcrichton/jobserver-rs

Client::configure can't be used to call e.g. make

The cargo docs added by commit https://github.com/rust-lang/cargo/commit/cbf25a9b0ae5ac6f5b6da96e645b7fa6a75dc245 aren't really accurate because of this issue:

* `NUM_JOBS` - the parallelism specified as the top-level parallelism. This can
               be useful to pass a `-j` parameter to a system like `make`. Note
               that care should be taken when interpreting this environment
               variable. For historical purposes this is still provided but
               recent versions of Cargo, for example, do not need to run `make
               -j` as it'll automatically happen. Cargo implements its own
               [jobserver] and will allow build scripts to inherit this
               information, so programs compatible with GNU make jobservers will
               already have appropriately configured parallelism.

The jobserver implemented/provided by cargo to build scripts is not compatible with make jobservers. So you need to absolutely use NUM_JOBS right now to pass on the -j param, or copy over the "CARGO_MAKEFLAGS" env var to "MAKEFLAGS" so that cargo understands it...

IMO cargo should just set MAKEFLAGS.

Right now it seems that the jobserver crate only provides compatibility with make when make is the master, but not when make is the slave and the tool that uses this crate is the master.

glandium

comment created time in 2 days

fork est31/botan-rs

:shrimp: Rust wrapper of Botan cryptography library

fork in 2 days

issue openedrandombit/botan-rs

Linking failure

There seems to be a linking failure on travis when I test the new botan feature to vendor sources.

Link to a failed build: https://travis-ci.com/github/est31/rcgen/jobs/391529962

Excerpt from the logs:

error: linking with `cc` failed: exit code: 1
[...]
note: /usr/bin/ld: /home/travis/build/est31/rcgen/target/debug/deps/libbotan_sys-59cd180e5db8bbbc.rlib(ffi.o): relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC

          /home/travis/build/est31/rcgen/target/debug/deps/libbotan_sys-59cd180e5db8bbbc.rlib: error adding symbols: Bad value

          collect2: error: ld returned 1 exit status

It works locally on my machine.

created time in 3 days

issue commentrandombit/botan-rs

Single threaded botan-sys build

cc #15 @breard-r

est31

comment created time in 3 days

issue openedrandombit/botan-rs

Single threaded botan-sys build

If I enable the vendored feature, the build takes a long time because it's single threaded.

I'm not sure how to enable parallel make. make -j $NUM_JOBS is not the solution but I'm not sure how one can do jobserver passthrough.

created time in 3 days

push eventest31/rcgen

est31

commit sha 284f1a2482a5a1a6e1a0dfbd3ab323318982874c

Add botan based test Adds a test that botan successfully accepts our generated certs.

view details

push time in 3 days

push eventest31/mimas

est31

commit sha dd5e88d3acc0aa4f220fd4f9e07511ee7d22592e

Fix a regression caused by prior commit Fixes simple mistake introduced by 00fe7d310c9f7d40eaac4396f841675dde48f489 breaking movement of items from/to chests

view details

est31

commit sha 83acf29f5a0f01b0821d4cc9084bc6538c0e308f

Do crafting on the server This moves another functionality that made the client set the inventory unilaterally to the server.

view details

est31

commit sha f2f7512581344509dcbaae1033ada091a1c938e7

Move inventory selection to the server Now there isn't anything in the way of removing ClientToServerMsg::SetInventory any more.

view details

est31

commit sha 11acf567c822f255c58e7ba3e4efd76b9b02e6a5

Remove ClientToServerMsg::SetInventory for good Now clients can't just make up items out of thin air any more, or do similarly bad things.

view details

push time in 4 days

push eventest31/mimas

est31

commit sha b36cfa2009e385af4f9ce150db6200a920425fc1

Change todo to unreachable as crafting doesn't get here

view details

est31

commit sha 427efcb69910335e85fe4d88de902b782cb3955a

Update the inventory if needed

view details

push time in 4 days

push eventest31/mimas

est31

commit sha df17d25e9cfd7337bdc5bfb191b23888e142e603

Add KvWaitingPlayer This simplifies adding new data like mode (flying vs non-flying) etc

view details

est31

commit sha d6f031994ae0139ebeb6482c339665044a4e5e44

Use entry API to save some pwfk lookups We save the final lookup of pwfk by using an entry.

view details

est31

commit sha 3a72c32389ed1800fa2babc10520012b175ff1fc

Manage a crafting inventory on the server It's not used yet for applying movement/craft commands, which comes later.

view details

est31

commit sha 00fe7d310c9f7d40eaac4396f841675dde48f489

Send movement commands containing craft inv This means that craft inventory is now properly being stored and loaded.

view details

push time in 4 days

push eventest31/mimas

est31

commit sha 1f210cf2a03fa62f5e42ad9212b7f020105ce66f

Send a InventorySwap message if possible Currently the server doesn't store a crafting inventory. But if we only move inside the player inventory, we can already send InventorySwap commands to the server.

view details

push time in 4 days

issue commentrust-lang/rust

allow_internal_unstable silently ingores typos in feature names

@bugadani there are lib features and lang features. Only the second type is hardcoded in the compiler. For the first type, you need to check whether it's been declared in one of the upstream crates.

bugadani

comment created time in 4 days

Pull request review commentalexcrichton/openssl-src-rs

Add upstream patch to allow building on aarch64-apple-darwin

 fn apply_patches(target: &str, inner: &Path) {         .unwrap(); } +fn apply_patches_aarch64_apple_darwin(target: &str, inner: &Path) {+    if target != "aarch64-apple-darwin" {+        return;+    }++    // Apply build system changes to allow configuring and building+    // for Apple's ARM64 platform.+    // https://github.com/openssl/openssl/pull/12369++    let mut buf = String::new();+    let path = inner.join("Configurations/10-main.conf");+    File::open(&path).unwrap().read_to_string(&mut buf).unwrap();++    assert!(+        !buf.contains("darwin64-arm64-cc"),+        "{} already contains instructions for aarch64-apple-darwin",+        path.display(),+    );++    const PATCH: &'static str = r#"

'static has not been required on constants since 1.17.0

shepmaster

comment created time in 4 days

PullRequestReviewEvent

issue commentrust-lang/rust

Rebranding Rust compiler is extremely unpractical -- can't easily exercise freedom 3

The trademarks rust and cargo also appear in many places in the interface, like through Cargo.toml or rustc and cargo binary names, or in RUST_BACKTRACE, various env vars that cargo sets etc.

IMO once a foundation is set up, the trademark policy should be changed to be more tolerant towards this.

mimi89999

comment created time in 4 days

push eventest31/mimas

est31

commit sha 7e84be92dbd7d3792ecbbcc2ec061e0219dc78ca

Only send SetInventory to server if there is no swap command

view details

est31

commit sha e940d529f83a923e1a35e149afdea0c68986b5ed

Initialize the inventory at block placement if needed Previously, the server didn't initialize the inventory of a chest and thus the server wouldn't accept any movement commands from the client into the inventory, rendering any newly placed chests unusable.

view details

push time in 4 days

pull request commentNixOS/nixpkgs

[20.09] Plasma 5: Revert to Qt 5.12

Check the table here, it lists 5.12 and 5.13: https://community.kde.org/Schedules/Plasma_5#Support_status_by_Release_Series

ttuegel

comment created time in 4 days

pull request commentNixOS/nixpkgs

[20.09] Plasma 5: Revert to Qt 5.12

Qt 5.13 is supported as well, and it would fix some failing builds like akonadi or digikam (#98879) and might help with #98536 too.

ttuegel

comment created time in 4 days

push eventest31/mimas

est31

commit sha 7eb323f9cf46f294bce3f00a334ee54efc9567dc

Smoother jumping Performs jumping along a parabolic trajectory, so that top jumping speed isn't reached right away. Also makes it simpler to specify constants pertaining to the jump like height or duration of the jump animation

view details

push time in 4 days

pull request commentrust-lang/rust

Remove unused #[allow(...)] statements from compiler/

Btw I'm not sure about the lints in compiler/rustc_data_structures/src/flock.rs either, but it has three different implementations for three different platforms, so maybe it only fires on one platform, so I just kept it where it is.

est31

comment created time in 5 days

push eventest31/rust

Vali Schneider

commit sha 459969f88ff95c94b7b34043a7f0e13de91de4f8

added restriction lint that prohibits the usage of unimplemented, unreachable or panic in a function of type result or option

view details

Vali Schneider

commit sha ceab1a9167655eba9f9556f8766f8702e49dfef3

removed unnecessary comment

view details

Vali Schneider

commit sha 8462cce96081b87eba7a5bc89130a1a09fe1f6d0

edited documentation

view details

Vali Schneider

commit sha b2d8ca9a766703469178ea37d4d46067bb6fa926

ran cargo dev update lints

view details

Vali Schneider

commit sha b006522393a3c3c2656e1ccdfbb0076ff1bd7e99

added lint for todo and removed option

view details

Vali Schneider

commit sha a424a2c1676a29c147252873037e8943d54941d3

changed check_impl_item to check_fn and added a few more test cases

view details

Vali Schneider

commit sha 73a3288282e733bfc5893e9920d29f1de5a21591

uncommented fn

view details

Erik Desjardins

commit sha d3b9ece4c0028ff7e36e34df2d2b26366f9c0648

add tests related to tuple scalar layout with ZST in last field

view details

Erik Desjardins

commit sha e5d85f917b8965a5e62513c17cbb887366b152bc

allow reordering of the last field of a MaybeUnsized struct if it's a ZST

view details

Erik Desjardins

commit sha e9bc3ddb073f2261ac46832d985efe8db863ed6a

test that we do not change the offset of ZST tuple fields when unsizing

view details

Erik Desjardins

commit sha 68217c9e0f1269d29b4c1c72d08fb1b95bf441cd

ignore zst offsets instead

view details

Erik Desjardins

commit sha 6fc1d8bc13124bb134d7ab54e56237821a55912e

add codegen test

view details

Erik Desjardins

commit sha 24e0913e37cc6fc363b37d13bf519db212f175a2

handle vector layout

view details

Vali Schneider

commit sha f9fcbbea03edb735c22311522b55d7b854bd6ac0

fixed bug

view details

Ricky

commit sha e49a29933be3bd988ccb75b053f480d9c99a7ff5

Working map_err_ignore lint

view details

Ricky

commit sha 202a80c927412a548180eca5990ee764d76ed643

Added tests for map_err, ignored map_err lint on drop_ref tests

view details

Ricky

commit sha 337729137bdec31b55665653ef0cf7dc124b0eaa

Ran cargo dev update_lints

view details

Ricky

commit sha 2387f68e437bf2ff5f117f63936257ce64052cfa

Removed map_err suggestion in lint, and updated lint documentation example

view details

Jane Lusby

commit sha c31d4730b0d40c62934839405d0c25e2ffa3fad1

update example to be more idiomatic

view details

Ricky

commit sha 4f1c4a99d4d98f1acea3c9c7cc55355aa46119aa

Fixed typo in lint and test

view details

push time in 5 days

PR opened rust-lang/rust

Remove unused #[allow(...)] statements from compiler/
+2 -28

0 comment

21 changed files

pr created time in 5 days

push eventest31/rust

Vali Schneider

commit sha 459969f88ff95c94b7b34043a7f0e13de91de4f8

added restriction lint that prohibits the usage of unimplemented, unreachable or panic in a function of type result or option

view details

Vali Schneider

commit sha ceab1a9167655eba9f9556f8766f8702e49dfef3

removed unnecessary comment

view details

Vali Schneider

commit sha 8462cce96081b87eba7a5bc89130a1a09fe1f6d0

edited documentation

view details

Vali Schneider

commit sha b2d8ca9a766703469178ea37d4d46067bb6fa926

ran cargo dev update lints

view details

Vali Schneider

commit sha b006522393a3c3c2656e1ccdfbb0076ff1bd7e99

added lint for todo and removed option

view details

Vali Schneider

commit sha a424a2c1676a29c147252873037e8943d54941d3

changed check_impl_item to check_fn and added a few more test cases

view details

Vali Schneider

commit sha 73a3288282e733bfc5893e9920d29f1de5a21591

uncommented fn

view details

Erik Desjardins

commit sha d3b9ece4c0028ff7e36e34df2d2b26366f9c0648

add tests related to tuple scalar layout with ZST in last field

view details

Erik Desjardins

commit sha e5d85f917b8965a5e62513c17cbb887366b152bc

allow reordering of the last field of a MaybeUnsized struct if it's a ZST

view details

Erik Desjardins

commit sha e9bc3ddb073f2261ac46832d985efe8db863ed6a

test that we do not change the offset of ZST tuple fields when unsizing

view details

Erik Desjardins

commit sha 68217c9e0f1269d29b4c1c72d08fb1b95bf441cd

ignore zst offsets instead

view details

Erik Desjardins

commit sha 6fc1d8bc13124bb134d7ab54e56237821a55912e

add codegen test

view details

Erik Desjardins

commit sha 24e0913e37cc6fc363b37d13bf519db212f175a2

handle vector layout

view details

Vali Schneider

commit sha f9fcbbea03edb735c22311522b55d7b854bd6ac0

fixed bug

view details

Ricky

commit sha e49a29933be3bd988ccb75b053f480d9c99a7ff5

Working map_err_ignore lint

view details

Ricky

commit sha 202a80c927412a548180eca5990ee764d76ed643

Added tests for map_err, ignored map_err lint on drop_ref tests

view details

Ricky

commit sha 337729137bdec31b55665653ef0cf7dc124b0eaa

Ran cargo dev update_lints

view details

Ricky

commit sha 2387f68e437bf2ff5f117f63936257ce64052cfa

Removed map_err suggestion in lint, and updated lint documentation example

view details

Jane Lusby

commit sha c31d4730b0d40c62934839405d0c25e2ffa3fad1

update example to be more idiomatic

view details

Ricky

commit sha 4f1c4a99d4d98f1acea3c9c7cc55355aa46119aa

Fixed typo in lint and test

view details

push time in 5 days

create barnchest31/rust

branch : remove_unused_allow

created branch time in 5 days

pull request commentserde-rs/serde

Add "const-generics" feature

it is just a matter of bumping the minimal compiler version

serde's maintainer has gone to great lengths to avoid bumping the MSRV of serde proper. You could try moving the offending code into a separate module in a separate file, and put the mod foo statement behind a cfg. This should make sure the compiler never encounters it when the feature is turned off.

c410-f3r

comment created time in 5 days

push eventest31/mimas

est31

commit sha 6e71a1058f1b8ae079e0fbdbde0f9788cee1ca1f

Return the executed command from check_event

view details

push time in 5 days

push eventest31/rust

Marcel Hellwig

commit sha 00d537dcd03f9ff5ebdf8b86e039dbdb0a7f850c

deny(unsafe_op_in_unsafe_fn) in libstd/path.rs

view details

Ivan Tham

commit sha c5975e9b6c5781b3b7300b7921c14b060086e1c1

Reduce duplicate in liballoc reserve error handling

view details

Federico Ponzi

commit sha 27c90b881df93b53fd3f24dcbfed116379c2fc69

initial implementation of OpenOptions to c_int

view details

Federico Ponzi

commit sha eb3906be4ad375cc6b83cd6a6e0116817db22575

Fix typo get openoptions function name Co-authored-by: Ivan Tham <pickfire@riseup.net>

view details

David Wood

commit sha 0f2bd56b29857453835e47abbe96a80b175632d1

lint/ty: move fns to avoid abstraction violation This commit moves `transparent_newtype_field` and `is_zst` to `LateContext` where they are used, rather than being on the `VariantDef` and `TyS` types. Signed-off-by: David Wood <david@davidtw.co>

view details

CDirkx

commit sha 518f1ccb728aa03665e51710c12973a74cc98df5

Stabilize some Result methods as const Stabilize the following methods of `Result` as const: - `is_ok` - `is_err` - `as_ref` Possible because of stabilization of #49146 (Allow if and match in constants).

view details

Federico Ponzi

commit sha 1bc0627607262cc60a7692b16e205f30fc88b89f

Add as_flag function to the OpenOptionsExt struct

view details

Federico Ponzi

commit sha 2c9e27b759a9e9feeb943fb855e32d7383d1dcc6

Merge branch 'convert-openoptions-cint' of github.com:FedericoPonzi/rust into convert-openoptions-cint

view details

Federico Ponzi

commit sha 7c1e5c1dcd25c945f619eda289f639dbe2b002da

Update OpenOptions::as_flags docs, and minor styling

view details

Federico Ponzi

commit sha 321b680fe66d1be04cd67fac75ff7f148fd117fe

Update docs of OpenOptions::as_flags

view details

Federico Ponzi

commit sha 28db5214d2c48e7a58cf79b9e272097260910a33

More implementations of Write for immutable refs Fixes #73836

view details

Christiaan Dirkx

commit sha 787b2707a77fa1a98f512a4905662a1a16daf13c

Move const tests for `Result` to `library\core` Part of #76268

view details

Scott McMurray

commit sha 6092828d1f432bb313818e7cfab961c0e494f69e

Add `[T; N]: TryFrom<Vec<T>>` This is very similar to the existing `Box<[T; N]>: TryFrom<Box<[T]>>`, but allows avoiding the `shrink_to_fit` if you have a vector and not a boxed slice.

view details

David Wood

commit sha f8376b59d1391a5191a561c44067355f1a99c7c0

shim: monomorphic `FnPtrShim`s during construction This commit adjusts MIR shim construction so that substitutions are applied to function pointer shims during construction, rather than during codegen (as determined by `substs_for_mir_body`) - as substitutions will no longer occur during codegen, function pointer shims can now be polymorphic without incurring double substitutions. Signed-off-by: David Wood <david@davidtw.co>

view details

kadmin

commit sha 6cb671628393e292d5e68e6367f80488ace46532

Add test for checking if-let or-patterns

view details

scottmcm

commit sha 2c8a4c8f73e8b36e72b15e7f97ef29ad36c15e17

Nightly is currently 1.48

view details

Ivan Tham

commit sha 685f04220ee584f00f60e5ff9d7aca16351c5399

Clean up vec benches bench_in_place style

view details

scottmcm

commit sha 3d89ee9586354e736cfe4a472d8aaa507d10f77c

Typo fix Thanks, Amanieu Co-authored-by: Amanieu d'Antras <amanieu@gmail.com>

view details

Ralf Jung

commit sha caeb5544ecd9dba4d67b68b8c1b32d8132c6d5f2

do not inline black_box when building for Miri

view details

Ralf Jung

commit sha 4b5cd544d1268df8f95424a7dc77ce6c852bac56

use black_box instead of local optimziation barriers in const tests where possible

view details

push time in 5 days

push eventest31/mimas

est31

commit sha 61ba3dd1c527891a984ffd4518bd5e6cfa01eab1

Add a check_event function like there is check_movement already This moves much of the state update code out of the render loop.

view details

push time in 5 days

issue openedest31/mimas

Adopt an ECS

I think mimas has grown to a point where using an ECS isn't overengineering any more.

created time in 5 days

push eventest31/mimas

est31

commit sha b2ab991cfe1185eb5ba815cc1042507a0e9229fd

Replace StrErr with anyhow's Result in mimas-server

view details

est31

commit sha 9412abe8cff046b0b20bf0fb1555c686cd1ab51c

Replace last use of StrErr and remove it completely

view details

push time in 5 days

push eventest31/mimas

est31

commit sha 14dfdc2052b00f2efaecc6d5c84b21926ef2e560

Fix style in assets.rs

view details

est31

commit sha 00a95c21f931bec3258de1c76bb234822d98dd94

Use anyhow::Result in mimas-server's main.rs and mimas crates

view details

push time in 5 days

push eventest31/mimas

est31

commit sha 3a00c2ffba6fa171b6a3db8b734aa5339149dec6

Migrate from StrErr to anyhow Anyhow has become a popular error handling library, and fundamentally it embraces the design choices currently closest to the needs of mimas. So we switch to it. Still calls the error type StrErr but that's mainly to make the diff smaller and fixing this is left to futher work.

view details

push time in 5 days

push eventest31/mimas

est31

commit sha 9e4e368ed60a98e2279acf9e2efc0ccf5f41e54c

Return StrErr in get_id Unified error type :)

view details

est31

commit sha b2d89aaf5c5cde63587da0bce352e058b8cedb60

Perform rename of constants: MEHLON -> MIMAS Missed them in the original rename :)

view details

push time in 5 days

push eventest31/mimas

est31

commit sha f261e88922d575359b518f1a63cfb7d203eaa164

Reorder imports in server.rs

view details

push time in 5 days

push eventest31/mimas

est31

commit sha 4697d51f459717e62cacc08fac920d6e7d7ab843

Move StrErr to lib.rs

view details

est31

commit sha 68b5405e5065adeb6a98f8a32439c8c91eef4169

Remove blanket export in favour of pub use

view details

push time in 5 days

push eventest31/mimas

est31

commit sha 493830666bd443a654ff88ff52f2ee0a5c809f69

Move most of the server implementation to mimas-server/server.rs

view details

push time in 5 days

pull request commentrust-lang/rfcs

Stable Rustdoc URLs

This RFC only concerns the URL components relative to the crate root of the currently documented crate, right? Because currently there are a bunch of issues with cargo doc's choice of crate URLs, like e.g. https://github.com/rust-lang/rust/issues/56169 . I presume it's not the intent to lock in the current behaviour?

jyn514

comment created time in 5 days

push eventest31/mimas

est31

commit sha d44ba916e5614dafe63522f1a4c92f3891fdce93

Add Server::tick function and move the server loop code into it This saves an indentation level

view details

est31

commit sha 7741cead359442fa85b6fea4aeaa291756fad069

The exit variable is never written to so remove it

view details

est31

commit sha be83b6d311324a0ee8f8be088ef0e3a88f596122

Move InventorySwap handling code into dedicated function Saves some indentation levels and reduces the size of the tick function

view details

est31

commit sha 6ce012257f3b1abd58e744470d36e8871f09509c

Move dig handling into separate function

view details

push time in 6 days

PR closed glium/glium

Add lots of documentation and remove #[allow(missing_docs)] from lots of files

This, if merged, would add significant amounts of documentation for previously undocumented items. It would also completely remove #[allow(missing_docs)] from a lot of files. Also, it clarifies that support for compute shaders does exist in OpenGL by fixing one FIXME comment.

The documentation in lots of places isn't ideal, but from what I understand it's accurate. This is a somewhat significant step towards having full and in-depth documentation.

+233 -32

3 comments

6 changed files

LiamTheProgrammer

pr closed time in 6 days

pull request commentglium/glium

Add lots of documentation and remove #[allow(missing_docs)] from lots of files

Yeah the /*do foo*/ foo() type doc comments are part of why I'm so reluctant about merging this. Documentation improvements in general are welcome, but I agree that such class of changes don't constitute as improvements. Thus I'll close this for now.

LiamTheProgrammer

comment created time in 6 days

push eventest31/mimas

est31

commit sha a73dcea2508109afea4b749cc4c749f41ab866de

We already send a chunk update The chunk update is yielded from the on change function on the map.

view details

push time in 6 days

push eventest31/mimas

est31

commit sha 849a87347dc3405f5a2318445229c6ea2a0e9e7d

Always use only one invocation of merge_or_move It's easily visible how this improves/simplifies the code.

view details

push time in 6 days

push eventest31/mimas

est31

commit sha 45d6561fb7419e1cc76481bcb76b7ad47f4764bd

Remove SetMetadata as it's now not unused

view details

push time in 6 days

push eventest31/mimas

est31

commit sha 08d3c4846cb5b65bcb14955409c18d09a2235137

Add docs to PlaceBlock client to server msg

view details

est31

commit sha c9d4b94448c930539553436e711a7f50790cb14f

Add an InventorySwap command to the server

view details

est31

commit sha ff269b9ac1166e3a0bb8ecb4b76c55d6303a6cf5

Move merge_or_swap and move_n_if_possible into free functions

view details

est31

commit sha eccaf2aa2708488764c29f58f006a9c3389a4e18

Introduce InvRef trait and use it in the movement functions

view details

est31

commit sha 3de29dcdab365276170e001101cd0a677b7988db

Fill inventory movement client to server msg with life It's a bit complicated due to having to convince Rust's proof system that everything is sound, but I guess we have to live with it :).

view details

est31

commit sha efa4cd33f4fd8f86a263c83852783a75c228e2b7

Add SwapCommand to ui.rs but (for now) do nothing about it

view details

est31

commit sha fc22960c035d4364288e417bafeab991fc0a6350

Make the client send InventorySwap commands when it concerns chests Currently hitting a BorrowMut error when moving stuff from/to chests, but not when moving it inside the inventory, or inside the chest.

view details

est31

commit sha 56f070451211f99a44a3978f0df12cb57a35f1be

Store the inventory inside a local variable instead of borrowing If we move stuff between chests and the inventory, we will call the set function for the map chunk metadata handle while the borrow is active. But the metadata change triggers the on change function of the map, which sends the metadata change to all players. This change fixes an already borrowed crash when moving stuff between chests and the player inventory. Thus, the new inventory movement logic is now usable as well as used!

view details

push time in 6 days

pull request commentrust-lang/rust

Remove TrustedLen requirement from BuilderMethods::switch

I don't think that the fact that TrustedLen is underspecified means we should start removing it from internal APIs.

Thankfully this PR has more justification than only that, in that TrustedLen is not required. What would you say if instead of an unused TrustedLen bound, there were an unused Clone bound?

Also note that this PR doesn't propose removal of all uses of TrustedLen in the compiler. In the other place where it's used, one I can't replace it this easily with ExactSizeIterator because latter doesn't support chaining. In this instance though, it's dead weight. Nobody needs the bound and it only confuses readers. The fact that the original reviewer would prefer review by a TrustedLen expert further proves my point :).

I'll r? @petrochenkov , maybe they are more amenable to simplification PRs :).

est31

comment created time in 6 days

pull request commentrust-lang/rust

Remove TrustedLen requirement from BuilderMethods::switch

This signature allows them to assume len is accurate in unsafe code.

I wouldn't agree with that. #37572 lists the question what TrustedLen means for ExactSizeIterator as open question. The only thing that implementors can assume is that size_hint is accurate. The default ExactSizeIterator impl bases on that but there is no guarantee that there's no special sauce here :).

est31

comment created time in 6 days

pull request commentrust-lang/rust

Remove TrustedLen requirement from BuilderMethods::switch

Admittedly I wasn't aware of this guarantee that the trait gave, but I was lucky that it's not applicable :).

Yeah, neither cranelift codegen nor gcc-rust implement the trait, only the in-tree llvm codegen. Even if they used it, the API provided is unstable anyways, and it's not really hard to update. I had to spend a lot of time reading github discussions on what TrustedLen means and I think the new API is much more easy to handle because implementors don't have this mental burden of having to understand a poorly documented and niche feature of the language (which also has still unresolved questions in its tracking issue).

Btw the commit that introduced the TrustedLen was a similar cleanup commit: 35705dee7eb10783280e0be92aedfc187e019dd

est31

comment created time in 6 days

pull request commentrust-lang/rust

Remove TrustedLen requirement from BuilderMethods::switch

It's not UB if the number is wrong. According to docs, it's only a hint for allocation:

Create a switch instruction with the specified value, default dest, and with a hint for the number of cases that will be added (for efficient allocation).

est31

comment created time in 6 days

PR opened rust-lang/rust

Remove TrustedLen requirement from BuilderMethods::switch

The main use case of TrustedLen is allowing APIs to specialize on it, but no use of it uses that specialization. Instead, only the .len() function provided by ExactSizeIterator is used, which is already required to be accurate.

Thus, the TrustedLen requirement on BuilderMethods::switch is redundant.

+2 -6

0 comment

4 changed files

pr created time in 6 days

create barnchest31/rust

branch : swich_len_already_trusted

created branch time in 6 days

issue commentrust-lang/rust

Use dynamic linking and download LLVM from CI for rustc across platforms

Switching to static linking would preclude any of the improvements from #76349, so it would be better to use dynamic linking instead

In which way is static linking making downloaded LLVM impossible?

jyn514

comment created time in 7 days

pull request commentrust-lang/rust

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

@jyn514 idk it seems to run this command:

  Step 9/9 : ENV SCRIPT python3 ../x.py test --stage 0 --config /config/nopt-std-config.toml library/std   && python3 ../x.py --stage 2 test

I was just checking what my the rollup my PR was in was up to and found this error :).

nathanwhit

comment created time in 8 days

issue commentrust-lang/cargo

cargo vendor should support OS support restrictions

@wbl Cargo can't really "parse" lockfiles in that it uses them as sole source of information for compiling a crate graph. It always needs a second source of information to compare a lockfile to. In fact, the internal algorithm uses the second source as main method to determine a resolved graph, and uses the lockfile only to fill in the gaps (like concrete versions). In the general use case, comparing the lockfile to the second source makes total sense because cargo needs to be aware if you e.g. changed your Cargo.toml to increase some semver version. Then Cargo needs to be able to react and possibly update the version. And in the general use case, the index is already available so it's no big deal. But for cargo vendor, no index is available, so Cargo needs the full sources as that main source to build the crate graph.

Of course for vendored use cases, this design choice seems wrong but I guess nobody has done the work of lockfiles.

wbl

comment created time in 8 days

pull request commentrust-lang/rust

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

Doctest failure in rollup #77082:

---- src/ffi/c_str.rs - ffi::c_str::CStr::as_ptr (line 1269) stdout ----
error: unknown lint: `temporary_cstring_as_ptr`
 --> src/ffi/c_str.rs:1269:27
  |
3 | #![allow(unused_must_use, temporary_cstring_as_ptr)]
  |                           ^^^^^^^^^^^^^^^^^^^^^^^^
  |
note: the lint level is defined here
 --> src/ffi/c_str.rs:1267:9
  |
1 | #![deny(warnings)]
  |         ^^^^^^^^
  = note: `#[deny(unknown_lints)]` implied by `#[deny(warnings)]`

nathanwhit

comment created time in 8 days

issue commentrust-lang/cargo

Support for vendoring on a single platform

An alternative to solve this issue with platform specific lockfiles would be to generate empty stubs for crates left out from the build, just with enough information for cargo to make sense of the passed lockfile.

To give a different way of looking at this proposal: this method is already implemented for unvendored crates.io crates in the form of the index. Stub Cargo.tomls would be nothing else than extracting those parts of the index that are relevant so that the vendor setting doesn't need to use the index. Only the format would be different from the index's json format and use Cargo.toml instead.

The advantage: it would only require functional changes in cargo-vendor but not cargo itself, and especially not require complicated resolver changes.

I think from a practical standpoint, this approach could solve the main objections of people, weird files* included by dependencies and the size bloat. It might seem like a hack at first sight, but as I've outlined above, the same thing is done with the index already.

*: Note that I wouldn't be unhappy if raw dylibs finally got implemented so that winapi can drop those files

nipunn1313

comment created time in 8 days

issue commentrust-lang/cargo

cargo vendor should support OS support restrictions

Dupe of #7058

wbl

comment created time in 8 days

issue closedest31/mimas

Rendered inventory items

closed time in 8 days

est31

issue commentest31/mimas

Rendered inventory items

Implemented by 776515668c080696cfdb1717a66423b6b3f348fb, d53a1d2d1be623f693c3c6ff3dc82c06dc1a6a4d, 79230f19dff78a2149f6993c5576b4940cf382c5, 03b52e8d27077ed4a4b93d9d5be66048a9fd2e6b

est31

comment created time in 8 days

issue openedest31/mimas

More client security

Currently, clients can freely move items around, set blocks, etc. It would be great if clients did local prediction but the server would keep its own log of things to make sure that hacked clients can't do everything they want.

  • [ ] Only allow placing blocks that are in the inventory: 0b2b981525e62c4b4213e302b65006584e1a511c
  • [ ] Do inventory movement on the server, both for chests and for player inventories
  • [ ] Do crafting on the server
  • [ ] Velocity checking
  • [ ] Location checking, verifying that the player isn't inside walls or something

created time in 8 days

PR opened rust-lang/rust

Add #[track_caller] to more panicking Cell functions

Continuation of #74526

Adds the #[track_caller] attribute to almost all panicking Cell functions. The ones that borrow two Cells in their function body are spared, because the panic location helps pinpoint which of the two borrows failed. You'd need to have full debuginfo and backtraces enabled together with column info in order to be able to discern the cases. Column info in debuginfo is only available on non-Windows platforms.

+3 -0

0 comment

1 changed file

pr created time in 8 days

push eventest31/rust

est31

commit sha 05c3a2b07dc66fabc874181ce1eebea192cb4b56

Add #[track_caller] to more panicking Cell functions Continuation of #74526 Adds the #[track_caller] attribute to almost all panicking Cell functions. The ones that borrow two Cells in their function body are spared, because the panic location helps pinpoint which of the two borrows failed. You'd need to have full debuginfo and backtraces enabled together with column info in order to be able to discern the cases. Column info is only available on non-Windows platforms.

view details

push time in 8 days

create barnchest31/rust

branch : more_track_caller

created branch time in 8 days

Pull request review commentrust-lang/rust

more tiny clippy cleanups

 impl<'mir, 'tcx: 'mir, M: Machine<'mir, 'tcx>> InterpCx<'mir, 'tcx, M> {         let res = match bin_op {             Eq => l == r,             Ne => l != r,-            Lt => l < r,+            Lt => !l & r, // equals l < r

Shouldn't there be an allow here instead of the new code?

  1. regardless whether you think whether l < r is clearer than !l & r or not, this specific piece of code concerns the implementation of l < r in the constant evaluator. I think it's most clear to implement l < r via l < r instead via something that clippy thinks is better.

  2. If l < r should be replaced with not and and operations, why not l <= r as well?

The bool comparison lint description in clippy's docs makes sense, x < true is code smell. But x < y in an implementation of x < y is IMO not.

matthiaskrgr

comment created time in 8 days

PullRequestReviewEvent

push eventest31/mimas

est31

commit sha 0b2b981525e62c4b4213e302b65006584e1a511c

Do the inventory calculations for block placing on the server This works towards the goal of clients only being used for prediction, and the main game logic being on the server, so that hacked clients can't magically make blocks appear.

view details

push time in 8 days

push eventest31/mimas

est31

commit sha 56d504a8fe44bf95db970a84a47fa6578158a351

Rename SetBlock to PlaceBlock

view details

push time in 9 days

pull request commentrust-lang/rust

DroplessArena: Allocate objects from the end of memory chunk

@Mark-Simulacrum another important point is that TypedArena always deallocates objects starting from the start. But the deallocation code for u8 is thankfully a no op, and not called anyways (clear is not called), so it's no big deal.

tmiasko

comment created time in 9 days

pull request commentrust-lang/rust

Add `x.py setup`

In my personal workflow, I cp config.toml.example to config.toml and then adjust the settings I want adjusted. That way their documentation is next to them and I always know what they do. I regularly re-do this step so that it doesn't bitrot too much as new options are being added/old ones removed. But maybe it is smarter to just have that single line instead plus 1 comment.

jyn514

comment created time in 9 days

PR opened rust-lang/rust

Dogfood total_cmp in the test crate
+2 -17

0 comment

2 changed files

pr created time in 10 days

push eventest31/rust

est31

commit sha 9172e277f864205daaf8fde64868d833cc6e7eb2

Dogfood total_cmp in the test crate

view details

push time in 10 days

create barnchest31/rust

branch : dogfood_total_cmp

created branch time in 10 days

pull request commentrust-lang/rust

Remove unused static_assert macro

Also there are crates now that offer a much larger choice of static assert macros: https://crates.io/crates/static_assertions

est31

comment created time in 10 days

pull request commentrust-lang/rust

Remove unused static_assert macro

The macro isn't really that hard to replicate. And given the size of the rustc codebase (0.4 million lines!), if there's any need to use it, it would probably already have been used somewhere, if it were that needed/valuable. static_assert_size on the other hand is used 25 times, and {debug_,}assert! 1393 times inside compiler/.

est31

comment created time in 10 days

issue commentrust-lang/rust-clippy

Manual Duration::{as_nanos,as_milis,as_secs_f64,as_secs_f32} implementation

Example encounters in the wild:

  • https://github.com/rust-lang/cargo/pull/8721

  • https://github.com/rust-lang/rust/pull/76958

est31

comment created time in 10 days

pull request commentrust-lang/rust

Remove unused feature gates from library/ crates

@bors r+ r=lcnr

est31

comment created time in 11 days

PR opened rust-lang/rust

Remove unused static_assert macro
+0 -12

0 comment

1 changed file

pr created time in 11 days

create barnchest31/rust

branch : remove_static_assert

created branch time in 11 days

PR opened rust-lang/rust

Use const_cstr macro in consts.rs
+3 -4

0 comment

1 changed file

pr created time in 11 days

create barnchest31/rust

branch : const_cstr

created branch time in 11 days

issue openedrust-lang/rust-clippy

Manual Duration::{as_nanos,as_milis,as_secs_f64,as_secs_f32} implementation

What it does

Recognize cases of manual re-implementation of the builtin as_nanos and as_secs_f64 and as_secs_f32 functions on Duration.

Categories

  • Kind: complexity, sometimes also correctness

Drawbacks

MSRV issues, implementing the suggestion might increase the MSRV.

Example

let nanos = diff.as_secs() * 1_000_000_000 + diff.subsec_nanos() as u64;
let milis = diff.as_secs() * 1_000 + diff.subsec_milis() as u64;
let secs_f64 = (diff.as_secs() as f64 * 1_000.0 + diff.subsec_milis() as f64) / 100.0;
let secs_f64 = diff.as_secs() as f64 + diff.subsec_milis() as f64 / 1_000.0;
let secs_f64 = diff.as_secs() as f64 + diff.subsec_nanos() as f64 / 1_000_000_000.0;

Could be written as:

let nanos = diff.as_nanos() as u64;
let milis = diff.as_millis() as u64;
let secs_f64 = diff.as_secs_f64();
let secs_f64 = diff.as_secs_f64();
let secs_f64 = diff.as_secs_f64();

created time in 11 days

PR opened rust-lang/rust

Replace write_fmt with write!

Latter is simpler

+12 -12

0 comment

2 changed files

pr created time in 11 days

create barnchest31/rust

branch : write

created branch time in 11 days

PR opened rust-lang/rust

Replace manual as_nanos and as_secs_f64 reimplementations
+3 -10

0 comment

3 changed files

pr created time in 11 days

create barnchest31/rust

branch : ns

created branch time in 11 days

more