profile
viewpoint

nagisa/django-bfm 40

[Not really maintained anymore] BFM is an Apache Licenced server file manager for Django made with ease of use and new web technologies in mind.

nagisa/math.rs 31

Implementation of libm in rust

nagisa/Manga-Fox-Grabber 12

GUI to download manga from mangafox, make it into PDF, and maybe read in your EBook reader.

lucab/memfd-rs 8

A pure-Rust library to work with Linux memfd

nagisa/marksman_escape 7

HTML escaping and unescaping in Rust

nagisa/e4rat-preload-lite 5

More efficient way to preload e4rat file lists.

nagisa/Feeds 3

Feed Reader for GNOME.

nagisa/gnome-shell-theme-min 3

A GNOME-Shell theme without bells or whistles

nagisa/llvm_build_utils.rs 2

LLVM build utils for cargo build scripts

nagisa/django-localflavor-lt 1

Country-specific Django helpers for Lithuania.

pull request commentjturner314/py_literal

Port py_literal to pest with reproducibility fixes

I believe the fix was when you added the Rule::EOI on line 96 of parse.rs, and I've kept that change.

Yeah, but without the tmp change the error makes no sense. Though I guess I can see why you want to keep it inside the assertion...

what are you using py_literal for?

It is a dependency of the ndarray-npy, which is what we are actually using (to… load npy files).

nagisa

comment created time in 9 hours

pull request commentjturner314/py_literal

Port py_literal to pest with reproducibility fixes

Either way, please do release a version that includes this sooner rather than later.

nagisa

comment created time in 10 hours

pull request commentjturner314/py_literal

Port py_literal to pest with reproducibility fixes

Thanks for this! I've reverted an unnecessary change in src/parse_macros.rs

I think that change is in fact necessary. Before it I would get an error of the form:

expected `None`, got `None`

because when checking it would probably call iter.next() (and see EOI) and then when formatting the message call iter.next() again to produce the nonsensical message.

nagisa

comment created time in 10 hours

delete branch nagisa/py_literal

delete branch : reproducibility

delete time in 10 hours

issue commentrust-lang/rust

Miscompilation with clashing symbol fn names of different types

https://github.com/rust-lang/rust/pull/23011 added 7 of them and they still exist, but not sure why they don’t get triggered.

jumbatm

comment created time in 10 hours

issue commentrust-lang/rust

Miscompilation with clashing symbol fn names of different types

We used to have such a check already in the past, but it has been since removed in https://github.com/rust-lang/rust/commit/db477af9ade518d5d756daf20c647095a1f4af23#diff-1dee305d01351d452373973846b43671 cc @eddyb

jumbatm

comment created time in 10 hours

pull request commentjturner314/py_literal

Port py_literal to pest with reproducibility fixes

Looks to be good to go.

nagisa

comment created time in 17 hours

push eventnagisa/py_literal

Simonas Kazlauskas

commit sha b9ccbb25277499f1fe0618b091ebb67595ab995e

Fix format

view details

push time in 17 hours

push eventnagisa/py_literal

Simonas Kazlauskas

commit sha 66b98a27c8956743572030437b5deb0a9045f97d

Fix one of the tests...

view details

push time in 17 hours

pull request commentpest-parser/pest

Remove HashMap from derive/generate

Please release a version of pest_generator with this fix sooner rather than later.

nagisa

comment created time in a day

push eventnagisa/py_literal

Simonas Kazlauskas

commit sha 5922da0e475ff9ecd5d6dc240acbc0d2828a93e6

Fix one of the tests...

view details

push time in a day

Pull request review commentjturner314/py_literal

Port py_literal to pest with reproducibility fixes

 edition = "2018" num-bigint = { version = "0.2", default-features = false, features = ["std"] } num-complex = "0.2" num-traits = "0.2"-pest = "1.0"-pest_derive = "1.0"+pest = "2.1"+pest_derive = "2.1"+# Pin pest_generator to version with reproducibility+pest_generator = "2.1.2"

Not released yet, hopefully they will right after/if they land https://github.com/pest-parser/pest/pull/442.

nagisa

comment created time in a day

push eventnagisa/py_literal

Simonas Kazlauskas

commit sha 2c513688856f3a1187c7b625d3409fcd61002527

Port py_literal to pest with reproducibility fixes

view details

push time in a day

create barnchnagisa/py_literal

branch : reproducibility

created branch time in a day

fork nagisa/py_literal

Rust crate for parsing/formatting Python literals

https://docs.rs/py_literal

fork in a day

PR opened pest-parser/pest

Remove HashMap from derive/generate

There is a lot of value in outputs produced by compilers being reproducible. Rust makes it somewhat hard to get it right, but most of the time rustc’s outputs are also reproducible. This allows us to enjoy all the benefits as other more primitive toolchains. Most of the time.

Pest was, sadly, one of those examples where reproducibility was not a concern and HashMap was used to implement some of the code generation portions. Replacing this HashMap with a Vec and a O(nm) loop is the easy solution. With the values that n and m get substituted with in practice, however, this loop should still be approximately as good as the previous HashMap implementation.

+13 -9

0 comment

2 changed files

pr created time in a day

create barnchnagisa/pest

branch : reproducibility

created branch time in a day

fork nagisa/pest

The Elegant Parser

https://pest.rs

fork in a day

issue commentjturner314/py_literal

This crate fails to produce reproducible artifacts

Still fails with v2.0. Will submit a PR to update pest to 2-series sometime later, anyway.

nagisa

comment created time in a day

issue openedpest-parser/pest

pest derive macro is not reproducible

Using a pest derive macro to generate code will produce non-reproducible results. In turn crates using pest also become non-reproducible and a major pain to deal with.

ref. https://github.com/jturner314/py_literal/issues/14

created time in a day

issue commentjturner314/py_literal

This crate fails to produce reproducible artifacts

Yep, definitely looks like pest. Checking out this crate and doing the following:

cargo clean
cargo rustc -- -Zunstable-options --pretty=expanded > out1
cargo clean
cargo rustc -- -Zunstable-options --pretty=expanded > out2
diff -u out1 out2

Gives something along the lines of

--- out1	2020-02-22 05:28:38.434767770 +0200
+++ out2	2020-02-22 05:28:49.569917054 +0200
@@ -3664,53 +3664,53 @@
                                      })
                 }
                 #[inline]
-                fn soi<'i>(pos: ::pest::Position<'i>,
-                           _: &mut ::pest::ParserState<'i, Rule>)
+                fn pop<'i>(pos: ::pest::Position<'i>,
+                           state: &mut ::pest::ParserState<'i, Rule>)
                  ->
                      ::std::result::Result<::pest::Position<'i>,
                                            ::pest::Position<'i>> {
-                    pos.at_start()
+                    let pos =
+                        {
+                            let string =
+                                state.stack.last().expect("pop was called on empty stack").as_str();
+                            pos.match_string(string)
+                        };
+                    if pos.is_ok() { state.stack.pop().unwrap(); }
+                    pos
                 }
                 #[inline]
-                fn peek<'i>(pos: ::pest::Position<'i>,
-                            state: &mut ::pest::ParserState<'i, Rule>)
+                fn eoi<'i>(pos: ::pest::Position<'i>,
+                           _: &mut ::pest::ParserState<'i, Rule>)
                  ->
                      ::std::result::Result<::pest::Position<'i>,
                                            ::pest::Position<'i>> {
-                    let string =
-                        state.stack.last().expect("peek was called on empty stack").as_str();
-                    pos.match_string(string)
+                    pos.at_end()
                 }
                 #[inline]
-                fn any<'i>(pos: ::pest::Position<'i>,
+                fn soi<'i>(pos: ::pest::Position<'i>,
                            _: &mut ::pest::ParserState<'i, Rule>)
                  ->
                      ::std::result::Result<::pest::Position<'i>,
                                            ::pest::Position<'i>> {
-                    pos.skip(1)
+                    pos.at_start()
                 }
                 #[inline]
-                fn pop<'i>(pos: ::pest::Position<'i>,
-                           state: &mut ::pest::ParserState<'i, Rule>)
+                fn peek<'i>(pos: ::pest::Position<'i>,
+                            state: &mut ::pest::ParserState<'i, Rule>)
                  ->
                      ::std::result::Result<::pest::Position<'i>,
                                            ::pest::Position<'i>> {
-                    let pos =
-                        {
-                            let string =
-                                state.stack.last().expect("pop was called on empty stack").as_str();
-                            pos.match_string(string)
-                        };
-                    if pos.is_ok() { state.stack.pop().unwrap(); }
-                    pos
+                    let string =
+                        state.stack.last().expect("peek was called on empty stack").as_str();
+                    pos.match_string(string)
                 }
                 #[inline]
-                fn eoi<'i>(pos: ::pest::Position<'i>,
+                fn any<'i>(pos: ::pest::Position<'i>,
                            _: &mut ::pest::ParserState<'i, Rule>)
                  ->
                      ::std::result::Result<::pest::Position<'i>,
                                            ::pest::Position<'i>> {
-                    pos.at_end()
+                    pos.skip(1)
                 }
                 #[inline]
                 #[allow(dead_code)]

Reporting an issue there.

nagisa

comment created time in a day

issue openedjturner314/py_literal

This crate fails to produce reproducible artifacts

I haven’t investigated too closely what exactly is it, but every time this crate is built in a controlled environment, the produced rlib is wildly different.

I suspect it might be due to pest, but I haven’t investigated too deeply yet.

created time in a day

issue openedfish-shell/fish-shell

Adding a time builtin is a breaking change

I have the following in my fish configuration:

function time --description 'generate various statistics of running process'
    /bin/time -f '%P (%e real, %S kernel, %U user); %Mk resident\n%F major/%R minor pfaults; %W swaps; %c invol/%w vol contexts\n%I inputs/%O outputs; %s sck sent/%r sck recv; %k signals recv' $argv
end

and upgrading to

$ fish --version
fish, version 3.1.0

is now erroring out with

/etc/fish/config.fish (line 106): function: The name 'time' is reserved,
and can not be used as a function name
function time --description 'generate various statistics of running process'
^

and the time alias has changed in behaviour. This should be more prominent in the changelogs. Its now being noted down as just a "new command".

created time in a day

issue commentkolloch/crate2nix

jemalloc-sys is not reproducible

cc @andir

nagisa

comment created time in a day

issue openedkolloch/crate2nix

jemalloc-sys is not reproducible

Building project with jemalloc-sys as a dependency results in a closure that's not entirely reproducible. In particular, the build output will install a large number of other unnecessary files, including intermediate build artifacts. In particular instance of jemalloc-sys there will be just one different file: config.log:

<details> <summary>Diff</summary>

--- /nix/store/w7asdvykp8qnq27rd1xz0rip97rbyhyj-rust_jemalloc-sys-0.3.2-lib/lib/jemalloc-sys.out/build/config.log	1970-01-01 03:00:01.000000000 +0300
+++ /nix/store/w7asdvykp8qnq27rd1xz0rip97rbyhyj-rust_jemalloc-sys-0.3.2-lib.check/lib/jemalloc-sys.out/build/config.log	1970-01-01 03:00:01.000000000 +0300
@@ -508,7 +508,7 @@
 conftest.c:48:6: warning: conflicting types for built-in function 'log' [-Wbuiltin-declaration-mismatch]
  char log ();
       ^~~
-/nix/store/cl1i6bfqnx48ipakj4px7pb1babzs23j-binutils-2.31.1/bin/ld: /build/ccve8EIc.o: in function `main':
+/nix/store/cl1i6bfqnx48ipakj4px7pb1babzs23j-binutils-2.31.1/bin/ld: /build/ccwdPg4g.o: in function `main':
 /build/jemalloc-sys-0.3.2/target/build/jemalloc-sys.out/build/conftest.c:52: undefined reference to `log'
 collect2: error: ld returned 1 exit status
 configure:7639: $? = 1
@@ -1009,7 +1009,7 @@
 configure:10328: result: yes
 configure:10333: checking for dlsym
 configure:10333: gcc -o conftest -std=gnu11 -Wall -Wsign-compare -Wundef -Wno-format-zero-length -pipe -g3 -fvisibility=hidden -O3 -funroll-loops -O3 -ffunction-sections -fdata-sections -fPIC -g -fno-omit-frame-pointer -m64 -Wall -O3 -ffunction-sections -fdata-sections -fPIC -g -fno-omit-frame-pointer -m64 -Wall -D_GNU_SOURCE -O3 -ffunction-sections -fdata-sections -fPIC -g -fno-omit-frame-pointer -m64 -Wall conftest.c -lm  -lpthread >&5
-/nix/store/cl1i6bfqnx48ipakj4px7pb1babzs23j-binutils-2.31.1/bin/ld: /build/ccqJOSJ9.o: in function `main':
+/nix/store/cl1i6bfqnx48ipakj4px7pb1babzs23j-binutils-2.31.1/bin/ld: /build/ccCCuODv.o: in function `main':
 /build/jemalloc-sys-0.3.2/target/build/jemalloc-sys.out/build/conftest.c:100: undefined reference to `dlsym'
 collect2: error: ld returned 1 exit status
 configure:10333: $? = 1
@@ -1255,7 +1255,7 @@
 configure:10915: result: yes
 configure:10928: checking for issetugid
 configure:10928: gcc -o conftest -std=gnu11 -Wall -Wsign-compare -Wundef -Wno-format-zero-length -pipe -g3 -fvisibility=hidden -O3 -funroll-loops -O3 -ffunction-sections -fdata-sections -fPIC -g -fno-omit-frame-pointer -m64 -Wall -O3 -ffunction-sections -fdata-sections -fPIC -g -fno-omit-frame-pointer -m64 -Wall -D_GNU_SOURCE -D_REENTRANT -O3 -ffunction-sections -fdata-sections -fPIC -g -fno-omit-frame-pointer -m64 -Wall conftest.c -lm  -lpthread -ldl >&5
-/nix/store/cl1i6bfqnx48ipakj4px7pb1babzs23j-binutils-2.31.1/bin/ld: /build/ccIa2k8n.o: in function `main':
+/nix/store/cl1i6bfqnx48ipakj4px7pb1babzs23j-binutils-2.31.1/bin/ld: /build/ccWVvm7H.o: in function `main':
 /build/jemalloc-sys-0.3.2/target/build/jemalloc-sys.out/build/conftest.c:109: undefined reference to `issetugid'
 collect2: error: ld returned 1 exit status
 configure:10928: $? = 1
@@ -1375,7 +1375,7 @@
 configure:10928: result: no
 configure:10941: checking for _malloc_thread_cleanup
 configure:10941: gcc -o conftest -std=gnu11 -Wall -Wsign-compare -Wundef -Wno-format-zero-length -pipe -g3 -fvisibility=hidden -O3 -funroll-loops -O3 -ffunction-sections -fdata-sections -fPIC -g -fno-omit-frame-pointer -m64 -Wall -O3 -ffunction-sections -fdata-sections -fPIC -g -fno-omit-frame-pointer -m64 -Wall -D_GNU_SOURCE -D_REENTRANT -O3 -ffunction-sections -fdata-sections -fPIC -g -fno-omit-frame-pointer -m64 -Wall conftest.c -lm  -lpthread -ldl >&5
-/nix/store/cl1i6bfqnx48ipakj4px7pb1babzs23j-binutils-2.31.1/bin/ld: /build/cctEmE6r.o: in function `main':
+/nix/store/cl1i6bfqnx48ipakj4px7pb1babzs23j-binutils-2.31.1/bin/ld: /build/ccRRT9HM.o: in function `main':
 /build/jemalloc-sys-0.3.2/target/build/jemalloc-sys.out/build/conftest.c:109: undefined reference to `_malloc_thread_cleanup'
 collect2: error: ld returned 1 exit status
 configure:10941: $? = 1
@@ -1495,7 +1495,7 @@
 configure:10941: result: no
 configure:10956: checking for _pthread_mutex_init_calloc_cb
 configure:10956: gcc -o conftest -std=gnu11 -Wall -Wsign-compare -Wundef -Wno-format-zero-length -pipe -g3 -fvisibility=hidden -O3 -funroll-loops -O3 -ffunction-sections -fdata-sections -fPIC -g -fno-omit-frame-pointer -m64 -Wall -O3 -ffunction-sections -fdata-sections -fPIC -g -fno-omit-frame-pointer -m64 -Wall -D_GNU_SOURCE -D_REENTRANT -O3 -ffunction-sections -fdata-sections -fPIC -g -fno-omit-frame-pointer -m64 -Wall conftest.c -lm  -lpthread -ldl >&5
-/nix/store/cl1i6bfqnx48ipakj4px7pb1babzs23j-binutils-2.31.1/bin/ld: /build/ccoDPhwz.o: in function `main':
+/nix/store/cl1i6bfqnx48ipakj4px7pb1babzs23j-binutils-2.31.1/bin/ld: /build/ccsdpPIT.o: in function `main':
 /build/jemalloc-sys-0.3.2/target/build/jemalloc-sys.out/build/conftest.c:109: undefined reference to `_pthread_mutex_init_calloc_cb'
 collect2: error: ld returned 1 exit status
 configure:10956: $? = 1

</details>

An obvious fix would be to just not install the unnecessary files. Did not yet investigate it is crate2nix or buildRustCrate (I think its going to be latter) that’s installing them, but since bugs here have significantly greater signal-to-noise ratio, reporting it here.

created time in a day

issue commentPyO3/pyo3

The extension-module feature fails to be additive

2 pyo3 crates for the separate use-cases (pyo3-extension to if you’re writing an extension and pyo3 otherwise) would help to an extent. It still would fail to work for a crate that has both a library and binary output, but it would not fail to work in a workspace where you have a binary and extension as entirely separate entities.

Another option would be to move the attachment of the relevant linker arguments to the user crate. e.g. pyo3 could expose

macro_rules! link_python { 
    () => {
        #[link(name=env!("PYO3_PYTHON_BINARY_LINK_ARG"))] // envvar exported by the build script
        extern {}
    }
}

and the binaries using python would be responsible for invoking this macro somewhere inside (usually main.rs?) that’s used only in the binary but not the library. Would work in either case.

This is what we currently (in its non-macro form) use in our project which originally prompted this issue.

nagisa

comment created time in 2 days

issue commentrust-lang/rust

Re-evaluate `Hash{Set,Map}` vs `FxHash{Set,Map}` once #69152 lands

aHash not being reproducible between machines make it unsuitable choice for rustc anyway. If we want to have any resemblance of support for distributed builds, that is.

nnethercote

comment created time in 2 days

issue commentPyO3/pyo3

The extension-module feature fails to be additive

One is the behavior of workspaces, as explained in ...

However Rust (and Cargo) project was operating presuming features to be additive (see also https://github.com/rust-lang/cargo/issues/4328) and a ton functionality assumes that enabling additional features is valid. A large many of workflows like cargo test --all-features and even outside of cargo assume this.

While some of the links do suggest very relevant solutions, given their state I’m not sure why pyo3 shouldn’t be investigating ways to resolve this and similar issues on its end.

nagisa

comment created time in 2 days

issue commentiterative/dvc

Telemetrics daemon is creepy and broken

We are doing that for our pyinstaller-built packages, if there is a way to detect that we are currently running in such a way (e.g. maybe there are some env vars that poetry2nix sets that we can base our logic on?) then we could easily do that. Or we could fail and retry, sure.

No easy way to check (the wrapper only really adjusts PATH and PYTHONPATH) but dvc could check if the file is valid Python by compileing it first?

nagisa

comment created time in 2 days

issue commentrust-lang/rust

Re-evaluate `Hash{Set,Map}` vs `FxHash{Set,Map}` once #69152 lands

I can confirm similar findings between DefaultHasher and fx even though in my own codebases (although belatedly)

Hardware accelerated hashes sound nice until you consider the bigger than usual performance cliff when it does not exist. Using something like ahash is fine when you know you only care about x86. Rustc cares about way more.

On Fri, 21 Feb 2020, 00:09 Eduard-Mihai Burtescu, notifications@github.com wrote:

@nnethercote https://github.com/nnethercote Just to confirm, when you're talking about DefaultHasher, it's still SipHash, right?

I had seen #69153 (comment) https://github.com/rust-lang/rust/issues/69153#issuecomment-586180880 and got myself confused into thinking your results were for aHash.

I'm not surprised SipHash is still a slowdown, given its intended usecase (DoS protection), I don't think we can get away with a hash function "that good" unless we can heavily rely on hardware acceleration (which, ironically, might make actual cryptographic hashes faster; I guess the hardware acceleration might be reusable for something weaker than full-blown AES, but I have no idea).

— You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub https://github.com/rust-lang/rust/issues/69153?email_source=notifications&email_token=AAFFZUWZRSYYE6NFQE6M4G3RD35THA5CNFSM4KU7TWWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMQRPKY#issuecomment-589371307, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFFZUXWBHY3N73T2WRESXTRD35THANCNFSM4KU7TWWA .

nnethercote

comment created time in 3 days

issue commentiterative/dvc

Telemetrics daemon is creepy and broken

Well, the wrapper here comes from poetry2nix I believe, but I’m writing this issue here, because I believe its best fixed in dvc.

I can suggest a couple ways to fix this (subjectively ordered from the best to worst):

  1. Fork and call the relevant code in the fork;
  2. Ignore the error and continue working without a component that’s otherwise optional anyway;
  3. Try multiple ways to spawn argv[0] (e.g. try also without prepending sys.executable).
nagisa

comment created time in 3 days

issue commentiterative/dvc

Telemetrics daemon is creepy and broken

Could you please describe such a use case in more details?

A common reason to overwrite argv[0] is to ensure that when user invokes a program, the program appears to act as if it was argv[0]. A good example where this is very relevant is the --help screen. If the wrapper script was:

#/usr/bin/env bash
# some setup here
wrapped_command "$@"

then the the fact that it is a wrapped_command would leak out and the user might mistakenly copy-paste some invocation that misses the wrapper. As the example here shows, overwriting argv[0] might also be necessary to ensure that the program uses the wrapper when it spawns itself.

So instead the script is written as such:

#!/usr/bin/env bash
#some setup here
exec -a "$0" wrapped_command "$@"

and this ensures that this hole gets plugged up, at least to some extent.

In our particular case the wrapper sets up the $PATH and $PYTHONPATH, so missing the wrapper would just make things fail altogether, anyway.

Hope that helps.

nagisa

comment created time in 3 days

issue openediterative/dvc

Telemetrics daemon is creepy and broken

When sys.argv[0] is not pointing exactly to the DVC script (which can happen occasionally when wrapping the entry points up) the daemon spawning code will fail as it will try to run $PYTHON $WRAPPER and not just $WRAPPER or $PYTHON $ACTUALPYTHONSCRIPT. $WRAPPER here could be, for instance, a bash script.


Not to mention that spawning some daemon to ship data off to the Internets by default is just outright creepy.

created time in 3 days

issue openedkolloch/crate2nix

proc_macro should be in the prelude

As of https://github.com/rust-lang/cargo/pull/7700 --extern proc_macro is getting added to the prelude of the rustc invocations cargo makes when building proc_macro crates.

As crate2nix/buildRustCrate (not sure where exactly this would go, filling this issue out without investigating too much) does not add this flag, there’s some discrepancy between how rustc behaves when invoked by cargo and by crate2nix. In particular cargo does not require extern crate proc_macro anymore to use proc_macro in proc_macro crates, so eventually things will start failing to compile when this gets to stable and crates stop including this.

created time in 3 days

issue commentkolloch/crate2nix

nix-shell support

(nb: cargo here is from the mozilla overlay so it does include all the cargo-tools you’d expect)

kolloch

comment created time in 3 days

issue commentkolloch/crate2nix

nix-shell support

{ lib, mkShell, allCrates, cargo }:

let
  depsCollector = n: a: a.completeBuildDeps ++ a.completeDeps ++ [a];
  allRustDeps = lib.mapAttrsToList depsCollector allCrates;
  uniqueRustDeps = lib.unique (builtins.concatLists allRustDeps);
  inputs = builtins.map (a: a.buildInputs) uniqueRustDeps;
  uniqueInputs = lib.unique (builtins.concatLists inputs);
  nativeInputs = builtins.map (a: a.nativeBuildInputs) uniqueRustDeps;
  uniqueNativeInputs = lib.unique (builtins.concatLists nativeInputs);
  getUniqueValue = list: (assert [(lib.head list)] == lib.unique list; lib.head list);
  envVars = lib.zipAttrs (builtins.map (lib.filterAttrs (n: v: n == lib.toUpper n)) uniqueRustDeps);
  verifiedEnvVars = lib.mapAttrs (n: v: getUniqueValue v) envVars;
  shellAttrs = verifiedEnvVars // {
    name = "rust-build-shell";
    buildInputs = uniqueInputs;
    nativeBuildInputs = uniqueNativeInputs ++ [
      cargo
    ];
  };

in mkShell shellAttrs

is what I came up locally a little while ago.

kolloch

comment created time in 3 days

issue closedrust-lang/rust

unused-extern-crate false positive with sysroot crates

To use certain crates such as proc_macro it is required to include it with extern crate proc_macro. Similar thing applies to other sysroot crates.

Denying the unused group of lints will prevent code from compiling properly with an error like this:

error: `extern crate` is not idiomatic in the new edition
 --> src/lib.rs:3:1
  |
3 | extern crate proc_macro;
  | ^^^^^^^^^^^^^^^^^^^^^^^^ help: convert it to a `use`
  |
  = note: `-D unused-extern-crates` implied by `-D unused`

closed time in 3 days

nagisa

issue commentrust-lang/rust

unused-extern-crate false positive with sysroot crates

Ah, I see why this is happening, now.

What we do is we run nightly cargo clippy, which, I presume, does add the --extern proc_macro but we compile actual code with plain rustc and we do not add the flag (yet). Hence the disconnect between what the lint is saying and the behaviour we are seeing when compiling code.

Closing as not-a-bug.

nagisa

comment created time in 3 days

issue commentrust-lang/rust

unused-extern-crate false positive with sysroot crates

Note that at least the "convert to use" suggestion is not applicable, because use-ing a sysroot crate does not in fact work cc @estebank

nagisa

comment created time in 3 days

issue commentrust-lang/rust

unused-extern-crate false positive with sysroot crates

Might be reproducible only when cargo checking a proc_macro crate. I am having trouble in quickly minimizing this.

nagisa

comment created time in 3 days

issue openedrust-lang/rust

unused-extern-crate false positive with sysroot crates

To use certain crates such as proc_macro it is required to include it with extern crate proc_macro. Similar thing applies to other sysroot crates.

Denying the unused group of lints will prevent code from compiling properly with an error like this:

error: `extern crate` is not idiomatic in the new edition
 --> src/lib.rs:3:1
  |
3 | extern crate proc_macro;
  | ^^^^^^^^^^^^^^^^^^^^^^^^ help: convert it to a `use`
  |
  = note: `-D unused-extern-crates` implied by `-D unused`

created time in 3 days

issue commentrust-lang/rust-clippy

unneeded_field_pattern

This should definitely become allow-by-default.

nipunn1313

comment created time in 4 days

issue closedrust-lang/rust-clippy

Changing CLI flags does not invalidate previous runs

Changing the CLI flags passed to clippy will not make clippy re-run the affected lints on crates. In particular running

cargo clippy

may reveal a number of warnings that one might want to immediately deny before fixing, so they would change their CI script to invoke

cargo clippy -- -Dclippy::some_lint

but upon rerunning the CI script cargo clippy will just dump the old warnings from previous run.

closed time in 4 days

nagisa

issue commentrust-lang/rust-clippy

Changing CLI flags does not invalidate previous runs

I guess?

nagisa

comment created time in 4 days

issue openedrust-lang/rust-clippy

Changing CLI flags does not invalidate previous runs

Changing the CLI flags passed to clippy will not make clippy re-run the affected lints on crates. In particular running

cargo clippy

may reveal a number of warnings that one might want to immediately deny before fixing, so they would change their CI script to invoke

cargo clippy -- -Dclippy::some_lint

but upon rerunning the CI script cargo clippy will just dump the old warnings from previous run.

created time in 4 days

issue openedPyO3/pyo3

The extension-module feature fails to be additive

In Rust it is the best practice to have features to be strictly additive. extension-module, instead, subtracts from the crate by not linking python. This can result in weird and difficult to resolve failure modes in e.g. workspaces.

For instance consider…

💥 Reproducing

[workspace]
members = [
    "extension",
    "some_binary",
]

where both extension and some_binary use as a dependency pyo3, but extension enables the extension-module feature, while some_binary explicitly disables the features.

When cargo build is run from the workspace root, then both of the binaries will get a pyo3 with extension-module feature enabled and some_binary will fail to link.

This behaviour is entirely valid from cargo’s standpoint – it dictates that features should be additive and thus there must not be a way to write any single crate in a way that would fail when additional features are enabled in its dependencies.

To be honest, I don’t see a good way to fix it, other than spiting pyo3 into two separate crates.

created time in 5 days

issue closedrust-lang/rust

Confusing error message on error [E0599]

Hi! I was doing some work with async_std when I got a confusing error message. With this minimal code:

use async_std::{stream::Stream, task::Poll};

pub fn test_poll_next<F, T>(first: F) -> Poll<Option<T>>
where
    F: Stream<Item = T>,
{
    first.poll_next()
}

I got this error:

error[E0599]: no method named `poll_next` found for type `F` in the current scope
 --> src/lib.rs:7:11
  |
7 |     first.poll_next()
  |           ^^^^^^^^^ method not found in `F`
  |
  = help: items from traits can only be used if the type parameter is bounded by the trait
help: the following traits define an item `poll_next`, perhaps you need to restrict type parameter `F` with one of them:
  |
3 | pub fn test_poll_next<F: futures_core::stream::Stream, T>(first: F) -> Poll<Option<T>>
  |                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3 | pub fn test_poll_next<F: futures_core::stream::Stream, T>(first: F) -> Poll<Option<T>>
  |                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

If I follow the suggestion, import futures_core and so on, I get the following error message:

error[E0599]: no method named `poll_next` found for type `F` in the current scope
 --> src/lib.rs:7:11
  |
7 |     first.poll_next()
  |           ^^^^^^^^^ method not found in `F`
  |
  = help: items from traits can only be used if the type parameter is bounded by the trait
help: the following traits define an item `poll_next`, perhaps you need to restrict type parameter `F` with one of them:
  |
3 | pub fn test_poll_next<F: futures_core::stream::Stream + futures_core::stream::Stream, T>(first: F) -> Poll<Option<T>>
  |                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3 | pub fn test_poll_next<F: futures_core::stream::Stream + futures_core::stream::Stream, T>(first: F) -> Poll<Option<T>>
  |                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

Which seems to be redundant. So, this seems not to be the issue I'm facing. What is really happening here?

closed time in 5 days

Razican

issue commentrust-lang/rust

Confusing error message on error [E0599]

Duplicate of #65149

Razican

comment created time in 5 days

issue commentrust-lang/rust

Trait bound is ignored

Should we close the duplicates? And also this issue, given that we no longer suggest wrong?

fuchsnj

comment created time in 5 days

issue commentrayon-rs/rayon

Scheduling should be topology/NUMA aware

Re-titling the issue to be more general than just "NUMA" as nowadays even within a single NUMA node certain logical cores are a better choices than the others when deciding where to send work.

nagisa

comment created time in 7 days

pull request commentrust-lang/rust

[WIP] Implement new asm! syntax from RFC 2850

I’ll be reviewing this per-commit and fairly slowly as I have time to dig into it, so the comments will come in as a trickle.

Amanieu

comment created time in 8 days

Pull request review commentrust-lang/rust

[WIP] Implement new asm! syntax from RFC 2850

  fn main() {     unsafe {-        asm!(""); //~ ERROR inline assembly is not stable enough+        llvm_asm!(""); //~ ERROR inline assembly is not stable enough

Make sure that both the the new macro and the old pass-through are unstable.

Amanieu

comment created time in 8 days

Pull request review commentrust-lang/rust

[WIP] Implement new asm! syntax from RFC 2850

 #![feature(is_sorted)] #![feature(lang_items)] #![feature(link_llvm_intrinsics)]+#![feature(llvm_asm)]

I think you’ll want to add a feature-gate test for this.

Amanieu

comment created time in 8 days

issue commentrust-lang/rust

_modsi3 macros.rs:255 crash on armv7 & armv7s iOS Device

is that possible?

Sure, sounds plausible enough. It might help to link the rust library to your application in a way that does not leak Rust’s code.

ronghui1219

comment created time in 8 days

issue commentrust-lang/rust

Trait bounds were not satisfied

I'm curious whom to blame in this patricular case:

Some fault definitely lies in the compiler for being confusing about the lifetime names it puts in the diagnostic hints. Hence the A-diagnostics label. Whether HRTBs would make sense in any particular scenario is not for the compiler to decide – it affects the public API after all and is something that you’d need to arrive to yourself.

ababo

comment created time in 8 days

issue commentrust-lang/rust

Trait bounds were not satisfied

(FWIW the code is extremely difficult to make sense of, I suspect that it was arrived to from the other end – that is, by looking at a compiler diagnostic and then adding lifetime bounds everywhere possible)

The following is something that at least compiles and makes some sense to at least me.

pub struct Script {
    vm: gluon::RootedThread,
}

impl Script
{
    pub async fn run<In, Out>(&mut self, input: In) -> Result<Out, Box<dyn std::error::Error>>
    where
        In: VmType + for<'banana> Pushable<'banana>,
        Out: VmType + for<'peach, 'mango> Getable<'peach, 'mango> + Send + Sync + 'static,
    {
        let mut func = self.vm.get_global::<FunctionRef<fn(In) -> Out>>("main")?;

        return Ok(func.call_async(input).compat().await?);
    }
}
ababo

comment created time in 8 days

issue commentrust-lang/rust

Trait bounds were not satisfied

This code is extremely hard to make sense and I think the confusion comes entirely from the fact that the lifetimes used in gluon and in this code have matching names – which is why the compiler notes appear to be wrong – while they actually aren't.

For instance even if you rewrite the code as such:

use futures_util::compat::Future01CompatExt;
use gluon::{
    vm::api::{FunctionRef, Getable, Pushable, VmType},
};

pub type Error = gluon::Error;

pub struct Script<'banana, 'peach, In, Out>
where
    In: VmType + Pushable<'banana>,
    Out: VmType + Getable<'banana, 'peach> + Send + Sync,
{
    vm: gluon::RootedThread,
}

impl<'banana, 'peach, In, Out> Script<'banana, 'peach, In, Out>
where
    In: VmType + Pushable<'banana>,
    Out: VmType + Getable<'banana, 'peach> + Send + Sync,
{
    pub async fn run(&mut self, input: &In) -> Result<Out, Error> {
        let func: FunctionRef<fn(In) -> Out> = self.vm.get_global("main")?;

        return func.call_async(input).compat().await;
    }
}

you will get exactly the same error as before:

error[E0599]: no method named `call_async` found for type `gluon::gluon_vm::api::Function<&gluon::Thread, fn(In) -> Out>` in the current scope
  --> src/lib.rs:27:21
   |
27 |         return func.call_async(input).compat().await;
   |                     ^^^^^^^^^^ method not found in `gluon::gluon_vm::api::Function<&gluon::Thread, fn(In) -> Out>`
   |
   = note: the method `call_async` exists but the following trait bounds were not satisfied:
           `In : gluon::gluon_vm::api::Pushable<'vm>`
           `Out : gluon::gluon_vm::api::Getable<'x, 'value>`

making it easier to see that this is at best a diagnostics bug.

ababo

comment created time in 8 days

issue commentrust-lang/rust

_modsi3 macros.rs:255 crash on armv7 & armv7s iOS Device

rust replace iOS own implementation?

Not actively. It does have an implementation of this, but generally having two conflicting symbols should result in linking errors, not one implementation being silently called over the other.

This will definitely require investigation on your part or a fairly isolated mcve.

ronghui1219

comment created time in 8 days

issue commentrust-lang/rust

Bad quality code for `Clone` on enum types

Clone is special-cased for cases where Copy is also implemented. The other case depends entirely on optimizer as derive(Clone) has to generate a fairly generic sequence of operations that would work for arbitrary enums.

reinerp

comment created time in 8 days

pull request commentrust-lang/rust

Added tvOS as targets

Looks like you’ll need to reformat the code, but otherwise LGTM.

simlay

comment created time in 8 days

issue commentrust-lang/rust

Absolute path to *.pdb in the binary file

This is a tracker for the issues in rustc. For support, consider posting your question on users.rlo, stackoverflow, reddit, or asking on one of the chat platforms: discord or zulip.


That said, does --remap-path-prefix help?

afonichev

comment created time in 9 days

issue commentrust-lang/rust

thread::Builder::spawn returns WouldBlock

So I think it's a good idea to automatically retry clone() on EAGAIN.

The only thing we currently do this for widely is EINTR AFAIK as implications of doing so are well understood. I’m not sure this is true for clone's EAGAIN.

jethrogb

comment created time in 9 days

issue commentrust-lang/rust

Jemalloc causes os-level deadlock

It is worth noting that we do not actively support versions that are so outdated. It would be great if you could try this same code with the current stable compiler with jemalloc enabled and see if it reproduces. Otherwise this issue should be closed.

git-blame

comment created time in 9 days

issue commentrust-lang/rust

Rustc overflow its stack when using impl Trait and the struct containing the function itself

Should we make LLVM type names respect -Zfewer-names?

Yes, the whole point of this option is to produce as lean LLVM-IR as possible -- to reduce the peak memory use first and foremost. This means no variable names, no label names and I don't see how type names are in any way unique here that would warrant keeping them.

lszxb

comment created time in 10 days

delete branch standard-ai/nixpkgs-tensorflow-rust

delete branch : buildRustCrate-rlib-support

delete time in 10 days

delete branch standard-ai/nixpkgs-tensorflow-rust

delete branch : buildRustCrate-no-out-path-overlay

delete time in 10 days

delete branch standard-ai/nixpkgs-tensorflow-rust

delete branch : nagisa/test-fixed-build-rust-crate

delete time in 10 days

delete branch standard-ai/nixpkgs-tensorflow-rust

delete branch : nagisa/backport-prefetch-git

delete time in 10 days

delete branch standard-ai/nixpkgs-tensorflow-rust

delete branch : nagisa/backport-speedups

delete time in 10 days

push eventstandard-ai/nixpkgs-tensorflow-rust

Andreas Rammhold

commit sha 563db0b42332376e08190d1651a0973dd17a177f

nix-prefetch-git: add gawk to PATH The prefetch script requires awk to be in PATH and fails otherwise. Fixes #79968

view details

push time in 10 days

pull request commentNixOS/nixpkgs

nix-prefetch-git: add gawk to PATH

r=me, not that it means anything :)

andir

comment created time in 10 days

issue openedNixOS/nixpkgs

nix-prefetch-git derivation does not pull all the necessary dependencies

Describe the bug

The derivation for nix-prefetch-git does not properly specify all the dependencies it requires to run. Namely, at least awk is missing.

To Reproduce

$ PATH= $(which nix) run -f '<nixpkgs>' nix-prefetch-git -c nix-prefetch-git --fetch-submodules https://github.com/githubtraining/example-dependency
Initialized empty Git repository in /run/user/1000/git-checkout-tmp-jRmv6W3w/example-dependency/.git/
remote: Enumerating objects: 7, done.
remote: Counting objects: 100% (7/7), done.
remote: Compressing objects: 100% (6/6), done.
remote: Total 7 (delta 0), reused 6 (delta 0), pack-reused 0
Unpacking objects: 100% (7/7), 1.08 KiB | 1.08 MiB/s, done.
From https://github.com/githubtraining/example-dependency
 * branch            HEAD       -> FETCH_HEAD
Switched to a new branch 'fetchgit'
Submodule 'js' (https://github.com/githubtraining/example-submodule.git) registered for path 'js'
/nix/store/0ddl3hxhkyvrxsi1zx4dfd6sj3bppj4x-nix-prefetch-git/bin/.nix-prefetch-git-wrapped: line 188: awk: command not found

Expected behavior It should work in a clean environment.

Metadata

  • system: "x86_64-linux"
  • host os: Linux 5.4.0, NixOS, 20.03pre202933.bbeed8b9e7e (Markhor)
  • multi-user?: yes
  • sandbox: yes
  • version: nix-env (Nix) 2.3.1
  • channels(root): "nixos-20.03pre212209.eee784a1bb6"
  • channels(nagisa): ""
  • nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

created time in 10 days

pull request commentrust-lang/rust

Suggestion when encountering assoc types from hrtb

@bors r+

estebank

comment created time in 10 days

push eventstandard-ai/nixpkgs-tensorflow-rust

Richard Wallace

commit sha 5f4e137baeebcda7acbf5fa7680acd9b566a0313

dockerTools.buildLayeredImage: fix building layered images in parallel when tar'ing store paths into layered archives when building layered images, don't use the absolute nix store path so that tar won't complain if something new is added to the nix store when building the final docker image, ignore any file changes tar detects in the layers. they are all immutable and the only thing that might change is the number of hard links due to store optimization

view details

Simonas Kazlauskas

commit sha fe112004dd48577672fcdafb23a858da614459ea

Merge pull request #9 from purcell/docker-tar-backport Backported fix for building layered images in parallel

view details

push time in 10 days

PR merged standard-ai/nixpkgs-tensorflow-rust

Backported fix for building layered images in parallel

This appears safe to apply standalone.

https://github.com/NixOS/nixpkgs/pull/75911

/cc @nagisa

+48 -6

0 comment

2 changed files

purcell

pr closed time in 10 days

pull request commentrust-lang/rust

Support new LLVM pass manager

@nikic fwiw you could’ve retried bors yourself...

nikic

comment created time in 11 days

pull request commentrust-lang/rust

Support new LLVM pass manager

@bors r+

nikic

comment created time in 11 days

push eventstandard-ai/hedwig-rust

Simonas Kazlauskas

commit sha ca11c1bd0c4b07a1178d8087115f9f46e7472b48

We are asynchronous now

view details

push time in 12 days

pull request commentrust-lang/rust

Make the SGX arg cleanup implementation a NOP

@bors r=jethrogb,nagisa

Goirad

comment created time in 12 days

pull request commentrust-lang/rust

Make the SGX arg cleanup implementation a NOP

@bors r+ as per the LGTM above.

Goirad

comment created time in 12 days

issue commentrust-lang/rust

Feature request: `swap_retain`

Algorithmically you are not required to copy the whole tail every time. As you know that the resulting list will be no larger than the initial one, the algorithm can keep 2 pointers: a write head and the read head & just copy from read head to write head as it iterates through the list.

Lucretiel

comment created time in 12 days

PR opened standard-ai/nixpkgs-tensorflow-rust

Reviewers
buildRustCrate: remove superfluous dependency overrides

By overriding each dependency on every level of the dependency tree we are creating a lot of unnecessary instances of the same derivation

Looking at the output size of nix-instantiate --trace-function-calls -vvvv … and the execution time I got about a 10x improvement after applying this change.

It was probably good intentions that lead to these overrides but in practice no tooling (that I know of) really needs this. carnix and crate2nix are fine without those overrides. Furthermore I believe that it is the job of the tooling around buildRustCrate to provide a coherent set of overrides. By not enforcing all of the overrides, debug flags, verbosity, … to be the same throughout the closure we also allow consumers to override specific aspects of the crates. Some (older?) crates might need different crateOverrides then newer crates with the same name. Currently such situations can not (easily) be implemented with the override in-place.

+2 -5

0 comment

1 changed file

pr created time in 12 days

create barnchstandard-ai/nixpkgs-tensorflow-rust

branch : nagisa/backport-speedups

created branch time in 12 days

pull request commentrust-lang/rust

Cleanup SGX entry code

@bors r+

jethrogb

comment created time in 12 days

issue openedrust-lang/cargo

workspaces: overzealous native library dependency conflicting

<!-- Thanks for filing a 🐛 bug report 😄! -->

Problem

I have a workspace with multiple crates, but for brevity purposes, consider this workspace:

[workspace]
members = [
    "brand_new",
    "old_rusty",
]

These two output a binary executable and don’t depend on each other at all. They have the following dependencies:

brand_new: ring v0.16
old_rusty: ring v0.13

And both versions of ring, in turn, specify links="ring-asm".

Trying to cargo update this workspace will then fail with the following error:

error: failed to select a version for `ring`.
    ... required by package `brand_new v0.0.1 (/tmp/foo/brand_new)`
versions that meet the requirements `^0.16` are: 0.16.11, 0.16.10, 0.16.9, 0.16.7, 0.16.6, 0.16.5, 0.16.4, 0.16.3, 0.16.2, 0.16.1, 0.16.0

the package `ring` links to the native library `ring-asm`, but it conflicts with a previous package which links to `ring-asm` as well:
package `ring v0.13.5`
    ... which is depended on by `old_rusty v0.0.1 (/tmp/foo/old_rusty)`

failed to select a version for `ring` which could resolve this conflict

There's no actual conflict here, however, and not using a workspace would make it work just fine. Whether that’s a good-enough of a workaround is dubious, though.

Steps <!-- The steps to reproduce the bug. -->

  1. Copy the setup from this gist: https://gist.github.com/nagisa/ca95a787c25ba27a73eb3662c85016b2
  2. Run cargo update

Possible Solution(s)

Do not conflict when a particular workspace crate links to just one links dependency. Care must be taken, however, to ensure that we still do conflict when we’d end up pulling multiple links crates into the same binary.

Notes

Output of cargo version: not relevant

created time in 12 days

pull request commentrust-lang/rust

Suggestion when encountering assoc types from hrtb

cc @eddyb

estebank

comment created time in 12 days

pull request commentrust-lang/rust

Suggestion when encountering assoc types from hrtb

Very coo overall! I think we shold remove the "not representable" message for now (or implement an alternative suggestion) and r=me then.

estebank

comment created time in 12 days

Pull request review commentrust-lang/rust

Suggestion when encountering assoc types from hrtb

 error[E0212]: cannot extract an associated type from a higher-ranked trait bound    | LL |     field: I::A    |            ^^^^+   |+   = note: this is not currently representable in Rust

Hmm, this says "not representable", but you can still do things like:

pub trait Foo<T> {
    type A;
    fn get(&self, t: T) -> Self::A;
}

struct SomeStruct<'a, I : for<'x> Foo<&'x isize>> {
    field: <I as Foo<&'a isize>>::A
}

And it’ll work fine, likely doing exactly what you’d expect?

estebank

comment created time in 12 days

pull request commentNixOS/nixpkgs

buildRustCrate: remove superfluous dependency overrides

This indeed appears to be much faster for a large workspace:

this: 104% (12.29 real, 0.52 kernel, 12.26 user); 943872k resident
before: 108% (120.91 real, 4.05 kernel, 127.24 user); 5063676k resident

We do still instantiate the most depended-on crates dozens of times, but it is definitely more livable now.

r+

andir

comment created time in 12 days

Pull request review commentrust-lang/rust

Cleanup SGX entry code

 IMAGE_BASE:  /*  We can store a bunch of data in the gap between MXCSR and the XSAVE header */ +/* MXCSR initialization value for ABI */+.Lmxcsr_init:+    .int 0x1f80++/* x87 FPU control word initialization value for ABI */+.Lfpucw_init:+    .int 0x037f

This is setting one of the reserved bits (6th) to 1?

jethrogb

comment created time in 12 days

pull request commentrust-lang/rust

Cleanup SGX entry code

All of these commits could definitely use some more text on them describing the why.

jethrogb

comment created time in 12 days

issue commentrust-lang/rust

Feature request: `swap_retain`

Not obvious if it indeed would be more efficient. Will likely depend on how many elements are in fact being removed. For cases where pred is more often true than not, regular retain is likely to be more efficient (due to lower memory throughput and more cache locality).

Lucretiel

comment created time in 12 days

issue commentkolloch/crate2nix

Super-linear instantiation counts/time

I went ahead and made a flamegraph of nix when evaluating a further cut-down Cargo.toml.

This suggests that most of the time is spent in build-rust-crate rather than the code generated by crate2nix... In particular https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/rust/build-rust-crate/default.nix#L18 looks sketchy. cc @Ekleog @andir

nagisa

comment created time in 12 days

issue openedNixOS/nixpkgs

google-cloud-sdk: gsutil does not work

Describe the bug

$ gsutil cp this gs://there
Traceback (most recent call last):
  File "/nix/store/w6sf268nsl8zbirfy8659wnrsbwiwjsq-google-cloud-sdk-268.0.0/google-cloud-sdk/platform/gsutil/gsutil", line 21, in <module>
    gsutil.RunMain()
  File "/nix/store/w6sf268nsl8zbirfy8659wnrsbwiwjsq-google-cloud-sdk-268.0.0/google-cloud-sdk/platform/gsutil/gsutil.py", line 123, in RunMain
    import gslib.__main__
  File "/nix/store/w6sf268nsl8zbirfy8659wnrsbwiwjsq-google-cloud-sdk-268.0.0/google-cloud-sdk/platform/gsutil/gslib/__main__.py", line 75, in <module>
    from gslib.command_runner import CommandRunner
  File "/nix/store/w6sf268nsl8zbirfy8659wnrsbwiwjsq-google-cloud-sdk-268.0.0/google-cloud-sdk/platform/gsutil/gslib/command_runner.py", line 64, in <module>
    from gslib.tests.util import HAS_NON_DEFAULT_GS_HOST
ImportError: No module named tests.util

To Reproduce Steps to reproduce the behavior:

  1. nix run -f '<nixpkgs>' google-cloud-sdk -c gsutil --help

Expected behavior

Works.

Metadata

 - system: `"x86_64-linux"`
 - host os: `Linux 5.4.0, NixOS, 20.03pre202933.bbeed8b9e7e (Markhor)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3.1`
 - channels(root): `"nixos-20.03pre212209.eee784a1bb6"`
 - channels(nagisa): `""`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Maintainer information:

# a list of nixpkgs attributes affected by the problem
attribute: google-cloud-sdk
# a list of nixos modules affected by the problem
module:

created time in 13 days

issue closedrust-lang/rust

about std output

I very like the Rust lang, We strongly hope to add syntax to template output: fn main(){ let string = “test”; println!("${string}"); // "test" //or println!("{string}"); // "test" }

closed time in 13 days

toop

issue closedrust-lang/rust

Valgrind reports that statx arguments point to unaddressable bytes

I tried this code:

fn main() {
    std::fs::metadata("/").unwrap();
}

I compiled it and ran it under Valgrind:

$ rustc example.rs
$ valgrind ./example

I expected to see that Valgrind reported no errors.

Instead, it reports errors:

==1164== Memcheck, a memory error detector
==1164== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1164== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==1164== Command: ./example
==1164==
==1164== Syscall param statx(file_name) points to unaddressable byte(s)
==1164==    at 0x49B094D: syscall (syscall.S:38)
==1164==    by 0x1149AB: statx (weak.rs:90)
==1164==    by 0x1149AB: std::sys::unix::fs::try_statx (fs.rs:132)
==1164==    by 0x11430E: std::sys::unix::fs::stat (fs.rs:995)
==1164==    by 0x10C43B: std::fs::metadata (in /home/ubuntu/example)
==1164==    by 0x10CBB2: example::main (in /home/ubuntu/example)
==1164==    by 0x10C382: std::rt::lang_start::{{closure}} (in /home/ubuntu/example)
==1164==    by 0x113082: {{closure}} (rt.rs:52)
==1164==    by 0x113082: std::panicking::try::do_call (panicking.rs:292)
==1164==    by 0x114E39: __rust_maybe_catch_panic (lib.rs:78)
==1164==    by 0x113A7F: try<i32,closure-0> (panicking.rs:270)
==1164==    by 0x113A7F: catch_unwind<closure-0,i32> (panic.rs:394)
==1164==    by 0x113A7F: std::rt::lang_start_internal (rt.rs:51)
==1164==    by 0x10C367: std::rt::lang_start (in /home/ubuntu/example)
==1164==    by 0x10CBEA: main (in /home/ubuntu/example)
==1164==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==1164==
==1164== Syscall param statx(buf) points to unaddressable byte(s)
==1164==    at 0x49B094D: syscall (syscall.S:38)
==1164==    by 0x1149AB: statx (weak.rs:90)
==1164==    by 0x1149AB: std::sys::unix::fs::try_statx (fs.rs:132)
==1164==    by 0x11430E: std::sys::unix::fs::stat (fs.rs:995)
==1164==    by 0x10C43B: std::fs::metadata (in /home/ubuntu/example)
==1164==    by 0x10CBB2: example::main (in /home/ubuntu/example)
==1164==    by 0x10C382: std::rt::lang_start::{{closure}} (in /home/ubuntu/example)
==1164==    by 0x113082: {{closure}} (rt.rs:52)
==1164==    by 0x113082: std::panicking::try::do_call (panicking.rs:292)
==1164==    by 0x114E39: __rust_maybe_catch_panic (lib.rs:78)
==1164==    by 0x113A7F: try<i32,closure-0> (panicking.rs:270)
==1164==    by 0x113A7F: catch_unwind<closure-0,i32> (panic.rs:394)
==1164==    by 0x113A7F: std::rt::lang_start_internal (rt.rs:51)
==1164==    by 0x10C367: std::rt::lang_start (in /home/ubuntu/example)
==1164==    by 0x10CBEA: main (in /home/ubuntu/example)
==1164==  Address 0x0 is not stack'd, malloc'd or (recently) free'd

Meta

rustc --version --verbose:

$ rustc --version --verbose
rustc 1.41.0 (5e1a79984 2020-01-27)
binary: rustc
commit-hash: 5e1a799842ba6ed4a57e91f7ab9435947482f7d8
commit-date: 2020-01-27
host: x86_64-unknown-linux-gnu
release: 1.41.0
LLVM version: 9.0

rustc +nightly --version --verbose:

rustc 1.43.0-nightly (a29424a22 2020-02-07)
binary: rustc
commit-hash: a29424a2265411dda7d7446516ac5fd7499e2b55
commit-date: 2020-02-07
host: x86_64-unknown-linux-gnu
release: 1.43.0-nightly
LLVM version: 9.0

closed time in 14 days

shepmaster

issue commentrust-lang/rust

Valgrind reports that statx arguments point to unaddressable bytes

Cool. Closing as inactionable.

shepmaster

comment created time in 14 days

more