Clippy tricked me into thinking there wouldn't be much it complained about... but that was a lie.

Most of this is boring but nice to get clippy's consistency I guess. A few things stand out though:

• I added a few Default impls because clippy wanted those. That's a public API addition so perhaps deserves some more careful consideration. We could disable these warnings if better for now. Though if ::new() were to change on these it would also be a public API change so perhaps than no longer being able to use Default or it having different semantics at that point is fine.

• I added a few allow(clippy::should_implement_trait) attributes, clippy complains that those methods have expectations in common traits (std::ops::Add in this case) and should either impl that trait or use different names. I think using different names is probably better here, but that breaks the public API so I'm not doing that.

Happy to squash etc if you'd like, feel free to be critical.

Thanks! I'm struck by how much of this is code that wouldn't have worked in older versions of Rust (which were current when I wrote the bulk of the code). It's interesting to see the evolution of Rust in such a direct way!

This seems fine. I'm not sure that there are really valid semantics for Default here, but considering that new already hands out an empty list this isn't much different.

I'm not morally opposed to this but panic! just reads oddly in the context of tests. (I realize that assert! uses panic! internally.)

This adds some generic CI configuration and runs cargo-fmt on all the code. No code changes made.

For now still allow warnings, since there are a lot of them.

For most of my crates I think I just run cargo test --all and it runs everything I've ever cared about? I'm not sure if there's something covered by cargo doc that doesn't get covered there.

Nope! I cleaned up that test that checked the example in the README that I commented on, and made the description in the README / crate-level docs slightly nicer while I was at it, and I've just released 0.1.2: https://crates.io/crates/spawn-ptrace/0.1.2

Let me know if you encounter any other issues! Thanks again!

Thanks!

As mentioned in https://github.com/luser/spawn-ptrace/pull/2#discussion_r505879852 :slightly_smiling_face:

Hi there! Thanks for making this crate.

I was looking at using it on a research project that I'm working on, and I noticed that it was no longer compiling correctly. I've taken the liberty of bringing it up to date with the latest nix release and giving it a pass through cargo fmt. I confirmed locally that the tests still pass.

The external-facing API hasn't changed at all.

Please let me know if there's anything else I can do!

Oh, we should remove this whole file and replace it with the doc-comment crate: https://crates.io/crates/doc-comment (you don't have to do that now, but I just noted this on a PR on another crate of mine so it's in my head).

You could write this more concisely as ptrace::traceme().map_err(|e| { // the err case you have below }) I'm not hung up on it enough to even use the review suggestion tool to rewrite it for you, so you can fix it in a followup if you're motivated or it can be what it is. :)

Is this split out to a separate job because that's how it currently is in the Travis config? I'm fuzzy on the details but looking at it I think it's only written that way because the docmatic crate had some problems, and I believe I'm only using that to test the examples in the README:

What would you think about swapping that out for the doc-comment crate (it's trivial to use), running cargo test --all in the test job above, and removing this separate doctest job? https://docs.rs/doc-comment/0.3.3/doc_comment/

If this isn't going to also run the doc upload script like the Travis config does then it's not really worth running this. I'm fine with dropping that entirely, I don't look at the nightly docs and I doubt anyone else does. docs.rs exists for releases and it's simple enough to run cargo doc locally for master.

This isn't incredibly important, but I did write a proof of concept implementation of this a while ago that I stumbled upon, it's on the dump-command-line branch: https://github.com/luser/rust-minidump/commit/4f6eae86dd16f0aaf0b6a8056989d76b691a9934 https://github.com/luser/rust-minidump/commits/dump-command-line

It requires traversing a series of undocumented NT kernel structures in the minidump memory. I can't recall if it even actually worked given the memory that's available in a minidump.

I had a WIP change to add this sitting in my local tree: https://github.com/luser/rust-minidump/tree/misc-info-5

I don't think it worked, but I can't remember why at the moment.

The breakpad-symbols crate in this repository is not feature complete and likely never will be at this rate. Sentry's symbolic crate has support for reading Breakpad symbol files along with a variety of other debug info formats. We should just remove the breakpad-symbols crate from this tree and use symbolic directly.

Thank you!

Thanks! I should have actually looked at this more closely but I think I merged that update on top of the scroll bustage...

https://github.com/luser/rust-minidump/pull/97 updated the reqwest version which by default uses async code now. Migrate to the blocking client feature instead.

The new scroll dependency introduced in https://github.com/luser/rust-minidump/pull/101 has slightly simplified traits. Adapt the code to work with these.

As a procedural note, it might be helpful to exhaustively enumerate all the cases we expect this crate to be able to handle gracefully, what's currently supported / needs work, and where new functionality might want to exist. Off the top of my head I can think of:

• ELF binaries with DWARF:
  • The simple case, full debug info in the binary (-g)
  • Traditional debug info in a separate file where everything has been compiled and linked as usual, and then objdump is used to create a separate file containing only debug info, and a .gnu_debuglink section is added, or the ELF Build ID is used to locate the separate file
  • Split DWARF, binary contains references to debug info in the .dwo files alongside the original object files (-gsplit-dwarf)
    • Utilizing the .gdb_index section, or the newer DWARF 5 .debug_names + .debug_str sections if present, as an optimization
  • Split DWARF where the .dwo files have been packaged into a .dwp file
• Mach-O binaries with DWARF:
  • Debug info in the original object files with the stabs index in the binary (as discussed in this issue)
  • Debug info in a separate file in a .dSYM bundle, the result of running dsymutil
• Windows PE with PDB debug info:
  • Standard PDB referenced in the PE debug headers containing full debug info
  • PDB referenced in the PE debug headers but with most debug info as references to PDB files next to individual object files (/DEBUG:FASTLINK)

Create a hashmap of archive mmaps that can be reused, and use reference counting to determine when they can be freed.

I think this strategy, or something like it, to at least avoid mapping the same archive multiple times, is worthwhile.

The object is specified by an N_OSO symbol

Is there already a crate that handles parsing stabs debug info? I can't recall seeing one, but it is an old and relatively unused format so that doesn't surprise me. It's also not terribly complicated and the set of stabs you actually need to support for handling the macOS case is not that large.

It is probably worthwhile to at least ensure that whatever you design here won't need major changes to work with DWARF split debuginfo, since that would be a valuable addition.

This feels like an awkward band-aid papering over the actual problem, honestly. It's obviously simpler than fixing the underlying issue but pushing this complexity onto users doesn't feel great. Making the cache creation code async so that LRUDiskCache could do the full scan on a background thread would be much nicer.

Updates the requirements on reqwest to permit the latest version. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/seanmonstar/reqwest/releases">reqwest's releases</a>.</em></p> <blockquote> <h2>v0.10.8</h2> <ul> <li>Add <code>must_use</code> to <code>RequestBuilder</code> and <code>ClientBuilder</code>.</li> <li>Fix Windows system proxy detection of Fiddler proxies.</li> <li>(wasm) Add <code>headers</code> method to <code>RequestBuilder</code>.</li> <li>(wasm) Add <code>execute</code> method to <code>Client</code>.</li> <li>(wasm) Add <code>TryFrom<http::Request></code> for <code>Request</code>.</li> <li>(wasm) Fix checking for global <code>window</code> to work in non-browser environments.</li> <li>(wasm) Fix sending of an empty body when not required.</li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/seanmonstar/reqwest/blob/master/CHANGELOG.md">reqwest's changelog</a>.</em></p> <blockquote> <h2>v0.10.8</h2> <ul> <li>Add <code>must_use</code> to <code>RequestBuilder</code> and <code>ClientBuilder</code>.</li> <li>Fix Windows system proxy detection of Fiddler proxies.</li> <li>(wasm) Add <code>headers</code> method to <code>RequestBuilder</code>.</li> <li>(wasm) Add <code>execute</code> method to <code>Client</code>.</li> <li>(wasm) Add <code>TryFrom<http::Request></code> for <code>Request</code>.</li> <li>(wasm) Fix checking for global <code>window</code> to work in non-browser environments.</li> <li>(wasm) Fix sending of an empty body when not required.</li> </ul> <h2>v0.10.7</h2> <ul> <li>Add <code>NO_PROXY</code> environment variable support.</li> <li>Add more <code>Error::{is_request, is_body, is_decode}</code> getters.</li> <li>Add conversion of <code>reqwest::ClientBuilder</code> to <code>reqwest::blocking::ClientBuilder</code>.</li> <li>Add <code>headers_mut()</code> to <code>reqwest::blocking::Response</code>.</li> <li>(wasm) Add <code>form()</code>, <code>query()</code>, <code>multipart</code> and <code>bearer_auth()</code> to <code>RequestBuilder</code>.</li> </ul> <h2>v0.10.6</h2> <ul> <li>Changed handling of URLs that don't have <code>http:</code> or <code>https:</code> schemes, returning an error instead.</li> <li>Fixed a potential hyper-rustls feature conflict.</li> </ul> <h2>v0.10.5</h2> <ul> <li>Add <code>ClientBuilder::pool_idle_timeout</code> option.</li> <li>Add <code>ClientBuilder::pool_max_idle_per_host</code> option, deprecate <code>max_idle_per_host</code>.</li> <li>Add <code>Response::content_length</code> for WASM target.</li> <li>Enable TCP_NODELAY by default.</li> <li>Implement <code>TryFrom<http::Request></code> for <code>blocking::Request</code>.</li> <li>Implement <code>TryFrom<http::Request></code> for <code>Request</code>. <ul> <li>Removes <code>From<http::Request></code> for <code>Request</code>.</li> <li>This is technically a breaking change, but was a mistake. It was not valid to convert from an <code>http::Request</code> to a <code>reqwest::Request</code> in an infallible fashion. It would panic if the conversion was not possible. Instead, the implementation has been changed to <code>TryFrom</code> to indicate it could fail.</li> </ul> </li> </ul> <h2>v0.10.4</h2> <ul> <li>Add <code>trust-dns</code> optional feature to change DNS resolver.</li> <li>Add <code>bytes()</code> method to <code>reqwest::blocking::Response</code>.</li> <li>Add <code>buffer()</code> method to <code>reqwest::blocking::Body</code>.</li> <li>Implement <code>From<http::Request></code> for <code>reqwest::Request</code>.</li> </ul> <h2>v0.10.3</h2> <ul> <li>Upgrade internal <code>rustls</code> version.</li> </ul> <h2>v0.10.2</h2> <ul> <li>Add Brotli support, enabled with the optional <code>brotli</code> feature.</li> <li>Add <code>Client::use_preconfigured_tls(tls_connector)</code> allowing manual configuration of TLS options.</li> <li>Implement <code>Default</code> for blocking <code>Client</code>, <code>ClientBuilder</code>, and <code>multipart::Form</code>.</li> </ul> <!-- raw HTML omitted --> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/seanmonstar/reqwest/commit/7ef8e94250634e306d398e4f369d2f86e3f075ed"><code>7ef8e94</code></a> v0.10.8</li> <li><a href="https://github.com/seanmonstar/reqwest/commit/db24d5409730397645c076142dc0119955e7a8a4"><code>db24d54</code></a> Add must_use to ClientBuilder & RequestBuilder (<a href="https://github-redirect.dependabot.com/seanmonstar/reqwest/issues/1011">#1011</a>)</li> <li><a href="https://github.com/seanmonstar/reqwest/commit/d42385e7f2cc364efa5e16a7154e7e0cebdd1b57"><code>d42385e</code></a> wasm: Omit request body if it's empty (<a href="https://github-redirect.dependabot.com/seanmonstar/reqwest/issues/1012">#1012</a>)</li> <li><a href="https://github.com/seanmonstar/reqwest/commit/9e23103371c6e35182c8851dd839133ca4c09606"><code>9e23103</code></a> Fix detection of system proxy from Windows registry (<a href="https://github-redirect.dependabot.com/seanmonstar/reqwest/issues/1005">#1005</a>)</li> <li><a href="https://github.com/seanmonstar/reqwest/commit/512fb97ffc35376d8569145f8b8b6ce515365729"><code>512fb97</code></a> Use proxy's DNS in TOR example (<a href="https://github-redirect.dependabot.com/seanmonstar/reqwest/issues/1003">#1003</a>)</li> <li><a href="https://github.com/seanmonstar/reqwest/commit/7a5c5ed600823ad3e8eca8af374e88b66dc1c25b"><code>7a5c5ed</code></a> Remove non-working example. Postman-echo does not return CORS headers. After ...</li> <li><a href="https://github.com/seanmonstar/reqwest/commit/cff487ff58630cf0ac59f3e46cbf20cf50a28b3f"><code>cff487f</code></a> docsrs: build wasm32-unknown-unknown docs (<a href="https://github-redirect.dependabot.com/seanmonstar/reqwest/issues/998">#998</a>)</li> <li><a href="https://github.com/seanmonstar/reqwest/commit/dd8441fd23dae6ffb79b4cea2862e5bca0c59743"><code>dd8441f</code></a> wasm: impl TryFrom<HttpRequest<!-- raw HTML omitted -->> for Request (<a href="https://github-redirect.dependabot.com/seanmonstar/reqwest/issues/997">#997</a>)</li> <li><a href="https://github.com/seanmonstar/reqwest/commit/ecc863fdacc94e3f2ec1c6cccc42e730063b6b08"><code>ecc863f</code></a> Do not assume that <code>window</code> exists in WASM (<a href="https://github-redirect.dependabot.com/seanmonstar/reqwest/issues/990">#990</a>)</li> <li><a href="https://github.com/seanmonstar/reqwest/commit/83fa93ccafe1ec5044f2edd118006edf4faa28b2"><code>83fa93c</code></a> Make headers method on WASM client for compatibility with async_impl (<a href="https://github-redirect.dependabot.com/seanmonstar/reqwest/issues/991">#991</a>)</li> <li>Additional commits viewable in <a href="https://github.com/seanmonstar/reqwest/compare/v0.9.0...v0.10.8">compare view</a></li> </ul> </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language
• @dependabot badge me will comment on this PR with code to add a "Dependabot enabled" badge to your readme

Additionally, you can set the following in your Dependabot dashboard:

• Update frequency (including time of day and day of week)
• Pull request limits (per update run and/or open at any time)
• Automerge options (never/patch/minor, and dev/runtime dependencies)
• Out-of-range updates (receive only lockfile updates, if desired)
• Security updates (receive only security updates, if desired)

</details>

Updates the requirements on scroll to permit the latest version. <details> <summary>Commits</summary> <ul> <li>See full diff in <a href="https://github.com/m4b/scroll/commits">compare view</a></li> </ul> </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language
• @dependabot badge me will comment on this PR with code to add a "Dependabot enabled" badge to your readme

Additionally, you can set the following in your Dependabot dashboard:

• Update frequency (including time of day and day of week)
• Pull request limits (per update run and/or open at any time)
• Automerge options (never/patch/minor, and dev/runtime dependencies)
• Out-of-range updates (receive only lockfile updates, if desired)
• Security updates (receive only security updates, if desired)

</details>

This is a public field on the Minidump struct, but the API currently forces you to explicitly pull in scroll to use it. It seems reasonable for the crate to export the types which which is uses in public APIs.

That seems fine, yes. I've been historically lazy about ensuring formatting and such on my own personal projects. In my defense this project does predate a lot of Rust tooling. :)

This is a quick workaround to fix compilation on Rust 1.47.0, which was released to the stable channel today. It seems that custom derives no longer resolve the syntax tree correctly when declared in a macro that uses ty matchers. When updated to tt, it works however.

I yet have to pin it down and then potentially report this upstream.

Fixes https://github.com/luser/rust-minidump/issues/100

error[E0277]: the trait bound `[u16; 260]: scroll::ctx::TryFromCtx<'_, _>` is not satisfied
    --> minidump-common/src/format.rs:1322:25
     |
1322 |           #[derive(Clone, Pread, SizeWith)]
     |                           ^^^^^ the trait `scroll::ctx::TryFromCtx<'_, _>` is not implemented for `[u16; 260]`
...
1331 | / multi_structs! {
1332 | |     /// Miscellaneous process information
1333 | |     ///
1334 | |     /// This struct matches the [Microsoft struct][msdn] of the same name.
...    |
1376 | |     }
1377 | | }
     | |_- in this macro invocation
     |
     = help: the following implementations were found:
               <&'a [u8] as scroll::ctx::TryFromCtx<'a, usize>>
     = note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info)

So I definitely understand the motivation here: to distinguish between "iOS Simulator" and "iOS on macOS (Catalyst)" at build time, since they are otherwise both targeting the same CPU and OS.

Looking at the two built-in specs: https://github.com/rust-lang/rust/blob/9cba260df0f1c67ea3690035cd5611a7465a1560/compiler/rustc_target/src/spec/x86_64_apple_ios.rs https://github.com/rust-lang/rust/blob/9cba260df0f1c67ea3690035cd5611a7465a1560/compiler/rustc_target/src/spec/x86_64_apple_ios_macabi.rs

Effectively the only differences are:

1. the llvm_target, which does include the -macabi suffix for the catalyst target
2. The link_env_remove field, which is a quirky internal implementation detail used to determine specific environment variables to remove from compilation that affect LLVM and can get mixed up when cross-compiling.

However I note that target_env is unset for both specs, and the reference for that option describes it as:

Key-value option set with further disambiguating information about the target platform with information about the ABI or libc used.

I think you could make a pretty compelling argument for setting target_env = "macabi" for the Catalyst target, which would then let you distinguish the two by writing things like #[cfg(all(target_os = "ios", target_env = "macabi"))], which is very close to your provided example but avoids defining a new cfg attribute.

To answer my own question, yes it does: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_target/spec/abi/enum.Abi.html

However, this enum seems a lot more like it's describing "calling convention" than "ABI".

However, it would be significantly more useful to also have ability to load the file into a token stream and create a source map for it, so all the spans are assigned properly.

This is #55904

This likely needs upstream rustc changes to make it possible for sccache to know what's happening. There's https://github.com/rust-lang/rust/issues/73921, which proposes adding an API that proc macros could use to indicate that they use external files. If that was added and proc macros like the one mentioned here used it then rustc could list these files in --output=dep-info. sccache already parses that output to use as inputs to the hash key so it could also use it to gather files for distributed compilation.

Side note: this made me realize that this is also currently a caching hazard in that sccache doesn't know to include files like this in the hash, so it could produce incorrect results from the cache.

Does rustc already have the concept of target ABI internally? If not it seems really important to spell out how exactly this is defined. The concept of ABIs is really poorly understood by developers in my experience. Obviously there's a 1:1 mapping of target : ABI, but the inverse mapping is a little fuzzy to me and I'm not sure how useful it is in practice.

For example, I'm not really aware of an existing convention for talking about the "x86-64 System V ABI" despite it being the ABI used in both x86-64 Linux and macOS.

How feasible would it be to allow specifying individual components of the target triple string by keyword inside a target cfg, something like:

#[cfg(target(arch="aarch64", os="none"))]

which would be equivalent to:

#[cfg(all(target_arch="aarch64", target_os="none"))]

?

I definitely agree with the assertion that "matching the entire target with the current set of cfg options is extremely verbose", but I'm not convinced that "allow matching the entire target string directly" is the right way to address that.

This is the biggest drawback in my experience. People will often reach for the most accessible way to target a platform even if it's the wrong one. We saw this a lot in the Firefox codebase where people would use the #ifdef for "using the GTK widget implementation" when they really meant "this is Linux" or other similar things.

I don't think the motivation section provides enough of a compelling argument for why this is desirable. Fleshing this out with specific examples of existing crates that use workarounds to achieve this and why they do so would be useful.

Enough of this has fallen out of my head that I'm not sure I can usefully comment here. @tromey (an actual GDB developer) had some thoughts on this, see #26 for example.

Right, there's really no security model to speak of in sccache as a cache, clients trust the cache storage, and any client that has write access to the cache can store anything they like in there. It was designed first and foremost to serve as a replacement for ccache in CI environments with multiple ephemeral build machines, with a secondary goal to be a ccache replacement for local developers that offered some additional features like MSVC and rustc support.

The key issue from a security perspective is that the cache entries contain compiled object files which clients will link into binaries, and there's a high likelihood that the resulting binaries will get executed on the developers' machines. A sufficiently determined adversary with write access to the cache could store cache entries with malicious code in the object files that could attack developers' machines. Solving that problem is probably out of scope for sccache. There are other projects that exist that would be a better place to start, such as synchronicity.

I'm not familiar enough with how the shared cache model of tools like bazel works to compare, but obviously companies like Google do have internal shared artifact caches, so it seems plausible that there's a configuration that is secure enough to deploy in practice. If such a thing does not require additional security features then it would be reasonable to document what the important security properties are.

Just for the record, the full list of cpu_type_t and cpu_subtype_t values can be found in mach/machine.h: https://opensource.apple.com/source/xnu/xnu-4570.41.2/osfmk/mach/machine.h.auto.html

This means presumably this project is potentially missing out on:

• m68k (seems to be in #3)
• HPPA (PA-RISC, I guess NeXT supported it at some point)
• sparc same deal
• I860 This is absolutely wild
• MC98000 / MC88000 (I guess these are PowerPC?)

Unfortunately the cache implementation is extremely simple and is just keyed by hashes of the compiler inputs etc. so there's no straightforward way to enumerate cache entries and determine what compiler they were produced by. Having metadata like this attached would be useful to serve this kind of use case! sccache was originally primarily designed to be used in CI with an object store as the cache (S3 at Mozilla), so the cache bucket just had expiration rules configured.

This is a duplicate of #87, should have been fixed by #666. In the general case, sccache includes a hash of the compiler binary (or libs in the rustc case) in the cache key, but that didn't work well with rustup. It should be fixed nowadays.

For the initial cut at Rust support we're not handling rustup overrides, since we're caching compiler info purely by compiler path. With rustup, the same compiler binary can invoke different Rust toolchains depending on the cwd, so we'll have to handle that somehow.

I was thinking of using a two-tier cache where we cache the "is this a Rust compiler?" result in the server code as we currently do, but then internally check for the presence of a rustup binary next to rustc and run rustup which rustc or something in the compile cwd to locate the actual compiler in use, and then have a cache of compilers using that path.

Fixed by #666.

I don't want to bikeshed more as I think this is a valuable addition to std and you've done due diligence here, but I do think that it'd be unfortunate to ship the naive implementation on Linux that overcounts in the face of cpuset. Docker exposes cpuset as an option to docker run, that seems like a very common use case:

$ getconf _NPROCESSORS_ONLN
8
$ docker run -ti --rm ubuntu:19.04 getconf _NPROCESSORS_ONLN
8
$ docker run -ti --rm --cpuset-cpus="0-2" ubuntu:19.04 getconf _NPROCESSORS_ONLN
8
$ docker run -ti --rm --cpuset-cpus="0-2" ubuntu:19.04 /bin/sh -c 'taskset -c -p $$'
pid 1's current affinity list: 0-2

That being said, this is an implementation detail and could be changed after the fact, so I think it would be reasonable to land this and file a followup issue to make the implementation more correct.

Oh, that's interesting! Good catch! I wonder if the sccache server ought to be more judicious about choosing its temp dir? Honoring the environment variable is probably the right thing to do in the general case, but the way that sccache spawns a daemon by way of the compiler wrapper is a bit of an edge case.

This doesn't need to be if let, it could just be if io_err.kind() == io::ErrorKind::AddrInUse {. But furthermore, I believe you could write this as:

match e.downcast_ref::<io::Error>() {
  Some(io_err) if io_err.kind() == io::ErrorKind::AddrInUse => notify_server_startup(&notify, ServerStartup::AddrInUse)?;
  _ => {
    let reason = e.to_string();
    notify_server_startup(&notify, ServerStartup::Err { reason })?;
  }
}

Currently accessing elements in array fields is clunky in JavaScript/TypeScript. From the tutorial:

table Monster {
  // ...
  inventory:[ubyte];  // Vector of scalars.
  // ...
}

The array length and elements are accessed using separate accessor functions:

let invLength = monster.inventoryLength();
let thirdItem = monster.inventory(2);

Given that ES6 supports iteration using for..of it would be nice if arrays could implement the iteration protocol so that code could look more like:

for (let item of monster.inventory) {
  // ...
}

I toyed around with this idea and it would be possible to implement this without breaking backwards compatibility with the existing API by adding a Symbol.iterator property to the function itself. Small self-contained proof of concept:

class C {
	constructor(numbers) {
  	this._numbers = numbers;
    this.numbers[Symbol.iterator] = () => {
			const nums = this._numbers;
      let current = 0;
    	return {
      	next() {
        	if (current >= nums.length) {
          	return {
            	value: undefined,
              done: true,
            };
          }
          return {
          	value: nums[current++],
            done: false,
          }
        }
      };
    };
  }
  numbers(i) {
  	return this._numbers[i];
  }
}

let c = new C([1,2,3]);
console.log(c.numbers(0));
for (let x of c.numbers) {
	console.log(x);
}

or slightly fancier using a getter:

class C {
	constructor(numbers) {
  	this._numbers = numbers;
  }
  get numbers() {
  	let f = i => this._numbers[i];
    f[Symbol.iterator] = () => {
    	const nums = this._numbers;
      let current = 0;
    	return {
      	next() {
        	if (current >= nums.length) {
          	return {
            	value: undefined,
              done: true,
            };
          }
          return {
          	value: nums[current++],
            done: false,
          }
        }
      };
    };
    return f;
  }
}

let c = new C([1,2,3]);
console.log(c.numbers(0));
for (let x of c.numbers) {
	console.log(x);
}