profile
viewpoint

js-platform/p2p 267

PeerConnection broker for WebRTC

luser/calendarview 22

HTML calendar viewer

brettz9/dev-assistant 11

Developer Assistant (formerly Extension Developer Extension)

gimli-rs/moria 8

A crate to find DWARF debug symbols from stripped binaries

luser/auto-caption 8

Produce captions for videos using PocketSphinx speech recognition

luser/autoconftopy 3

Insanity

luser/breakpad-mac-update-symbols 3

Scrape symbols from OS X system updates for Breakpad crash reporting

luser/breakpad-scrape-system-symbols 3

Scripts to scrape symbols from system libraries for use with Breakpad crash reporting

luser/asteroids-old 2

Mah pages

luser/breakpad 1

Mirror of Google Breakpad project

fork luser/instantly

Download images from instagram lighting fast (instantly).

fork in 9 days

push eventluser/rust-minidump

Floris Bruynooghe

commit sha b507fba5f6498fdc15fce269b05430b8bf0cb152

Enable all CI This removes some doc comments which didn't do anything anyway and enables all CI.

view details

Floris Bruynooghe

commit sha 4c84ef41c0323ed1a925ba349245c2ff962ae2fe

Remove unused package replacements These are dependencies of some of the workspace crates and are defined in their respective Cargo.toml files. Also, this works with a released scroll by now.

view details

Floris Bruynooghe

commit sha 6fdca84b14e718d77275f6f705e99b95997cd230

Address clippy warnings Functionally nothing changes.

view details

Floris Bruynooghe

commit sha fa59642262e60083809a58267a6c71b43878412d

Followup clippy warnings

view details

Floris Bruynooghe

commit sha 6519357f771c77a56903fdbde8075f2a6bab9a5b

Another round of clippy fixes

view details

Floris Bruynooghe

commit sha 6110b530ba71a5321f4da513bd5488bbfe72e51c

fussy clippy

view details

Floris Bruynooghe

commit sha 0b86daec7ccafb9f360a6277af5fd4fcbaadfe82

Clippy in breakpad-symbols

view details

Floris Bruynooghe

commit sha 625e442a39c1bd0c4182c99dbb4b3de5ee2f9aa1

We need PWD everywhere

view details

Floris Bruynooghe

commit sha c58b43e2574b35c08cfdd6b8b04aa3406148d312

Move env back to steps We do not have the required variables yet at the toplevel and this isn't lazy.

view details

Floris Bruynooghe

commit sha 62ae399184c54c861c8ae89b4f8f5f9417c22a25

Clippy for minidump-processor

view details

Floris Bruynooghe

commit sha ca9719e90baf40401900da56118f14b997c73882

Clippy in minidump-tools

view details

Floris Bruynooghe

commit sha 0759d861d60374379388d587d59b1df645a8b056

Still more clippy errors They just keep coming...

view details

push time in 11 days

PR merged luser/rust-minidump

Enable all CI

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.

+220 -221

1 comment

19 changed files

flub

pr closed time in 11 days

pull request commentluser/rust-minidump

Enable all CI

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!

flub

comment created time in 11 days

Pull request review commentluser/rust-minidump

Enable all CI

 impl MinidumpModuleList {     } } +impl Default for MinidumpModuleList {

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.

flub

comment created time in 11 days

PullRequestReviewEvent

Pull request review commentluser/rust-minidump

Enable all CI

 fn test_processor() {         assert_eq!(raw.eip, 0x0040429e);         assert_eq!(*valid, MinidumpContextValidity::All);     } else {-        assert!(false, "Wrong context type");+        panic!("Wrong context type");

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

flub

comment created time in 11 days

PullRequestReviewEvent

push eventluser/rust-minidump

Ted Mielczarek

commit sha 74a6a5c50ddc1b9b3d0b769d6d56ff882c2068ae

fix formatting

view details

push time in 13 days

push eventluser/rust-minidump

Ted Mielczarek

commit sha d6679f18756c997e2f26d502f0618fba2cd845f4

remove Travis CI config + no-longer-used doc upload scripts, swap Travis badge for GH Actions badge in README

view details

Ted Mielczarek

commit sha 984f6b32e4606d4c9051b667bcf6af4ac88417f8

swap docmatic for doc-comment to test README examples

view details

push time in 13 days

push eventluser/rust-project-docs

doc upload bot

commit sha a803d11ae661799b9112484ea124394d816a2a65

doc upload for minidump (luser/rust-minidump)

view details

push time in 13 days

push eventluser/rust-project-docs

doc upload bot

commit sha 4b970f9e865fd743cd604ef6827e1808f2cb6fff

doc upload for minidump (luser/rust-minidump)

view details

push time in 13 days

push eventluser/rust-minidump

Floris Bruynooghe

commit sha ace026264d2dacdd02ba5939fb7957a35b01481b

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

view details

Floris Bruynooghe

commit sha ab58bd9b9f758d4cd4033fc4c06083ec67f7036a

Disable clippy, spell workspace correctly

view details

Floris Bruynooghe

commit sha 7c4c51dc87602d66c14c59a5519960bc80bd688d

Add caching, don't bother with beta for now Too many jobs, beta isn't that important.

view details

Floris Bruynooghe

commit sha b528419c4f11e02647faaf8072b44f4ebdf3d3fa

Ensure we have PWD set during tests

view details

Floris Bruynooghe

commit sha 8fd671bf4e1cc4484cab1d232286bc2622db2c64

Remove doctests simplify main test run This seems to cover all tests that are written.

view details

Floris Bruynooghe

commit sha d65703096b33c06672308e24d4205995bb2d5070

Add explicit examples and bins tests This runs any tests in examples and binaries, which is nice to have, even though currently there are none.

view details

push time in 13 days

PR merged luser/rust-minidump

Run cargo fmt and add ci

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.

+848 -461

2 comments

27 changed files

flub

pr closed time in 13 days

PullRequestReviewEvent

Pull request review commentluser/rust-minidump

Run cargo fmt and add ci

+name: Rust CI++on:+  pull_request:+  push:+    branches:+      - master+  schedule:+    - cron: '11 7 * * 1,4'++# env:+#   RUSTFLAGS: -Dwarnings+#   RUSTDOCFLAGS: -Dwarnings++jobs:++  fmt:+    runs-on: ubuntu-latest+    steps:+      - uses: actions/checkout@v1+      - uses: actions-rs/toolchain@v1+        with:+          toolchain: stable+          profile: minimal+          components: rustfmt+          override: true+      - uses: actions-rs/cargo@v1+        with:+          command: fmt+          args: --all -- --check++  # clippy:+  #   runs-on: ubuntu-latest+  #   steps:+  #     - uses: actions/checkout@v1+  #     - uses: actions-rs/toolchain@v1+  #       with:+  #           toolchain: stable+  #           profile: minimal+  #           components: clippy+  #           override: true+  #     - uses: actions-rs/clippy-check@v1+  #       with:+  #         token: ${{ secrets.GITHUB_TOKEN }}+  #         args: --workspace --tests --examples++  docs:+    runs-on: ubuntu-latest+    steps:+      - uses: actions/checkout@master+      - uses: actions-rs/toolchain@v1+        with:+          toolchain: nightly+          profile: minimal+          components: rust-docs+          override: true+      - uses: swatinem/rust-cache@v1+        with:+          key: ${{ github.job }}+      - uses: actions-rs/cargo@v1+        with:+          command: doc+          args: --workspace --no-deps++  test:+    runs-on: ${{ matrix.os }}+    strategy:+      matrix:+        os: [ubuntu-latest, windows-latest, macOS-latest]+        rust: [nightly, stable]+    steps:+      - uses: actions/checkout@master+      - uses: actions-rs/toolchain@v1+        with:+          toolchain: ${{ matrix.rust }}+          profile: minimal+          override: true+      - uses: swatinem/rust-cache@v1+        with:+          key: ${{ github.job }}+      - uses: actions-rs/cargo@v1+        with:+          command: test+          args: --workspace --tests --examples --bins+  +  doctest:+    runs-on: ${{ matrix.os }}+    strategy:+      matrix:+        os: [ubuntu-latest, windows-latest, macOS-latest]+        rust: [nightly, beta, stable]+    steps:+      - uses: actions/checkout@master+      - uses: actions-rs/toolchain@v1+        with:+          toolchain: ${{ matrix.rust }}+          profile: minimal+          override: true+      - uses: swatinem/rust-cache@v1+        with:+          key: ${{ github.job }}+      - uses: actions-rs/cargo@v1+        with:+          command: test+          args: --workspace --doc

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.

flub

comment created time in 13 days

PullRequestReviewEvent

pull request commentluser/spawn-ptrace

lib: Simplify error handling slightly

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!

woodruffw

comment created time in 13 days

created tagluser/spawn-ptrace

tag0.1.2

A Rust crate for spawning a Linux process with ptrace enabled

created time in 13 days

push eventluser/spawn-ptrace

Ted Mielczarek

commit sha 8d797a2f4c1d2f1311cbeb051fed68821430da80

(cargo-release) version 0.1.2

view details

Ted Mielczarek

commit sha 55bc49c4017f3efbd796a6e7f2bca61c51d154a2

(cargo-release) start next development iteration 0.1.3-alpha.0

view details

push time in 13 days

push eventluser/spawn-ptrace

Ted Mielczarek

commit sha 760635b8a50b06fc443fa857356a7aaf1f1e0b0a

Use doc-comment to test the README example, switch to 2018 edition, make the README slightly nicer.

view details

push time in 13 days

pull request commentluser/spawn-ptrace

lib: Simplify error handling slightly

Thanks!

woodruffw

comment created time in 14 days

push eventluser/spawn-ptrace

William Woodruff

commit sha 7a29f913ce03e26d4027bb13e70b6ebd2be0a5b2

lib: Simplify error handling slightly

view details

Ted Mielczarek

commit sha f6a805643d82dfb53a0d99fbb702f0bd45611dc6

Merge pull request #3 from trailofbits/ww/qa lib: Simplify error handling slightly

view details

push time in 14 days

PR merged luser/spawn-ptrace

lib: Simplify error handling slightly

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

+4 -10

0 comment

1 changed file

woodruffw

pr closed time in 14 days

push eventluser/spawn-ptrace

William Woodruff

commit sha ce5f150ebebfd70c5cdcd3c3544aaaec53134023

treewide: Modernize nix::sys::ptrace usage

view details

Ted Mielczarek

commit sha e136193e7600866bf772ed840fbca9a66994bd9d

Merge pull request #2 from trailofbits/ww/modernize treewide: Modernize nix::sys::ptrace usage

view details

push time in 14 days

PR merged luser/spawn-ptrace

treewide: Modernize nix::sys::ptrace usage

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!

+49 -30

1 comment

3 changed files

woodruffw

pr closed time in 14 days

Pull request review commentluser/spawn-ptrace

treewide: Modernize nix::sys::ptrace usage

 use std::process::Command; #[test] fn readme_test() {     let rustdoc = Path::new("rustdoc").with_extension(EXE_EXTENSION);-    let readme = Path::new(file!()).parent().unwrap().parent().unwrap().join("README.md");+    let readme = Path::new(file!())

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).

woodruffw

comment created time in 14 days

PullRequestReviewEvent

Pull request review commentluser/spawn-ptrace

treewide: Modernize nix::sys::ptrace usage

 pub trait CommandPtraceSpawn {  impl CommandPtraceSpawn for Command {     fn spawn_ptrace(&mut self) -> Result<Child> {-        let child = self.before_exec(|| {-            // Opt-in to ptrace.-            ptrace(PTRACE_TRACEME, 0, ptr::null_mut(), ptr::null_mut())?;-            Ok(())-        }).spawn()?;+        let child = unsafe {+            self.pre_exec(|| {+                // Opt-in to ptrace.+                match ptrace::traceme() {

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. :)

woodruffw

comment created time in 14 days

PullRequestReviewEvent

Pull request review commentluser/rust-minidump

Run cargo fmt and add ci

+name: Rust CI++on:+  pull_request:+  push:+    branches:+      - master+  schedule:+    - cron: '11 7 * * 1,4'++# env:+#   RUSTFLAGS: -Dwarnings+#   RUSTDOCFLAGS: -Dwarnings++jobs:++  fmt:+    runs-on: ubuntu-latest+    steps:+      - uses: actions/checkout@v1+      - uses: actions-rs/toolchain@v1+        with:+          toolchain: stable+          profile: minimal+          components: rustfmt+          override: true+      - uses: actions-rs/cargo@v1+        with:+          command: fmt+          args: --all -- --check++  # clippy:+  #   runs-on: ubuntu-latest+  #   steps:+  #     - uses: actions/checkout@v1+  #     - uses: actions-rs/toolchain@v1+  #       with:+  #           toolchain: stable+  #           profile: minimal+  #           components: clippy+  #           override: true+  #     - uses: actions-rs/clippy-check@v1+  #       with:+  #         token: ${{ secrets.GITHUB_TOKEN }}+  #         args: --workspace --tests --examples++  docs:+    runs-on: ubuntu-latest+    steps:+      - uses: actions/checkout@master+      - uses: actions-rs/toolchain@v1+        with:+          toolchain: nightly+          profile: minimal+          components: rust-docs+          override: true+      - uses: swatinem/rust-cache@v1+        with:+          key: ${{ github.job }}+      - uses: actions-rs/cargo@v1+        with:+          command: doc+          args: --workspace --no-deps++  test:+    runs-on: ${{ matrix.os }}+    strategy:+      matrix:+        os: [ubuntu-latest, windows-latest, macOS-latest]+        rust: [nightly, stable]+    steps:+      - uses: actions/checkout@master+      - uses: actions-rs/toolchain@v1+        with:+          toolchain: ${{ matrix.rust }}+          profile: minimal+          override: true+      - uses: swatinem/rust-cache@v1+        with:+          key: ${{ github.job }}+      - uses: actions-rs/cargo@v1+        with:+          command: test+          args: --workspace --tests --examples --bins+  +  doctest:+    runs-on: ${{ matrix.os }}+    strategy:+      matrix:+        os: [ubuntu-latest, windows-latest, macOS-latest]+        rust: [nightly, beta, stable]+    steps:+      - uses: actions/checkout@master+      - uses: actions-rs/toolchain@v1+        with:+          toolchain: ${{ matrix.rust }}+          profile: minimal+          override: true+      - uses: swatinem/rust-cache@v1+        with:+          key: ${{ github.job }}+      - uses: actions-rs/cargo@v1+        with:+          command: test+          args: --workspace --doc

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/

flub

comment created time in 14 days

Pull request review commentluser/rust-minidump

Run cargo fmt and add ci

+name: Rust CI++on:+  pull_request:+  push:+    branches:+      - master+  schedule:+    - cron: '11 7 * * 1,4'++# env:+#   RUSTFLAGS: -Dwarnings+#   RUSTDOCFLAGS: -Dwarnings++jobs:++  fmt:+    runs-on: ubuntu-latest+    steps:+      - uses: actions/checkout@v1+      - uses: actions-rs/toolchain@v1+        with:+          toolchain: stable+          profile: minimal+          components: rustfmt+          override: true+      - uses: actions-rs/cargo@v1+        with:+          command: fmt+          args: --all -- --check++  # clippy:+  #   runs-on: ubuntu-latest+  #   steps:+  #     - uses: actions/checkout@v1+  #     - uses: actions-rs/toolchain@v1+  #       with:+  #           toolchain: stable+  #           profile: minimal+  #           components: clippy+  #           override: true+  #     - uses: actions-rs/clippy-check@v1+  #       with:+  #         token: ${{ secrets.GITHUB_TOKEN }}+  #         args: --workspace --tests --examples++  docs:+    runs-on: ubuntu-latest+    steps:+      - uses: actions/checkout@master+      - uses: actions-rs/toolchain@v1+        with:+          toolchain: nightly+          profile: minimal+          components: rust-docs+          override: true+      - uses: swatinem/rust-cache@v1+        with:+          key: ${{ github.job }}+      - uses: actions-rs/cargo@v1+        with:+          command: doc

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.

flub

comment created time in 14 days

PullRequestReviewEvent
PullRequestReviewEvent

startedlark-parser/lark

started time in 15 days

push eventluser/rust-project-docs

doc upload bot

commit sha b4f598a09effcae12b2fc622a6ab9c183ae96e9f

doc upload for minidump (luser/rust-minidump)

view details

push time in 16 days

issue openedluser/rust-minidump

Support extracting commandline arguments from Windows dumps

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.

created time in 16 days

issue commentluser/rust-minidump

Support MINIDUMP_MISC_INFO_5

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.

luser

comment created time in 16 days

create barnchluser/rust-minidump

branch : misc-info-5

created branch time in 16 days

issue openedluser/rust-minidump

Remove breakpad-symbols crate, use symbolic instead

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.

created time in 16 days

pull request commentluser/rust-minidump

Fixes for updated scroll dependency

Thank you!

flub

comment created time in 16 days

pull request commentluser/rust-minidump

Fixes for new reqwest version

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

flub

comment created time in 16 days

push eventluser/rust-minidump

Floris Bruynooghe

commit sha cff87d576a01215aa69eb3f0595e7bdf1a2dda9a

Fixes for new request version 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.

view details

push time in 16 days

PR merged luser/rust-minidump

Fixes for new reqwest version

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.

+5 -4

0 comment

4 changed files

flub

pr closed time in 16 days

push eventluser/rust-minidump

Floris Bruynooghe

commit sha a3a7f42987dbb58d24bd9e78c04dded979c934ea

Fixes for updated scroll dependency 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.

view details

push time in 16 days

PR merged luser/rust-minidump

Fixes for updated scroll dependency

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.

+7 -10

0 comment

2 changed files

flub

pr closed time in 16 days

PullRequestReviewEvent

issue commentrust-lang/backtrace-rs

Support for split debuginfo

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)
philipc

comment created time in 17 days

issue commentrust-lang/backtrace-rs

Support for split debuginfo

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.

philipc

comment created time in 17 days

pull request commentmozilla/sccache

server: support a configurable timeout

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.

mathstuf

comment created time in 17 days

push eventluser/rust-minidump

dependabot-preview[bot]

commit sha 61f4c617c925e5d1408527acd0a0ce0df309ba9c

Update reqwest requirement from 0.9.0 to 0.10.8 Updates the requirements on [reqwest](https://github.com/seanmonstar/reqwest) to permit the latest version. - [Release notes](https://github.com/seanmonstar/reqwest/releases) - [Changelog](https://github.com/seanmonstar/reqwest/blob/master/CHANGELOG.md) - [Commits](https://github.com/seanmonstar/reqwest/compare/v0.9.0...v0.10.8) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>

view details

push time in 17 days

PR merged luser/rust-minidump

Update reqwest requirement from 0.9.0 to 0.10.8 dependencies

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>

+2 -2

0 comment

2 changed files

dependabot-preview[bot]

pr closed time in 17 days

push eventluser/rust-project-docs

doc upload bot

commit sha 98ad5cd4450d4d92abaa10985345482f07998e28

doc upload for minidump (luser/rust-minidump)

view details

push time in 17 days

push eventluser/rust-project-docs

doc upload bot

commit sha f2ee1f5614274b06bb5454a7240ed94ca0846b4a

doc upload for minidump (luser/rust-minidump)

view details

push time in 17 days

push eventluser/rust-minidump

dependabot-preview[bot]

commit sha af7433c104ab14c0295e7072c8d38832f16d91b6

Update scroll requirement from 0.9.0 to 0.10.2 Updates the requirements on [scroll](https://github.com/m4b/scroll) to permit the latest version. - [Release notes](https://github.com/m4b/scroll/releases) - [Changelog](https://github.com/m4b/scroll/blob/master/CHANGELOG.md) - [Commits](https://github.com/m4b/scroll/commits) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>

view details

push time in 17 days

PR merged luser/rust-minidump

Update scroll requirement from 0.9.0 to 0.10.2 dependencies

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>

+2 -2

0 comment

2 changed files

dependabot-preview[bot]

pr closed time in 17 days

push eventluser/rust-minidump

Floris Bruynooghe

commit sha fad6ff6203daff56b842af8673b29ec59fc2a8ad

Re-export scroll::Endian 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.

view details

push time in 17 days

PR merged luser/rust-minidump

Re-export scroll::Endian

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.

+3 -1

0 comment

1 changed file

flub

pr closed time in 17 days

Pull request review commentluser/rust-minidump

Re-export scroll::Endian

 pub mod synth_minidump; pub mod system_info;  pub use iostuff::Readable;+pub use minidump::*;

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. :)

flub

comment created time in 17 days

PullRequestReviewEvent
PullRequestReviewEvent

push eventluser/rust-project-docs

doc upload bot

commit sha 5f544b2de52439d614224c56a78a5e930f6cb3d1

doc upload for minidump (luser/rust-minidump)

view details

push time in 21 days

push eventluser/rust-project-docs

doc upload bot

commit sha 27b83c71358d10e24e35253525c348d8fd4a157b

doc upload for minidump (luser/rust-minidump)

view details

push time in 21 days

push eventluser/rust-minidump

Jan Michael Auer

commit sha f8a18211dbb0bf7dca5dd41e578af4b366fcb9be

Change multi_structs macro to compile on 1.47.0

view details

push time in 21 days

PR merged luser/rust-minidump

Change multi_structs macro to compile on 1.47.0

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

+1 -1

1 comment

1 changed file

jan-auer

pr closed time in 21 days

issue closedluser/rust-minidump

Does not compile with Rust 1.47.0

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)

closed time in 21 days

jan-auer

startedkoute/not-perf

started time in 21 days

PullRequestReviewEvent

push eventluser/handsup

Ted Mielczarek

commit sha 1b33f62c8c81dde87aa910f31c3ef150cd341ca3

some fixup

view details

push time in a month

pull request commentrust-lang/rfcs

RFC: Add `target_abi` configuration

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.

nvzqz

comment created time in a month

Pull request review commentrust-lang/rfcs

RFC: Add `target_abi` configuration

+- Feature Name: `cfg-target-abi`+- Start Date: 2020-09-27+- RFC PR: [rust-lang/rfcs#2992](https://github.com/rust-lang/rfcs/pull/2992)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++This proposes a new `cfg`: `target_abi`, which specifies certain aspects of the+target's [Application Binary Interface (ABI)][abi]. This also adds a+`CARGO_CFG_TARGET_ABI` environment variable for parity with other+`CARGO_CFG_TARGET_*` variables.++# Motivation+[motivation]: #motivation++Certain targets are only differentiated by their ABI. For example: the `ios` OS+in combination with the `macabi` ABI denotes targeting Mac Catalyst (iOS on+macOS). The non-`macabi` `x86_64-apple-ios` target is not for Mac Catalyst and+instead is for the iOS simulator, which is a very different environment.++It is not currently possible to `#[cfg]` against a certain target ABI without+a `build.rs` script to emit a custom `cfg` based on the `TARGET` environment+variable. This is not ideal because:++- Adding a build script increases compile time and makes a crate incompatible+  with certain build systems.++- Checking `TARGET` is error prone, mainly because the ABI often follows+  `target_env` without separation.++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++This would act like [existing `target_*` configurations][cfg-options].++For example: if one had a module with bindings to+[Apple's AppKit](https://developer.apple.com/documentation/appkit), this feature+could be used to ensure the module is available when targeting regular macOS and+Mac Catalyst.++```rust+#[cfg(any(+    target_os = "macos",+    all(+        target_os = "ios",+        target_abi = "macabi",+    ),+))]+pub mod app_kit;+```++This configuration option would also be usable as+`#[cfg_attr(target_abi = "...", attr)]`.++# Reference-level explanation+[reference-level-explanation]: #reference-level-explanation++`target_abi` is a key-value option set once with the target's ABI. The value is

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".

nvzqz

comment created time in a month

PullRequestReviewEvent

issue commentrust-lang/rust

Add a macro to track a file

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

GuillaumeGomez

comment created time in a month

issue commentmozilla/sccache

[dist] failure when build.rs or procmacro depend on externalities

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.

drahnr

comment created time in a month

startedkshoji/BLE-HID-Peripheral-for-Android

started time in a month

Pull request review commentrust-lang/rfcs

RFC: Add `target_abi` configuration

+- Feature Name: `cfg-target-abi`+- Start Date: 2020-09-27+- RFC PR: [rust-lang/rfcs#2992](https://github.com/rust-lang/rfcs/pull/2992)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++This proposes a new `cfg`: `target_abi`, which specifies certain aspects of the+target's [Application Binary Interface (ABI)][abi]. This also adds a+`CARGO_CFG_TARGET_ABI` environment variable for parity with other+`CARGO_CFG_TARGET_*` variables.++# Motivation+[motivation]: #motivation++Certain targets are only differentiated by their ABI. For example: the `ios` OS+in combination with the `macabi` ABI denotes targeting Mac Catalyst (iOS on+macOS). The non-`macabi` `x86_64-apple-ios` target is not for Mac Catalyst and+instead is for the iOS simulator, which is a very different environment.++It is not currently possible to `#[cfg]` against a certain target ABI without+a `build.rs` script to emit a custom `cfg` based on the `TARGET` environment+variable. This is not ideal because:++- Adding a build script increases compile time and makes a crate incompatible+  with certain build systems.++- Checking `TARGET` is error prone, mainly because the ABI often follows+  `target_env` without separation.++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++This would act like [existing `target_*` configurations][cfg-options].++For example: if one had a module with bindings to+[Apple's AppKit](https://developer.apple.com/documentation/appkit), this feature+could be used to ensure the module is available when targeting regular macOS and+Mac Catalyst.++```rust+#[cfg(any(+    target_os = "macos",+    all(+        target_os = "ios",+        target_abi = "macabi",+    ),+))]+pub mod app_kit;+```++This configuration option would also be usable as+`#[cfg_attr(target_abi = "...", attr)]`.++# Reference-level explanation+[reference-level-explanation]: #reference-level-explanation++`target_abi` is a key-value option set once with the target's ABI. The value is

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.

nvzqz

comment created time in a month

PullRequestReviewEvent

Pull request review commentrust-lang/rfcs

RFC: Add `target` configuration

+- Feature Name: `cfg-target`+- Start Date: 2020-09-27+- RFC PR: [rust-lang/rfcs#2991](https://github.com/rust-lang/rfcs/pull/2991)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++This proposes a new `cfg`: `target`, which matches the entire target triple+string (e.g. `arm-unknown-linux-gnueabihf`). This also adds a `CARGO_CFG_TARGET`+environment variable for parity with other `CARGO_CFG_*` variables.++# Motivation+[motivation]: #motivation++To `#[cfg]` against a specific target, a `build.rs` script is required to emit a+custom `cfg` based on the `TARGET` environment variable. Adding a build script+increases compile time and makes a crate incompatible with certain build+systems.++Otherwise, all available components would need to be specified separately:+`target_arch`, `target_vendor`, `target_os`, and `target_env`. This can be very+cumbersome. Note that the target ABI cannot currently be `#[cfg]`-ed against, so+a `build.rs` is still necessary to match all target components.++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++This would act like existing `target_*` configurations but match against all+components (except `target_feature`).++```rust+#[cfg(target = "x86_64-apple-ios-macabi")]+mod mac_catalyst;+```++This includes `#[cfg_attr(target = "...", attr)]`.++# Reference-level explanation+[reference-level-explanation]: #reference-level-explanation++`target` is a key-value option set once with the target's Rust triple.++Example values:++- `"aarch64-apple-darwin"`+- `"arm-unknown-linux-gnueabihf"`+- `"x86_64-apple-ios-macabi"`+- `"x86_64-pc-windows-gnu"`+- `"x86_64-pc-windows-msvc"`+- `"x86_64-unknown-linux-gnu"`++# Drawbacks+[drawbacks]: #drawbacks++- Configuring against specific targets can be overly strict and could make+  certain `#[cfg]`s miss similar configurations with small changes.++  For example: `aarch64-unknown-none` does not match+  `aarch64-unknown-none-softfloat`, yet one would likely want to include ABI+  variants. The same concern applies to the target vendor.++  A potential solution would be to allow glob matching (e.g.

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.

nvzqz

comment created time in a month

Pull request review commentrust-lang/rfcs

RFC: Add `target` configuration

+- Feature Name: `cfg-target`+- Start Date: 2020-09-27+- RFC PR: [rust-lang/rfcs#2991](https://github.com/rust-lang/rfcs/pull/2991)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++This proposes a new `cfg`: `target`, which matches the entire target triple+string (e.g. `arm-unknown-linux-gnueabihf`). This also adds a `CARGO_CFG_TARGET`+environment variable for parity with other `CARGO_CFG_*` variables.++# Motivation+[motivation]: #motivation++To `#[cfg]` against a specific target, a `build.rs` script is required to emit a+custom `cfg` based on the `TARGET` environment variable. Adding a build script+increases compile time and makes a crate incompatible with certain build+systems.++Otherwise, all available components would need to be specified separately:+`target_arch`, `target_vendor`, `target_os`, and `target_env`. This can be very+cumbersome. Note that the target ABI cannot currently be `#[cfg]`-ed against, so+a `build.rs` is still necessary to match all target components.++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++This would act like existing `target_*` configurations but match against all+components (except `target_feature`).++```rust+#[cfg(target = "x86_64-apple-ios-macabi")]+mod mac_catalyst;+```++This includes `#[cfg_attr(target = "...", attr)]`.++# Reference-level explanation+[reference-level-explanation]: #reference-level-explanation++`target` is a key-value option set once with the target's Rust triple.++Example values:++- `"aarch64-apple-darwin"`+- `"arm-unknown-linux-gnueabihf"`+- `"x86_64-apple-ios-macabi"`+- `"x86_64-pc-windows-gnu"`+- `"x86_64-pc-windows-msvc"`+- `"x86_64-unknown-linux-gnu"`++# Drawbacks+[drawbacks]: #drawbacks++- Configuring against specific targets can be overly strict and could make

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.

nvzqz

comment created time in a month

Pull request review commentrust-lang/rfcs

RFC: Add `target` configuration

+- Feature Name: `cfg-target`+- Start Date: 2020-09-27+- RFC PR: [rust-lang/rfcs#2991](https://github.com/rust-lang/rfcs/pull/2991)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++This proposes a new `cfg`: `target`, which matches the entire target triple+string (e.g. `arm-unknown-linux-gnueabihf`). This also adds a `CARGO_CFG_TARGET`+environment variable for parity with other `CARGO_CFG_*` variables.++# Motivation

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.

nvzqz

comment created time in a month

PullRequestReviewEvent
PullRequestReviewEvent

issue commentluser/rust-gdb-remote-protocol

How to implement continue

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.

nomtats

comment created time in a month

issue commentmozilla/sccache

Document multi-tenant security considerations

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.

DemiMarie

comment created time in a month

startedComponolit/RecordFlux

started time in a month

issue openedsaagarjha/dummy_thicc

List of potential CPU architectures

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:

created time in a month

issue commentmozilla/sccache

Automaticly prune unreachable entries

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.

DemiMarie

comment created time in a month

issue commentmozilla/sccache

rustc version detection

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.

DemiMarie

comment created time in a month

issue closedmozilla/sccache

Support rustup overrides properly

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.

closed time in a month

luser

issue commentmozilla/sccache

Support rustup overrides properly

Fixed by #666.

luser

comment created time in a month

pull request commentrust-lang/rust

Add std::thread::available_concurrency

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.

yoshuawuyts

comment created time in a month

issue commentmozilla/sccache

sccache: error : Failed to create temp dir

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.

GopherJ

comment created time in a month

startedredsift/redbpf

started time in 2 months

startedalessandrod/snuffy

started time in 2 months

Pull request review commentmozilla/sccache

New entry in ServerStartup enum to indicate AddrInUse Error

 pub fn start_server(config: &Config, port: u16) -> Result<()> {         }         Err(e) => {             error!("failed to start server: {}", e);-            let reason = e.to_string();-            notify_server_startup(&notify, ServerStartup::Err { reason })?;+            if let Some(io_err) = e.downcast_ref::<io::Error>() {+                if let io::ErrorKind::AddrInUse = io_err.kind() {

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 })?;
  }
}
sum12

comment created time in 2 months

PullRequestReviewEvent

startedDushistov/flapigen-rs

started time in 2 months

issue openedgoogle/flatbuffers

Generate iterators for array fields in JavaScript/TypeScript code

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);
}

created time in 2 months

push eventluser/rust-android-jni-example

Ted Mielczarek

commit sha 24488a9d08735fef3a371cc3361ecebae01de3cb

Hide ThreadPool inside Driver API

view details

push time in 2 months

create barnchluser/rust-android-jni-example

branch : master

created branch time in 2 months

more