profile
viewpoint

jsgf/EyeFiServer 4

An open source Eye-Fi Server written in Python

jsgf/concurrent-barrier 2

Simple concurrency barriers

jsgf/aeson 1

A fast Haskell JSON library

jsgf/AndroidMessenger 1

A project I worked on to make a multiclient messaging client back when the android API was in beta

jsgf/constellation 1

Constellation

jsgf/criterion 1

A powerful but simple library for measuring the performance of Haskell code.

jsgf/dep-analyzer 1

Experiment in analyzing Rust dependencies with save-analysis output

jsgf/eventfd-rust 1

Rust binding to Linux eventfd

jsgf/frond 1

Frond firmware

jsgf/gloop 1

Link manager thingy

issue commentrust-lang/rust

Stabilize -Zsymbol-mangling-version / RFC2603?

I guess that's a question of what it means for the mangling to be "stable". Since Rust has no ABI guarantees, there's nothing in principle preventing either mangling scheme from changing from release to release. But since it's also an interface to other tools they need to be managed in a somewhat sensible way.

Legacy mangling gets away with this because it looks enough like typical C++ mangling for tools to show something useful (to a greater or lesser extent).

"v0" mangling needs more tool support to get good results, so there's a question of how well that support has been propagated (eg gdb and binutils has support for it upstream now, I think, but I don't know about current state of other tooling). Also if we extend v0 mangling to support new language features, will those demanglers degrade gracefully? (AFAIK @eddyb implemented them all, so I'm reasonably sure they will have taken that into consideration.)

So I think there's probably quite a few users which are currently relying on "legacy" as part of their environment, and have been for some time, so in that sense it is "stable". But we've been using "v0" for its richer type info for 1 year+, but its awkward that we need to invoke rustc in a nightly-like way to get it.

I'm also concerned that people are overlooking v0 mangling with the potential to introduce bugs, so we need to make sure its on equal footing with respect to regression testing etc.

So from my POV it makes sense to stabilize the option but retain the existing behaviour, until we're in the position to flip the default.

I think the counterargument would be that v0 mangling has some clear flaw and will need to be revised, in which case we should do a v1 and stabilize that. But I haven't seen anything to that effect. v0 - being a lot more inforation rich - is also a lot larger, but I don't know how much of a concern that is in practice.

jsgf

comment created time in 3 days

issue openedrust-lang/rust

Stabilize -Zsymbol-mangling-version / RFC2603?

Where are we with stabilizing RFC2603 and the -Zsymbol-mangling-version? Can we introduce -Csymbol-mangling-version?

(Note, I'm not thinking about changing the default from legacy yet, but we can also discuss that.)

cc @eddyb @michaelwoerister

created time in 4 days

issue commentrust-lang/cargo

Should build-plans be deleted?

BTW I did end up releasing my tool reindeer, which automatically (as possible) generates Buck build rules from Cargo dependencies.

alexcrichton

comment created time in 6 days

push eventjsgf/rust

The8472

commit sha b90816deb7be23d1884f051d20bf9b1b8883d2e4

remove example that relied on non-public trait

view details

The8472

commit sha 07a8c1b95ad23a0d08bffce2613eb36cd0be8400

hide binary_heap::IntoIter internals behind impl Trait

view details

The8472

commit sha 631543dcb4e79d3c134a7dfc8e87b62287e96796

restore Vec::extend specialization for vec::IntoIter sources that was lost during refactoring

view details

The8472

commit sha a4e385a0d0c1966870a18db5e138a55b8ebc7b04

use memmove instead of generic in-place iteration for IntoIter source this is the original SpecExtend<_, IntoIter> logic except generalizing the fast-path to include a memmove

view details

The8472

commit sha 2f700d085a988b1f2a51d80879e9e55bba031008

add benches from bluss' gists

view details

The8472

commit sha bb4f888a590b1fe24a386f3f40bad8537c3232a9

return the things under test so they get black_box()'ed

view details

The8472

commit sha 8ac96e6a9832d70f9b5d43967cd2680711fa92df

cyclic in-place reuse bench

view details

The8472

commit sha a9c78e371e3b46f0d1cf0b38368d503b6aa1ce6e

bench in-place collect of droppables

view details

The8472

commit sha a596ff36b55a37e7a74abd0504ff895a3d2fba6f

exercise more of the in-place pipeline in the bench

view details

The8472

commit sha 582fbb1d62420d8d85f364d06669038f12b7e423

use From specializations on extend if extended Vec is empty this enables in-place iteration and allocation reuse in additional cases

view details

The8472

commit sha dac0edfaaaa5a8c668f70a1cd58468c700a04627

restore SpecFrom<T, TrustedLen<Item=T>> specialization by nesting specializations

view details

The8472

commit sha 290fe895ba6a507479a745cb9ce720b47570a52c

specialize creating a Vec from a slice iterator where T: Copy this was already implemented for Extend but not for FromIterator

view details

The8472

commit sha cc67c8eb911a2ce607614434dabc41df26ca5d37

improve comments

view details

The8472

commit sha 8c816b96dd549d24146f6c4be410fcf7526221d1

remove redundant code

view details

The8472

commit sha 00a32eb54f65c11cd2f4d10c2414dd633fab3c5b

fix some in-place-collect edge-cases - it's an allocation optimization, so don't attempt to do it on ZSTs - drop the tail of partially exhausted iters

view details

The8472

commit sha 2b0b2ae9f61c26338dc00c70eee936230b4b75c0

additional specializations tests

view details

The8472

commit sha 3d5e9f1904e2c08369bfa7ec3963dab12a76544b

bench in-place zip

view details

The8472

commit sha 0f122e11196875c75071f4e3ac4ce1a652e320bf

add in-place iteration for Zip this picks the left hand side as source since it might be more natural to consume that as IntoIter source

view details

The8472

commit sha 085eb20a61164067f5c71ec64dc23100006f91c9

move free-standing method into trait impl

view details

The8472

commit sha 21a17d105c9cd81dfa8bd3a178e4a6b095f69e5d

support in-place iteration for most adapters `Take` is not included since users probably call it with small constants and it doesn't make sense to hold onto huge allocations in that case

view details

push time in 6 days

pull request commentrust-lang/rust

Implement `--extern-location`

@JohnCSimon @crlf0710 Looking.

jsgf

comment created time in 7 days

startedrtsuk/crankstart-klondike

started time in a month

issue openedwez/wezterm

SIGSEGV on startup

Describe the bug

When starting wezterm connect <host> it crashes very early - just after creating a window.

Environment (please complete the following information):

  • OS: Linux X!!
  • Version: wezterm 20200718-095447-d2315640-1-g28836224

To Reproduce

wezterm connect <host> to a host running wezterm start --front-end MuxServer.

Steps to reproduce the behavior.

Please include as much information as possible that can help to reproduce and understand the issue; some pointers and suggestions are included here in this template. You are empowered to include more or less information than is asked for here!

Configuration

local wezterm = require('wezterm')

local username = "jsgf"

return {
        scrollback_lines = 10000,
        enable_scroll_bar = true,

        enable_wayland = false, -- Wayland way too janky
        window_padding = {
                left = 7,
                right = 15, -- also scrollbar width
                top = 2,
                bottom = 2,
        },
        font = wezterm.font("Hasklig"),
}

Expected behavior

Not crash

Screenshots

If applicable, add screenshots to help explain your problem. Screenshots are most appropriate for rendering issues.

Additional context

If the server isn't running it falls back to ssh, which pops the window up for login details OK - except that its transparent (ie, the alpha channel doesn't look initialized).

Crash happens when running optimized build:

Thread 1 "wezterm" received signal SIGSEGV, Segmentation fault.
0x000055555576bbe0 in wezterm::frontend::gui::termwindow::TermWindow::render_screen_line_opengl ()

(gdb) bt
#0  0x000055555576bbe0 in wezterm::frontend::gui::termwindow::TermWindow::render_screen_line_opengl ()
#1  0x0000555555768005 in wezterm::frontend::gui::termwindow::TermWindow::paint_tab_opengl ()
#2  0x000055555575f2aa in <wezterm::frontend::gui::termwindow::TermWindow as window::WindowCallbacks>::paint_opengl ()
#3  0x0000555555cdc7df in window::os::x11::window::XWindowInner::paint ()
#4  0x0000555555cc25f7 in <window::os::x11::connection::XConnection as window::connection::ConnectionOps>::run_message_loop ()
#5  0x000055555581d876 in wezterm::run ()
#6  0x0000555555815851 in wezterm::main ()
#7  0x00005555556de033 in std::rt::lang_start::{{closure}} ()
#8  0x0000555556134a08 in std::rt::lang_start_internal::{{closure}} () at src/libstd/rt.rs:52
#9  std::panicking::try::do_call () at src/libstd/panicking.rs:297
#10 std::panicking::try () at src/libstd/panicking.rs:274
#11 std::panic::catch_unwind () at src/libstd/panic.rs:394
#12 std::rt::lang_start_internal () at src/libstd/rt.rs:51
#13 0x00005555558239a2 in main ()

Running a debug build shows:

 2020-08-11T00:22:23.915Z ERROR wezterm::mux > read_pty EOF: tab_id 0
 2020-08-11T00:22:24.490Z ERROR wezterm::mux > removing window 0
thread 'main' panicked at 'assertion failed: backend.is_current()', /home/jsgf/.cargo/registry/src/github.com-1ecc6299db9ec823/glium-0.27.0/src/context/mod.rs:646:17
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:78
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:59
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1076
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1537
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:62
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:49
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:198
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:218
  10: <alloc::boxed::Box<F> as core::ops::function::Fn<A>>::call
             at /home/jsgf/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/liballoc/boxed.rs:1090
  11: wezterm::notify_on_panic::{{closure}}
             at src/main.rs:709
  12: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:490
  13: std::panicking::begin_panic
             at /home/jsgf/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libstd/panicking.rs:410
  14: <glium::context::Context as glium::ContextExt>::make_current
             at /home/jsgf/.cargo/registry/src/github.com-1ecc6299db9ec823/glium-0.27.0/src/context/mod.rs:646
  15: glium::context::Context::is_context_lost
             at /home/jsgf/.cargo/registry/src/github.com-1ecc6299db9ec823/glium-0.27.0/src/context/mod.rs:420
  16: window::os::x11::window::XWindowInner::paint
             at window/src/os/x11/window.rs:155
  17: window::os::x11::connection::XConnection::do_paint
             at window/src/os/x11/connection.rs:432
  18: <window::os::x11::connection::XConnection as window::connection::ConnectionOps>::run_message_loop
             at window/src/os/x11/connection.rs:203
  19: <window::os::x_and_wayland::Connection as window::connection::ConnectionOps>::run_message_loop
             at window/src/os/x_and_wayland.rs:103
  20: <wezterm::frontend::gui::GuiFrontEnd as wezterm::frontend::FrontEnd>::run_forever
             at src/frontend/gui/mod.rs:71
  21: wezterm::run_mux_client
             at src/main.rs:504
  22: wezterm::run
             at src/main.rs:904
  23: wezterm::main
             at src/main.rs:725
  24: std::rt::lang_start::{{closure}}
             at /home/jsgf/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libstd/rt.rs:67
  25: std::rt::lang_start_internal::{{closure}}
             at src/libstd/rt.rs:52
  26: std::panicking::try::do_call
             at src/libstd/panicking.rs:297
  27: std::panicking::try
             at src/libstd/panicking.rs:274
  28: std::panic::catch_unwind
             at src/libstd/panic.rs:394
  29: std::rt::lang_start_internal
             at src/libstd/rt.rs:51
  30: std::rt::lang_start
             at /home/jsgf/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libstd/rt.rs:67
  31: main
  32: __libc_start_main
  33: _start
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
thread panicked while processing panic. aborting.
Illegal instruction (core dumped)

created time in 2 months

pull request commentfacebookincubator/reindeer

Fix typo in README

Thanks for the fix!

I haven't publicized this project must yet because it's still a bit rough. I definitely need to work out how CI should work and fill out the documentation a bit.

davemachado

comment created time in 2 months

push eventjsgf/rancher-xcp-xe-guest-utils

Jeremy Fitzhardinge

commit sha 5e0a95ea2d08637c309a976e6acdd0186163dbb5

Fix typo in entrypoint.sh

view details

push time in 2 months

pull request commentrust-lang/rust

[stable] 1.45.2 release

Confirming that applying these 1.45.1 resolves the #74954 and doesn't introduce any more problems.

Mark-Simulacrum

comment created time in 2 months

PR opened opnsense/plugins

acme-client: add support for Linode Cloud API

Resolves #1939

+19 -0

0 comment

3 changed files

pr created time in 2 months

Pull request review commentrust-lang/blog.rust-lang.org

1.45.2 post

+---+layout: post+title: "Announcing Rust 1.45.2"+author: The Rust Release Team+release: true+---++The Rust team is happy to announce a new version of Rust, 1.45.2. Rust is a+programming language that is empowering everyone to build reliable and+efficient software.++If you have a previous version of Rust installed via rustup, getting Rust+1.45.2 is as easy as:++```console+rustup update stable+```++If you don't have it already, you can [get `rustup`][install] from the+appropriate page on our website, and check out the [detailed release notes for+1.45.2][notes] on GitHub.++[install]: https://www.rust-lang.org/install.html+[notes]: https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-1452-2020-07-31++## What's in 1.45.2 stable++1.45.2 contains two fixes, one to 1.45.1 and the other to 1.45.0.++## `#[track_caller]` on trait objects++Trait objects and `#[track_caller]` could lead to unsoundness. `#[track_caller]`+is not yet stable on 1.45. However, the standard library makes use of this on+some traits for better error messages. Trait objects of `SliceIndex`, `Index`,+and `IndexMut` are affected by this bug.++## Bindings in tuple-patterns

The bug actually manifested in a slice pattern.

Mark-Simulacrum

comment created time in 2 months

issue openedrust-lang/rust

Pattern matching regression 1.45.0 -> 1.45.1 (+nightly)

<!-- Thank you for filing a bug report! 🐛 Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. -->

I tried this code:

fn main() {
    if let Some([b'@', filename @ ..]) = Some(b"@abc123") {
        println!("filename {:?}", filename);
    }
}

I expected this to compile and print

filename [97, 98, 99, 49, 50, 51]

which it does with 1.45.0

Instead, it failed to compile:

error[E0425]: cannot find value `filename` in this scope
 --> src/main.rs:3:35
  |
3 |         println!("filename {:?}", filename);
  |                                   ^^^^^^^^ not found in this scope

error: aborting due to previous error

Playground link

Meta

<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. -->

rustc --version --verbose:

rustc 1.45.1 (c367798cf 2020-07-26)

</p> </details>

created time in 2 months

push eventjsgf/plugins

Jeremy Fitzhardinge

commit sha 3e4d9294c0c9c7a7f38dd5a75d7000969328538b

acme-client: add support for Linode Cloud API Resolves #1939

view details

push time in 2 months

push eventjsgf/plugins

Jeremy Fitzhardinge

commit sha bfdd03d79ad26f7131ef1b3ce7ba2188438c59b0

acme-client: add support for Linode Cloud API Resolves #1939

view details

push time in 2 months

issue commentopnsense/plugins

Support Linode Cloud API in Let's Encrypt Plugin

@fraenki Yep, just working out how to test them first.

jsgf

comment created time in 2 months

push eventjsgf/plugins

Jeremy Fitzhardinge

commit sha 8949941d91a893df426486ffb2acf241d0d82c29

acme-client: add support for Linode Cloud API Resolves #1939

view details

push time in 2 months

fork jsgf/plugins

OPNsense plugin collection

https://opnsense.org/

fork in 2 months

issue openedopnsense/plugins

Support Linode Cloud API in Let's Encrypt Plugin

Important notices Before you add a new report, we ask you kindly to acknowledge the following:

[x] I have read the contributing guide lines at https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md

[x] I have searched the existing issues and I'm convinced that mine is new.

[x] When the request is meant for an existing plugin, I've added its name to the title.

Is your feature request related to a problem? Please describe. The Let's Encrypt plugin supports "Linode API" as a way of doing DNS-01 validation. However, this is the old API which Linode is migrating away from in favour of its "Cloud API" aka Linode API v4.

acme.sh supports this API with --dns dns_linode_v4 option, so it's just a matter of setting up a suitable UI to configure it.

Describe the solution you'd like

Extend Let's Encrypt plugin's UI to support Linode API v4.

Describe alternatives you've considered

Using the old Linode API. I'd prefer not to because it doesn't give enough access control.

Additional context Add any other context or screenshots about the feature request here.

created time in 2 months

PR opened cpascal/syno-ddns-linode

Fix linode ddns script
  • Use password rather than account as the API token so that it isn't visible in the API (and also to meet my expectation). Username is ignored.
  • Split hostname into "foo.bar.biff.blat" into "foo" and "bar.biff.blat" so that it copes with deeper than two domains
+7 -7

0 comment

1 changed file

pr created time in 2 months

push eventjsgf/syno-ddns-linode

Jeremy Fitzhardinge

commit sha 6f2e9b4a0124e494d04d3f87f3b1efe9e6a8db97

Fix linode ddns script - Use password rather than account as the API token so that it isn't visible in the API (and also to meet my expectation). Username is ignored. - Split hostname into "foo.bar.biff.blat" into "foo" and "bar.biff.blat" so that it copes with deeper than two domains. - use pwd rather than account as the API token - split hostname into "foo.bar.blat" into "foo" and "bar.blat" so that it copes with deeper than two domains

view details

push time in 2 months

push eventjsgf/syno-ddns-linode

Jeremy Fitzhardinge

commit sha 96aa9dd4dba2989946c119c7aadd1484dd15460f

Fix linode ddns script - use pwd rather than account as the API token - split hostname into "foo.bar.blat" into "foo" and "bar.blat" so that it copes with deeper than two domains

view details

push time in 2 months

fork jsgf/syno-ddns-linode

Linode DDNS script for Synology DSM

fork in 2 months

PR opened flathub/org.lamport.tla.toolbox

Add support for texlive extension

If texlive flatpak is installed, pdflatex is available at /app/texlive/bin/x86_64-linux/pdflatex

+10 -1

0 comment

1 changed file

pr created time in 2 months

push eventjsgf/org.lamport.tla.toolbox

Jeremy Fitzhardinge

commit sha a0e143922f3595a2e2c203384e818494cbbaab59

Add support for texlive extension If texlive flatpak is installed, pdflatex is available at /app/texlive/bin/x86_64-linux/pdflatex

view details

push time in 2 months

issue commentrust-lang/rustfmt

Feature request: path prefix remapping

It would also be nice to be able to specify a logical/assumed filename when reading from stdin.

jsgf

comment created time in 2 months

issue openedrust-lang/rustfmt

Feature request: path prefix remapping

rustfmt can emit diagnostics (eg syntax errors), but has no way to normalize the source filenames.

<!-- A clear and concise description of what the bug is. --> rustc has a --remap-path-prefix option so that all places where source file names are emitted (diagnostics, debug info, etc) can be normalized by, for example, removing an absolute path of a build directory.

It would be nice if rustfmt also implemented this option so the same kinds of remapping can be performed on its diagnostics.

To Reproduce

<!-- Steps to reproduce the behavior. If possible, please provide us with a link to your project or a minimal working example. -->

$ cat t.rs
fn main() {{}
$ rustfmt t.rs
error: this file contains an unclosed delimiter
 --> /home/jsgf/t.rs:1:15
  |
1 | fn main() {{}
  |           -   ^
  |           |
  |           unclosed delimiter

rustfmt shows the full path - not the path passed to it, and has no option for remapping this.

Expected behavior

rustfmt --remap-path-prefix /home/jsgf/= t.rs would show just t.rs:1:15 as the error path.

Meta

  • rustfmt version: rustfmt 1.4.15-stable (530eadf 2020-06-02)
  • From where did you install rustfmt?: rustup
  • How do you run rustfmt: rustfmt

created time in 2 months

issue commentrust-lang/rust

Add support for splitting linker invocation to a second execution of `rustc`

@joshtriplett Kernel?

alexcrichton

comment created time in 2 months

issue commentKyleMayes/clang-sys

clang-sys isn't using semver correctly

Oh what happened with the 0.2x.y releases?

jsgf

comment created time in 2 months

pull request commentrust-lang/rust

Add an unstable --json=unused-externs flag to print unused externs

@ehuss Well, it would be ideal if we can make one mechanism work well for everything. As I see it the pros and cons of the two approaches are:

-Wunused-crate-dependencies:

  • fits in with the general Rust lint handing flow, including deny/allow/warn/forbid
  • straightforward to integrate with external workflows (just another warning)
  • easy to integrate with a build system, so long as dependencies are precise
  • doesn't work well with Cargo's model
  • requires --extern-location to be able to provide good diagnostics/tooling

--json=unused-externs:

  • leaves decisions to build system, so can apply higher-level logic
  • allows build system to provide diagnostics
  • not treated as a rustc lint (Cargo doesn't currently have a lint concept)
  • requires close coupling between rustc and build system

Strictly speaking, --json=unused-externs isn't necessary if you have -Wunused-crate-dependencies, since in principle Cargo could parse the diagnostics output and look for the appropriate messages and consume/process/filter them. But it does leave awkwardness like the number of warnings being wrong unless Cargo also corrects those which is messy.

est31

comment created time in 3 months

pull request commentrust-lang/cargo

[WIP] Add flag to warn about unused dependencies

If cargo can't support dependency warnings as a side effect of normal builds, does dependency checking need to be its own explicit operation? Eg cargo check --dependencies which does a check build on all possible targets and complain about completely unused targets (and make fix proposals to remove unused deps or move deps to dev/build deps).

est31

comment created time in 3 months

issue commentKyleMayes/clang-sys

clang-sys isn't using semver correctly

Yeah that sounds like a workable strategy.

jsgf

comment created time in 3 months

issue commentKyleMayes/clang-sys

clang-sys isn't using semver correctly

@KyleMayes Thanks for working on this. I'll take a look at what you've got to see if I can help out when I get the chance (should be in the next few days).

jsgf

comment created time in 3 months

pull request commentrust-lang/rust

Implement `--extern-location`

I edited the PR description to match the current state of this PR - that is, only providing raw and json location types, and default locations when --extern-location isn't provided.

jsgf

comment created time in 3 months

pull request commentrust-lang/rust

Add an unstable --json=unused-externs flag to print unused externs

This is an interesting approach. I can see a possible path to making Buck support this, but it would need some philosophical discussion about how concerns should be separated (ie, is it really up to Buck to diagnose unused dependencies?).

est31

comment created time in 3 months

Pull request review commentrust-lang/rust

Add an unstable --json=unused-externs flag to print unused externs

 top_level_options!(         // by the compiler.         json_artifact_notifications: bool [TRACKED], +        // `true` if we're emitting a JSON blob containing the unused externs+        json_unused_externs: bool [TRACKED],

Does this need to be tracked?

est31

comment created time in 3 months

Pull request review commentrust-lang/rust

Add an unstable --json=unused-externs flag to print unused externs

 pub fn parse_color(matches: &getopts::Matches) -> ColorConfig { /// /// The first value returned is how to render JSON diagnostics, and the second /// is whether or not artifact notifications are enabled.-pub fn parse_json(matches: &getopts::Matches) -> (HumanReadableErrorType, bool) {+pub fn parse_json(matches: &getopts::Matches) -> (HumanReadableErrorType, bool, bool) {

Should (HumanReadableErrorType, bool, bool) become a real named type? Two bool is pretty ungainly.

est31

comment created time in 3 months

push eventjsgf/rust

Jeremy Fitzhardinge

commit sha 6e47b76de58914653b76c254b16d96fbb9c8f0bb

Add `--extern-loc` to augment unused crate dependency diagnostics This allows a build system to indicate a location in its own dependency specification files (eg Cargo's `Cargo.toml`) which can be reported along side any unused crate dependency. This supports several types of location: - 'json' - provide some json-structured data, which is included in the json diagnostics in a `tool_metadata` field - 'raw' - emit the provided string into the output. This also appears as a json string in `tool_metadata`. If no `--extern-location` is explicitly provided then a default json entry of the form `"tool_metadata":{"name":<cratename>,"path":<cratepath>}` is emitted.

view details

push time in 3 months

push eventjsgf/rust

Matthew Jasper

commit sha f97070db90b0e7310dd741673dd4048232d60b82

Forbid lifetime elision in let position impl Trait This is consistent with types.

view details

Matthew Jasper

commit sha 09546692ff41a081b7399e6693ae3a420f5c9d4b

Add more tests for type alias impl Trait

view details

Matthew Jasper

commit sha 857ea16feb6a3891555d032a0ff7d5d7c0e33b32

Remove associated opaque types They're unused now.

view details

Matthew Jasper

commit sha 6c04d8672dcf4ece3b835ea256115f98586781cb

Remove ImplItemKind::OpaqueTy from clippy

view details

Matthew Jasper

commit sha af9b09235c674aaa2562c6fc0be18370eb8200bd

Remove ImplItemKind::OpaqueTy from clippy

view details

Alexis Bourget

commit sha 93cbad6ed5f6a40bdd1e8cee6a9b1a39f17ab166

Add documentation to point to `!is_dir` instead of `is_file`

view details

Ayaz Hafiz

commit sha e243f623174e661e7e2392eb234a0af9ce9129cd

Provide suggestion to convert numeric op LHS rather than unwrapping RHS Given a code ```rust fn foo(x: u8, y: u32) -> bool { x > y } fn main() {} ``` it could be more helpful to provide a suggestion to do "u32::from(x)" rather than "y.try_into().unwrap()", since the latter may panic. We do this by passing the LHS of a binary expression up the stack into the coercion checker. Closes #73145

view details

Ayaz Hafiz

commit sha 0c02f8aea9d8b26ad0e02a8ba1333a794844e146

fixup! Provide suggestion to convert numeric op LHS rather than unwrapping RHS

view details

Matthew Jasper

commit sha ee0d3c7f906ae293be30a607e216e9f00ea22f08

Rename `TyKind::Def` to `OpaqueDef`

view details

Matthew Jasper

commit sha 1e0832faaa45b2b2488885f06073c3f1eda9094d

Allow all impl trait types to capture bound lifetimes

view details

Matthew Jasper

commit sha f975eceb62f3ecd9152c1eac998d2d9630323853

Document some opaque types code

view details

Matthew Jasper

commit sha 8b10d42ebe7843bcaed58dcbbc8836a0f27b54c9

Fix NLL test

view details

Alexis Bourget

commit sha ec63f9d99b4faec04db0f924c24be9529f4febed

Added the note to Metadata too

view details

Alexis Bourget

commit sha c1243dbcd96f43d013e38f01efe91eb35b81fa18

Make a note about is_dir vs is_file in Path too

view details

Mateusz Mikuła

commit sha 9ceb9bb20324630380153c1db5aeb56a433ab8d9

Move copying of self-contained objects to new function

view details

Mateusz Mikuła

commit sha 638ebbc5859a38794408a988ffec6f54e0dc0f0b

Move copying of MinGW CRT to the better location

view details

Mateusz Mikuła

commit sha 961974fe0348f479255f9e95b5924419c2c15a77

Use enum to distinguish dependency type

view details

Mateusz Mikuła

commit sha 5d298836f2254144f80e56ee37af44ac79f3eb2c

Move some libs to self-contained directory

view details

Mateusz Mikuła

commit sha e9ac01a9beeae77a15badcec094a7a4da0bebecb

Get self-contained directory path via dedicated function

view details

Mateusz Mikuła

commit sha 43905cd7501fd37090cb9de6069faaba761e514a

Move shipped MinGW linker to self-contained dir

view details

push time in 3 months

more