Since unsoundness is a property of an interface, that private safe function would be unsound but could be used as part of the implementation details of a sound public API.
It's not something I would do personally, and would be something I'd put down as a black mark against using a library as a dependency, but it's nowhere near as bad as doing the same thing on a public API.
Then your code calling `pre_exec` is unsound, it is calling into `foo1` which is not documented to be async-signal-safe. Without any documentation saying otherwise you can't assume a function can be called within weird contexts with non-standard restrictions, and if they update to do something like add an allocation that causes your code to be UB, that's allowed by their documented API.
If you're improving the UI around here it would also be good to see how the list was determined. For automated detection in particular it seems like the tooling used also should be made public to allow testing. I know of at least one dependency that I would expect to turn up on sentry's list that doesn't. (A first guess: a bug in how you handle Rust workspaces, using the root to calculate dependency depth; alternatively a bug in your handling of non-lowercase github usernames, I notice there are only lowercase usernames in the list, but that might just be an artifact of your UI design).
The hash you have is computed from the hash of the content and other data. You would need to send that additional data out-of-band to allow the client to compute the overall hash and verify it. (Not to mention with urls like ipfs://<hash>/some/path you only have the hash of some arbitrary parent node, so there's even more additional data necessary to be able to verify that the content at that path under the hash you have is valid).
JS being required for the interactive features would be fine. My personal problem is that I end up on some random gitlab instance to just take a look at the source or issues for some library, and get a blank white page. For the read-only public view there should be no need for any JS.
Though IIRC from some bugginess I was noticing a while ago, only to the JS API, it will still obey the dark color scheme media query (but sometimes inconsistently, I would load the same page in multiple tabs and sometimes get dark or light schemes).
A good one-time-sign-in-link implementation will send a link to authenticate a session elsewhere, so you can click the link on your phone to complete login on the computer.
Yes, this is basically erasing type invariants by moving them into runtime code. Similar things have been done with things like GPIO pins in embedded code, having the pin numbers carried in the type (`struct Pin1;`) and being able to erase those for collections by moving them to runtime (`struct Pin { id: u8 }`). Unfortunately it comes with a bunch of extra implementation overhead currently, maybe in the future with const-generics it would be possible to reduce this overhead (that would end up being closer to some sort of merge between the first example and the "future directions") .
Wow, did not expect to see grarr mentioned on HN. I should mention that it's basically dead at this point, and IMO would need a full rewrite to resurrect (the web framework it's built on is unmaintained and has been superseded by much nicer ones, the templating it uses is based on a compiler plugin that only works with a few years old nightly compiler).
The long term plan is to make assert! smart enough to recognise the assertion and provide good error messages based on its shape, maybe eventually deprecating assert_eq! etc.
I have a feeling that's a bug. I have an app that I want to have background location and was asked twice soon after upgrading to iOS 13, then iOS was silent for about a month, then started popping up a prompt for it 2 or 3 times a day for half a week. After restarting it stopped popping up again, so it seems likely that something was broken about saving whether it had prompted for that app.
non_exhaustive only affects downstream code, within the crate you can still treat it exhaustively. For example in this playground[0] if you build in test mode the match works inside the crate, but fails in the doc-test because that is treated as external code.
In your link there is a photo of what looks to me like a school hall that could very easily be a cropped and color changed version of a photo included in the OP (/vice-versa).
And yet iOS calendar is also more powerful in that you can set different time zones on the start and end of a single event, which macOS calendar will show but not let you edit.
The standard separator for build metadata fields is a period, since the section is ignored for version comparison it doesn’t really matter, but the spec does specify it (and some tools may display separate fields differently).
What cokml19 said, it’s all about minimising the work. This is just a normal Jekyll site hosted on github pages, but with just minimal css and js inlined into the page. There are actually a few more lines of js hidden around the place, e.g. for adding the “play” buttons onto the code snippets, but it’s all simple library-less code.
The actual Future implementation comes from std, std::future::from_generator takes a generator with the right associated types and turns it into a future.
Yep, the generator created by quote_encrypt_unquote is creating internal self-references from the future created by read_to_end into the AsyncRead it's storing in its environment, while this is happening the AsyncRead must not move and therefore the generator must not move, which is what pinning represents.
Tried to clarify this, it's not that C# and JS are implemented as CPS-like, rather that that's how they're commonly explained; and because of the GC this difference is not really externally visible, whereas with borrowing in Rust it would be.
Definitely. We’re currently blocked with the builtin await using thread local storage, but that’s planned to be removed and replaced with something that will work without an OS before stabilisation.
I have had the old macro based async code in Rust running on a Cortex M device, completely runtime free. Once the TLS stuff is sorted I plan to port this forward to work with the builtin syntax.