sebcrozet / instant Goto Github PK

View Code? Open in Web Editor NEW

107.0 107.0 39.0 7.58 MB

A std::time::Instant replacement that works on WASM too.

License: BSD 3-Clause "New" or "Revised" License

Rust 100.00%

instant's People

Contributors

Stargazers

Watchers

instant's Issues

Cargo Features for WASM environments are sub-optimal.

Having exploited the instant crate in my toy WebAssembly game that I've been playing around with, I have come to the conclusion that the way that Cargo features are defined for this crate is a little sub-optimal for two reasons:

They're not self documenting. That is to say, if one intends to target wasm32 using wasm-bindgen and expects that instant will, therefore, use the JavaScript performance.now(), one MUST express the wasm-bindgen feature flag for instant (similarly, for stdweb) but the requirement to do so is easy to miss and missing it results in a rather obtuse error related to JavaScript module imports, at runtime.
Cargo feature flags are supposed to be strictly additive. The Cargo Book says: "...enabling a feature should not disable functionality..." The existence of the inaccurate feature directly contravenes this recommendation and is, for me, an issue because my use-case requires accurate, high-precision performance counters and thus requires me to be sure that inaccurate will not be set.
- Tangent: I didn't go to all that trouble setting COOP / COEP headers just for another Cargo dep. to sink my timer precision!

I'm happy to help fix this and submit a merge request, improving the use of feature flags, but I am not entirely sure how this should or even could be done, without introducing breaking changes to the crate. My first thought was to handle the first problem with a compilation warning that could be dismissed by setting a feature -- perhaps named js-extern-now -- indicating that the user did, indeed, expect instant to find now() as a JS extern. To handle case 2, perhaps introducing a precise feature which overrides (or conflicts) with inaccurate would help but that seems somewhat messy.

`stdweb` feature no longer builds?

Hi, I noticed recently while working on winit that it no longer builds in the stdweb configuration due to this crate. Building instant directly yields (rustc 1.38.0 (625451e37 2019-09-23)):

PS D:\code\instant> cargo build --target wasm32-unknown-unknown --features stdweb
   Compiling instant v0.1.2 (D:\code\instant)
error[E0433]: failed to resolve: use of undeclared type or module `wasm_bindgen`
  --> src\wasm.rs:92:13
   |
92 |     let v = js! { return performance.now(); };
   |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ use of undeclared type or module `wasm_bindgen`
   |
   = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)

error[E0433]: failed to resolve: use of undeclared type or module `WasmDescribe`
  --> src\wasm.rs:92:13
   |
92 |     let v = js! { return performance.now(); };
   |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ use of undeclared type or module `WasmDescribe`
   |
   = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)

error[E0425]: cannot find function `inform` in this scope
  --> src\wasm.rs:92:13
   |
92 |     let v = js! { return performance.now(); };
   |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in this scope
   |
   = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)

error[E0425]: cannot find value `FUNCTION` in this scope
  --> src\wasm.rs:92:13
   |
92 |     let v = js! { return performance.now(); };
   |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in this scope
   |
   = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)

error: aborting due to 4 previous errors

Some errors have detailed explanations: E0425, E0433.
For more information about an error, try `rustc --explain E0425`.
error: Could not compile `instant`.

To learn more, run the command again with --verbose.

This was working in the past (sorry! I don't know exactly when!) and I noticed this in the last week or so. I'm pretty confident the stdweb and wasm-bindgen versions don't matter here, as I've tried older versions with the same results.

Adding an explicit dependency in instant's Cargo.toml to wasm-bindgen seems to solve the problem, but I'm mostly confused that (as far as I know) nothing changed to cause this break...?

Edit: I just realized I may have upgraded rust itself in between this working and not. Looking through the changelog, maybe rust-lang/cargo#6860 could cause a change here? But 1.36.0 was released in July and the last successful CI build for instant ran when 1.1.2 released earlier this month. 😕

Proposal: remove optional dependency on obsolete `time` 0.2

I had another idea for an easy win for this crate: on non-WASM targets, instant has an optional dependency on an obsolete build of the time crate (version 0.2) if the now feature is enabled, all to get the use of time::precise_time_s() which is just a one-liner, calling std::time::SystemTime, which is in std, anyway. time::precise_time_s() is also deprecated and, presumably because now adds the extra burden of a dependency on the time crate, now is an optional feature. I propose:

Inlining the trivial implementation of time::precise_time_s() into instant::native::now()
- It's trivial and relies only on std: https://docs.rs/time/0.2.27/src/time/lib.rs.html#547-553
- It's deprecated in time, anyway, and gone in 0.3 and up.
- It removes the obsolete time 0.2 dependency.
Removing the now feature, making instant::now() always available, not optional.
- Simplifies the usage notes for instant.
- No longer imposes any cost at all, since it adds no dependencies.

I'll do it. Just say yea or nay... and, also, whether I should actually whack now as a feature in Cargo.toml, under [features], or leave it there, having no effect, to avoid introducing a breaking change. I did it, anyway. Please review.

Release 0.1.2

Would be nice to have a release of this lib to propagate the fix for #4. Particularly winit isn't working right now on web because of this.

instant now() does not work from within web workers using wasm-bindgen

When running within a web worker, there is no Window object available, and so the call to web_sys::window() from the instant now() implementation when using feature wasm-bindgen results in a panic.

A performance.now() implementation is available within the global scope available in a web worker (self), but it is not currently exposed by the web_sys::WorkerGlobalScope implementation. There is an upstream issue regarding this in wasm-bindgen: rustwasm/wasm-bindgen#1752

A fix is to use js-sys to grab the global() context and access the performance implementation directly from that (so that it will work in both main thread and web worker contexts). Hopefully at some point in the future wasm-bindgen will provide a supported way of accessing attributes of the WindowOrWorkerGlobalScope mixin through web-sys that work in both contexts.

I'll work on a PR to implement the immediately available js-sys based fix.

error: undefined symbol: _emscripten_get_now (referenced by top-level compiled C/C++ code)

Hi,

That error shows up when running :

cargo test --release --target=wasm32-unknown-emscripten

Which emsdk should I be using?

cargo.toml warnings

when building this crate I get:

warning: /Users/stephan/code/github/instant/Cargo.toml: Found `feature = ...` in `target.'cfg(...)'.dependencies`. This key is not supported for selecting dependencies and will not work as expected. Use the [features] section instead: https://doc.rust-lang.org/cargo/reference/features.html
warning: /Users/stephan/code/github/instant/Cargo.toml: Found `feature = ...` in `target.'cfg(...)'.dependencies`. This key is not supported for selecting dependencies and will not work as expected. Use the [features] section instead: https://doc.rust-lang.org/cargo/reference/features.html

did something change in cargo and does this break maybe some platforms? I am grasping straws here, investigating my issue with rapier: dimforge/rapier#207

This crates needs to be archived, and should redirect to web-time

Unmaintained
- Bug in implementation not fixed for almost a year #49
Is slow to use Performance #21
More here:
- rust-cv/cv#75 (comment)

Alternative is to change to web-time

Compilation failures

It seems like this crate isn't compatible with various tagets such as:

x86_64-unknown-linux-gnux32:

Compiling instant v0.1.4
error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-mx32" "-L" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnux32/lib" "/home/runner/work/livesplit-core/livesplit-core/target/x86_64-unknown-linux-gnux32/debug/deps/instant-550ae5fa912f454c.instant.abqweb52-cgu.0.rcgu.o" "-o" "/home/runner/work/livesplit-core/livesplit-core/target/x86_64-unknown-linux-gnux32/debug/deps/libinstant-550ae5fa912f454c.so" "-Wl,--version-script=/tmp/rustcMS7AWm/list" "/home/runner/work/livesplit-core/livesplit-core/target/x86_64-unknown-linux-gnux32/debug/deps/instant-550ae5fa912f454c.13ikqv5x1z64tajl.rcgu.o" "-Wl,--gc-sections" "-Wl,-zrelro" "-Wl,-znow" "-nodefaultlibs" "-L" "/home/runner/work/livesplit-core/livesplit-core/target/x86_64-unknown-linux-gnux32/debug/deps" "-L" "/home/runner/work/livesplit-core/livesplit-core/target/debug/deps" "-L" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnux32/lib" "-Wl,--start-group" "-Wl,-Bstatic" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnux32/lib/libstd-702251223b604f84.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnux32/lib/libpanic_unwind-b3ca9fba078e2f61.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnux32/lib/libhashbrown-9a5e3e1c5ec45dd5.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnux32/lib/librustc_std_workspace_alloc-eb52a12b4f508d71.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnux32/lib/libbacktrace-7efbc701b8c23305.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnux32/lib/libbacktrace_sys-6ddf034c50a4d68a.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnux32/lib/librustc_demangle-41ee65a4a9c3bc91.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnux32/lib/libunwind-9beeffcc394003d9.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnux32/lib/libcfg_if-33f9ae0a13c1a688.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnux32/lib/liblibc-ff7b06950e20877e.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnux32/lib/liballoc-4e001b7e791cd89e.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnux32/lib/librustc_std_workspace_core-51a60b0a2181fd75.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnux32/lib/libcore-499c7e2b3c33be99.rlib" "-Wl,--end-group" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnux32/lib/libcompiler_builtins-8c9a60c6d428b275.rlib" "-Wl,-Bdynamic" "-ldl" "-lrt" "-lpthread" "-lgcc_s" "-lc" "-lm" "-lrt" "-lpthread" "-lutil" "-ldl" "-shared"
  = note: /usr/bin/ld: cannot find crti.o: No such file or directory

armv5te-unknown-linux-gnueabi:

Compiling instant v0.1.4
error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-L" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/armv5te-unknown-linux-gnueabi/lib" "/home/runner/work/livesplit-core/livesplit-core/target/armv5te-unknown-linux-gnueabi/debug/deps/instant-c30ea17769597818.instant.1lj3dfed-cgu.0.rcgu.o" "-o" "/home/runner/work/livesplit-core/livesplit-core/target/armv5te-unknown-linux-gnueabi/debug/deps/libinstant-c30ea17769597818.so" "-Wl,--version-script=/tmp/rustcIcG6Ag/list" "/home/runner/work/livesplit-core/livesplit-core/target/armv5te-unknown-linux-gnueabi/debug/deps/instant-c30ea17769597818.1elg5uk5kknzy937.rcgu.o" "-Wl,--gc-sections" "-Wl,-zrelro" "-Wl,-znow" "-nodefaultlibs" "-L" "/home/runner/work/livesplit-core/livesplit-core/target/armv5te-unknown-linux-gnueabi/debug/deps" "-L" "/home/runner/work/livesplit-core/livesplit-core/target/debug/deps" "-L" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/armv5te-unknown-linux-gnueabi/lib" "-Wl,--start-group" "-Wl,-Bstatic" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/libstd-ad37c70b8f5034f7.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/libpanic_unwind-73aaa15f218816c3.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/libhashbrown-a5bf3f69444f613f.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/librustc_std_workspace_alloc-7e20015b8d730e7f.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/libbacktrace-b52e2ce78c8d3d36.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/libbacktrace_sys-bbe9aa043aa55b34.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/librustc_demangle-7c8cc70d44c6f1ce.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/libunwind-8a842ec7048c7394.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/libcfg_if-1c2b804ca5542b4f.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/liblibc-bf6fc08186d861f4.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/liballoc-d18fa1c7b0fb86fc.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/librustc_std_workspace_core-057abc730e843cfc.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/libcore-4a5b81689a4456fb.rlib" "-Wl,--end-group" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/libcompiler_builtins-e6cf897bfa39b5af.rlib" "-Wl,-Bdynamic" "-ldl" "-lrt" "-lpthread" "-lgcc_s" "-lc" "-lm" "-lrt" "-lpthread" "-lutil" "-ldl" "-lutil" "-shared"
  = note: /usr/bin/ld: /home/runner/work/livesplit-core/livesplit-core/target/armv5te-unknown-linux-gnueabi/debug/deps/instant-c30ea17769597818.1elg5uk5kknzy937.rcgu.o: Relocations in generic ELF (EM: 40)
          /usr/bin/ld: /home/runner/work/livesplit-core/livesplit-core/target/armv5te-unknown-linux-gnueabi/debug/deps/instant-c30ea17769597818.1elg5uk5kknzy937.rcgu.o: Relocations in generic ELF (EM: 40)
          /usr/bin/ld: /home/runner/work/livesplit-core/livesplit-core/target/armv5te-unknown-linux-gnueabi/debug/deps/instant-c30ea17769597818.1elg5uk5kknzy937.rcgu.o: Relocations in generic ELF (EM: 40)
          /usr/bin/ld: /home/runner/work/livesplit-core/livesplit-core/target/armv5te-unknown-linux-gnueabi/debug/deps/instant-c30ea17769597818.1elg5uk5kknzy937.rcgu.o: Relocations in generic ELF (EM: 40)
          /usr/bin/ld: /home/runner/work/livesplit-core/livesplit-core/target/armv5te-unknown-linux-gnueabi/debug/deps/instant-c30ea17769597818.1elg5uk5kknzy937.rcgu.o: Relocations in generic ELF (EM: 40)
          /usr/bin/ld: /home/runner/work/livesplit-core/livesplit-core/target/armv5te-unknown-linux-gnueabi/debug/deps/instant-c30ea17769597818.1elg5uk5kknzy937.rcgu.o: Relocations in generic ELF (EM: 40)
          /usr/bin/ld: /home/runner/work/livesplit-core/livesplit-core/target/armv5te-unknown-linux-gnueabi/debug/deps/instant-c30ea17769597818.1elg5uk5kknzy937.rcgu.o: Relocations in generic ELF (EM: 40)
          /usr/bin/ld: /home/runner/work/livesplit-core/livesplit-core/target/armv5te-unknown-linux-gnueabi/debug/deps/instant-c30ea17769597818.1elg5uk5kknzy937.rcgu.o: Relocations in generic ELF (EM: 40)
          /home/runner/work/livesplit-core/livesplit-core/target/armv5te-unknown-linux-gnueabi/debug/deps/instant-c30ea17769597818.1elg5uk5kknzy937.rcgu.o: error adding symbols: File in wrong format

This is likely because the crate is forcefully compiled as cdylib when it really shouldn't.

`SystemTime::elapsed()` is broken

self.duration_since(SystemTime::now()), https://github.com/sebcrozet/instant/blob/master/src/wasm.rs#L202, should be Self::now().duration_since(*self), like Instant.

Add `checked_duration_since`

checked_duration_since was added in Rust 1.39.

https://doc.rust-lang.org/std/time/struct.Instant.html#method.checked_duration_since

`now` exposed when neither `wasm-bindgen` or `stdweb` are available

When neither wasm-bindgen or stdweb features are used, the now function exposes a foreign now function, explicitly making it safe.

This behavior produces the effect that the FFI now is exposed even if wasm::now is never called, just because it is extern "C". Unfortunately, this causes some unexpected issues in other crates. I propose to remove wasm::now if no valid features are available, even if I understand that this is a breaking change.

Another possible solution is to change the behavior of the features in order to activate wasm-bindgen by default if the target is wasm32-unknown-unknown and stdweb is not specified.

I am very open to discussion, even because the rationale behind blindly using an extern now function is not clear to me. If you want I will be happy to open a PR when I have a clearer idea of what's the best thing that could be done.

LICENSE is slightly divergent from BSD-3-CLAUSE

The current version on master (https://github.com/sebcrozet/instant/blob/bdd142135d78387a02dfeaa8d6829a057892aca6/LICENSE) appears to diverge in the wording from the online texts I have found of that license.

https://opensource.org/licenses/BSD-3-Clause

https://spdx.org/licenses/BSD-3-Clause.html

In both of the above online sources, in the part where it says:

3. Neither the name of the copyright holder

The version in this repository says "name of the author" instead of "name of the copyright holder".

I caught that divergence through a tool I am developing for the legal team at my company. Please bear in mind that I don't have licensing knowledge nor can say if the texts are equivalent, just thought I would warn here about this in case it's not intentional.

Thanks for your time.

stdweb hasn't been updated in 5 years and is broken with later versions of wasm-bindgen

see koute/stdweb#427

Release 0.1.4

Hiya, would it be alright to release 0.1.4 for the changes in #16?
Thanks!

1.10 release

can we have a new release so that we can update rapier and fix dimforge/rapier#207 that way?

`wasm-bindgen` feature should override `stdweb`

Since stdweb can work with wasm-bindgen when using wasm-pack but wasm-bindgen does not work with cargo-web, I think it should be safe to assume that, whenever the wasm-bindgen feature is enabled the stdweb feature can be ignored. It can happen that when a crate that depends on instant has enabled the stdweb feature and another has wasm-bindgen enabled, conflicting implementations of now will be included and causes a compile error.

`Instant::elapsed` panics if time goes backwards, when `inaccurate` feature is enabled

STR:

Create an Instant: let now = Instant::now();
Later: check how long has passed now.elapsed();

If system time goes backwards in the intervening period, elapsed will panic:

panicked at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/instant-0.1.12/src/wasm.rs:24:9:
`earlier` cannot be later than `self`.

This seems to be largely because Instant is based on local system time rather than a proper monotonic clock, violating the specification of std::time::Instant. I think if we're going to do that, we need to let Instant::duration_since saturate rather than panic.

Update Instant with Hash trait support

This issue is relative to a winit issue, we are currently not able to build to a wasm32-unknown-unknown target. A pull request was created (and merged) few month ago #10.

Force constant/static time

Sometimes for unit tests or even for reproducible builds one wants to force a specific time to be returned by a call returning something like instant::now().

See https://reproducible-builds.org/docs/source-date-epoch/ for example.

Cannot represent instants before the program start

In one of my projects, I have the necessity of representing an arbitrary instant in time, which include instants before the program start.

The current implementation relies on creating a Duration from performe.now(). Because performe.now() return the time since the creation of the page/web worker, and because Duration cannot represent negative values, the Wasm version of Instant can only represent a small range of past instants.

Code snippets in the README call Instant::new() instead of ::now()

In the README file, also shown on the crates.io page for the crate, there are several erroneous code snippets illustrating how the instant crate is to be used. A recurring error in these snippets is to call instant::Instant::new() instead of instant::Instant::now() -- the former does not compile.

Merge-request incoming in 3...

How to configure a library using instant for wasm/native

This is going to seem like a dumb question, as I think I am just misreading your README.

I have a library (called 'flowrlib') that I want to use instant in, as it is compiled for native with one binary, and for wasm for a web app (which is a library, as I'm using wasm-pack etc to load it in web).

This is how I have configured the flowrlib Cargo.toml:

[features]
stdweb = [ "instant/stdweb" ]
wasm-bindgen = [ "instant/wasm-bindgen" ]

[dependencies]
instant = { version = "0.1", features = [ "now" ] }

(I tried without the stdweb and wasm-bindgen stuff, same problems).

Then I use it in the web library which is compiled to wasm (and hence this compiles flowrlib for wasm also as it is a dependency).

Web library Cargo.toml is thus:

[dependencies]
flowrlib = { path = "../../flowrlib", version = "~0.7.0" }

When I execute the resulting app in the browser I get the ''Time system call is not implemented by WebAssembly host'' message.

I tried also adding the

[features]
stdweb = [ "instant/stdweb" ]
wasm-bindgen = [ "instant/wasm-bindgen" ]

in the web-app library, but I can't as it says:

Caused by:
|   Features and dependencies cannot have the same name: `wasm-bindgen`

as it needs wasm-bindgen as a dependency:

[dependencies]
wasm-bindgen = "0.2.25"

So, my question is double:

how to configure my flowrlib library that uses instant, so that it can be used as a dependency by other libraries/binaries with native and wasm targets
do I need to do anything special in the Cargo.toml of a library consuming 'flowlibr' that is compiled for wasm via wasm-pack or similar

thanks!

Support checked_add/sub.

Heya, I'm using governor, which requires checked_sub in Instant.

instant::wasm::Instant doesn't yet have the checked_* operations, and so I'd like to add them.

Cannot compile `instant` for custom target

Repo to reproduce here: https://github.com/Takashiidobe/rvim/tree/test-building-x86_64-unknown-none

I was trying to compile one of my projects on a generic x86_64 target, which is defined by this target file:

// x86_64-unknown-none.json

{
  "llvm-target": "x86_64-unknown-none",
  "data-layout": "e-m:e-i64:64-f80:128-n8:16:32:64-S128",
  "linker-flavor": "gcc",
  "target-endian": "little",
  "target-pointer-width": "64",
  "target-c-int-width": "32",
  "arch": "x86_64",
  "os": "none",
  "disable-redzone": true,
  "features": "-mmx,-sse,+soft-float",
  "executables": true
}

To do that I ran this command inside of my project to build it:
$ cargo build --target ./x86_64-unknown-none.json

Predictably this outputs an error:

   Compiling cfg-if v1.0.0
   Compiling smallvec v1.7.0
   Compiling scopeguard v1.1.0
   Compiling bitflags v1.3.2
error[E0463]: can't find crate for `core`
  |
  = note: the `x86_64-unknown-none-17810034709879873439` target may not be installed
  = help: consider downloading the target with `rustup target add x86_64-unknown-none-17810034709879873439`
  = help: consider building the standard library from source with `cargo build -Zbuild-std`

For more information about this error, try `rustc --explain E0463`.
error: could not compile `scopeguard` due to previous error
warning: build failed, waiting for other jobs to finish...
error: build failed

So I need to build the stdlib. I did this by swapping to nightly:
$ rustup default nightly
and then running this:
$ cargo build -Z build-std --target ./x86_64-unknown-none.json

which outputs this:

Compiling compiler_builtins v0.1.49
   Compiling core v0.0.0 (/Users/takashi/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/core)
   Compiling libc v0.2.106
   Compiling cc v1.0.69
   Compiling memchr v2.4.1
   Compiling std v0.0.0 (/Users/takashi/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/std)
   Compiling parking_lot_core v0.8.5
   Compiling unwind v0.0.0 (/Users/takashi/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/unwind)
   Compiling rustc-std-workspace-core v1.99.0 (/Users/takashi/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/rustc-std-workspace-core)
   Compiling alloc v0.0.0 (/Users/takashi/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/alloc)
   Compiling cfg-if v0.1.10
   Compiling adler v0.2.3
   Compiling rustc-demangle v0.1.21
   Compiling rustc-std-workspace-alloc v1.99.0 (/Users/takashi/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/rustc-std-workspace-alloc)
   Compiling panic_unwind v0.0.0 (/Users/takashi/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/panic_unwind)
   Compiling panic_abort v0.0.0 (/Users/takashi/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/panic_abort)
   Compiling gimli v0.25.0
   Compiling object v0.26.2
   Compiling hashbrown v0.11.0
   Compiling std_detect v0.1.5 (/Users/takashi/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/stdarch/crates/std_detect)
   Compiling miniz_oxide v0.4.0
   Compiling addr2line v0.16.0
   Compiling proc_macro v0.0.0 (/Users/takashi/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/proc_macro)
   Compiling cfg-if v1.0.0
   Compiling scopeguard v1.1.0
   Compiling smallvec v1.7.0
   Compiling bitflags v1.3.2
   Compiling unicode-segmentation v1.8.0
   Compiling instant v0.1.12
   Compiling lock_api v0.4.5
error[E0658]: use of unstable library feature 'restricted_std'
  |
  = help: add `#![feature(restricted_std)]` to the crate attributes to enable

For more information about this error, try `rustc --explain E0658`.
error: could not compile `instant` due to previous error
warning: build failed, waiting for other jobs to finish...
error: build failed

I'm guessing this can be fixed by adding #![feature(restricted_std)] at the crate root for either this project or a dependent, but I'm not sure how this works in practice.

If nightly support and custom targets aren't a priority, feel free to close.
If this is coming from somewhere else, I can move the issue over there.

Thanks :)

wasm32-unknown-emscripten
wasm32-unknown-unknown
wasm32-wasi

Both wasm32-wasi and wasm32-unknown-emscripten have working Instant types in libstd, so this crate should only enable the custom Instant type for wasm32-unknown-unknown.

Invalid or corrupt file when "releasing" on MSVC

For a tiny program like this:

fn main() {
  println!("{:?}", instant::Duration::from_secs(1));
}

when running in debug mode, nothing bad happens, but when I run in release mode, I got this error:

  = note: LINK : warning LNK4044: unrecognized option '/s'; ignored
          [hidden]\tiny-ffmpeg-gui\target\release\deps\instant-bce189fdb2307e6a.instant.dt1bllbr-cgu.0.rcgu.o : fatal error LNK1107: invalid or corrupt file: cannot read at 0x55C


error: aborting due to previous error

error: could not compile `instant`.

sebcrozet / instant Goto Github PK

instant's People

Contributors

Stargazers

Watchers

Forkers

instant's Issues

Recommend Projects

Recommend Topics

Recommend Org