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.