profile
viewpoint
Josh Triplett joshtriplett https://joshtriplett.org Free and Open Source Software developer. @rust-lang developer and language team lead. he/him or they/them.

joshtriplett/async-pidfd 34

Rust crate to use process file descriptors (pidfd) for Linux

google/channel-id-enclave 29

Stores Chromium Channel ID private keys in an Intel SGX enclave.

joshtriplett/colorparse 2

Rust library to parse color configuration strings (in Git syntax) into ansi_term::Style objects

joshtriplett/anyhow 0

A better Box<dyn Error>

joshtriplett/async-h1 0

Asynchronous HTTP/1.1 in Rust

joshtriplett/async-process 0

Async interface for working with processes

joshtriplett/async-session 0

Async session support with plugabble backends

joshtriplett/async-sse 0

Async Server Sent Events parser and encoder

joshtriplett/async-tungstenite 0

Async binding for Tungstenite, the Lightweight stream-based WebSocket implementation

push eventrust-dev-tools/fmt-rfcs

Ivan Tham

commit sha b208df842cbfa013fe2d3123a96ef2780a4a9950

Use roman 4 letter instead of word Long text without numeric numbers when numeric numbers are used are hard to read.

view details

push time in 6 days

PR merged rust-dev-tools/fmt-rfcs

Use roman 4 letter instead of word

Long text without numeric numbers when numeric numbers are used are hard to read.

+1 -1

2 comments

1 changed file

pickfire

pr closed time in 6 days

push eventrust-dev-tools/fmt-rfcs

Daniel Vainsencher

commit sha f6a9b9ea5818897a96eee5964decdf55c52e99fd

Fix typo in types.md

view details

push time in 14 days

PR opened rust-dev-tools/fmt-rfcs

Fix typo in types.md
+1 -1

0 comment

1 changed file

pr created time in 15 days

issue commentrust-dev-tools/fmt-rfcs

[RFC] Merge imports by default

Would encourage folks to review and provide feedback on https://github.com/rust-lang/rustfmt/issues/3362#issuecomment-752723371 in the rustfmt repo

gnzlbg

comment created time in 16 days

PR opened git-series/git-series

Ignore submodules when determining whether unstaged changes prevent rebase

This matches the behavior of git's native rebase command.

Fixes #72.

+3 -2

0 comment

1 changed file

pr created time in 17 days

issue openedgit-series/git-series

"Cannot rebase: your index contains uncommitted changes." should ignore submodules

For a normal git rebase, the error "Cannot rebase: You have unstaged changes." comes from git-sh-setup, which prints it if the command git diff-files --quiet --ignore-submodules returns a nonzero exit status. Note the --ignore-submodules.

For git series rebase, on the other hand, git-series does its own diff and prints the same message if there are differences. However, it's too strict: it complains if there are any changes in submodules. There might be room for debate about whether it's actually wise to ignore submodules completely, but as is, even the existence of an untracked file inside the submodule is counted as an uncommitted change, which is clearly too much.

Here is a shell script that demonstrates the problem:

set -xe
rm -rf /tmp/rebase-test
mkdir /tmp/rebase-test
cd /tmp/rebase-test

git init submodule-upstream
pushd submodule-upstream
echo "Hello, world!" > hello.txt
git add hello.txt
git commit -m "Initial submodule commit"
popd

git init main
cd main
git submodule add ../submodule-upstream submodule
git commit -m "Initial main commit"

touch another-file.txt
git add another-file.txt
git commit -m "Add another file"

touch submodule/untracked-file.txt

git checkout -b test-branch master
echo test >> another-file.txt
git commit -a -m "Patch"
git rebase master^ # OK!
git rebase master

git series start test-series
git checkout test-branch
git series base master
git series commit -a -m "Initial series commit"
git series rebase master^ # Cannot rebase: your index contains uncommitted changes.

created time in 18 days

startedjoshtriplett/io-mux

started time in 24 days

startedjoshtriplett/async-pidfd

started time in a month

startedjoshtriplett/async-pidfd

started time in a month

startedjoshtriplett/metadeps

started time in 2 months

startedjoshtriplett/colorparse

started time in 2 months

push eventrust-dev-tools/fmt-rfcs

Camelid

commit sha 7ba2a06429dcb6e6753583ffca1b5e03a43daa63

Fix a couple typos Adding a line break after a '-' will also add a ' ', which leads to unintended rendered output that looks like > block- indented as opposed to the intended rendering as > block-indented

view details

push time in 2 months

PR merged rust-dev-tools/fmt-rfcs

Fix a couple typos

Adding a line break after a '-' will also add a ' ', which leads to unintended rendered output that looks like

block- indented

as opposed to the intended rendering as

block-indented

+5 -5

0 comment

1 changed file

camelid

pr closed time in 2 months

PR opened rust-dev-tools/fmt-rfcs

Fix a couple typos

Adding a line break after a '-' will also add a ' ', which leads to unintended rendered output that looks like

block- indented

as opposed to the intended rendering as

block-indented

+5 -5

0 comment

1 changed file

pr created time in 2 months

fork c1371064/highlight-stderr

Run a command and highlight its stderr, preserving the order of stdout and stderr

fork in 2 months

fork c1371064/systemd

The systemd System and Service Manager

https://systemd.io

fork in 2 months

startedjoshtriplett/io-mux

started time in 2 months

push eventrust-dev-tools/fmt-rfcs

Caleb Cartwright

commit sha 046bf6bfcc0515015a1d27831b9b581093eec348

docs: guidance for mac calls in match arm rhs

view details

Caleb Cartwright

commit sha f72c79a3afd0a78ac9ea4ef16c1f94781055360a

fix: typo for single expr match arm rhs

view details

Caleb Cartwright

commit sha 4c4e3efad5fc551600d460773204bafc33b36e6f

Merge pull request #159 from calebcartwright/match-rhs-mac-call-exprs clarify match block requirement for single mac call

view details

push time in 2 months

PR merged rust-dev-tools/fmt-rfcs

clarify match block requirement for single mac call

cc @Aaron1011 re: https://github.com/rust-lang/rustfmt/pull/4496 - think this minor clarification should cover the needed change but please let me know if you think anything additional is needed for the arm body flattening

@joshtriplett if you have time to review the text that'd be most appreciated as well!

+42 -2

2 comments

1 changed file

calebcartwright

pr closed time in 2 months

pull request commentrust-dev-tools/fmt-rfcs

clarify match block requirement for single mac call

@calebcartwright The new text looks good to me!

Awesome, thanks so much really appreciate your help on this one @Aaron1011! Fighting some indentation issues from copy/pasting out of GH but will go ahead and merge once I get that sorted and then we can proceed with https://github.com/rust-lang/rustfmt/pull/4496

calebcartwright

comment created time in 2 months

pull request commentrust-dev-tools/fmt-rfcs

clarify match block requirement for single mac call

@calebcartwright The new text looks good to me!

calebcartwright

comment created time in 2 months

Pull request review commentrust-dev-tools/fmt-rfcs

clarify match block requirement for single mac call

 match foo { ```  If the body is a single expression with no line comments and not a control flow-expression, then it may be started on the same line as the right-hand side. If+expression nor a macro call expression, then it may be started on the same line as the right-hand side. If

That sounds good to me. In general, I think rustfmt should be very cautious about making changes around macro invocations/definitions. I'm happy with accepting both the wrapped and unwrapped invocation, and adding something to the style guide about the pitfalls of the unwrapped case

calebcartwright

comment created time in 2 months

Pull request review commentrust-dev-tools/fmt-rfcs

clarify match block requirement for single mac call

 match foo { ```  If the body is a single expression with no line comments and not a control flow-expression, then it may be started on the same line as the right-hand side. If+expression nor a macro call expression, then it may be started on the same line as the right-hand side. If

This actually uses more forceful wording and would require additional work on the rustfmt side to explicitly reformat all such cases with a block wrapping, whereas https://github.com/rust-lang/rustfmt/pull/4496 is just going to preserve the programmers original arm body structure.

Given the additional discussion in https://github.com/rust-lang/rustfmt/pull/4496 about introducing a rustc warning in such cases, I'm actually now leaning towards changing the text here to make it a bit softer. The softer text would then align with the change https://github.com/rust-lang/rustfmt/pull/4496, and although rustfmt couldn't be used to automatically correct/update the problematic cases, it will defer to devs and allow them to block wrap the arm bodies in need, and keep the ones that don't.

Thoughts?

calebcartwright

comment created time in 2 months

Pull request review commentrust-dev-tools/fmt-rfcs

clarify match block requirement for single mac call

 match foo { ```  If the body is a single expression with no line comments and not a control flow-expression, then it may be started on the same line as the right-hand side. If+expression nor a macro call expression, then it may be started on the same line as the right-hand side. If

@calebcartwright: I don't really have any opinion about what the style guide should say. As long as https://github.com/rust-lang/rustfmt/pull/4496 is consistent with the style guide, I'll defer to your preferred wording.

calebcartwright

comment created time in 2 months

Pull request review commentrust-dev-tools/fmt-rfcs

clarify match block requirement for single mac call

 match foo { ```  If the body is a single expression with no line comments and not a control flow-expression, then it may be started on the same line as the right-hand side. If+expression nor a macro call expression, then it may be started on the same line as the right-hand side. If

Just to clarify, are you saying that block wrapping an arm body that has a single mac call expression could potentially fail to be semantics preserving

I was thinking that it could change the code from failing to compile (if the macro expands to a let statment, for example), to compiling. However, if the codr already compiles, then introducing a block won't change the behavior.

calebcartwright

comment created time in 2 months

Pull request review commentrust-dev-tools/fmt-rfcs

clarify match block requirement for single mac call

 match foo { ```  If the body is a single expression with no line comments and not a control flow-expression, then it may be started on the same line as the right-hand side. If+expression nor a macro call expression, then it may be started on the same line as the right-hand side. If

@Aaron1011

Note that the Style Guide provides guidance/prescriptions and best practices for formatting in general, which rustc doesn't necessarily care about one way or the other. The compiler is fine with spaces vs. tabs and doesn't care whether a control flow expression in a match arm body is block-wrapped or not, but the Style Guide still provides explicit guidance on both fronts.

I understand that => macro_call!(), will be fine in some cases even after https://github.com/rust-lang/rust/issues/33953 is fixed, but that doesn't necessarily preclude us from being able to provide guidance here (much in the same way that the compiler is fine with => if x { 1 } else { 2 }, but the Style Guide still says such a body, unrealistic as it may be, needs to be block-wrapped).

So I think the question for the Style Guide is whether it's worth prescribing block wrapping a single macro call expression as a general strategy to avoid running into parsing errors in cases where there's a trailing semi in the expansion.

If we don't want to go with something that strong, and still allow authors to write things like => println!("foo"), without rustfmt block wrapping it, that's fine too. Sure we could incorporate a general recommendation to be cognizant about block wrapping the body in cases where the expansion includes a semi which should provide sufficient cover for rustfmt to not flatten such cases.

None of the match arms should be flattened/un-flattend, since that can change the meaning.

Just to clarify, are you saying that block wrapping an arm body that has a single mac call expression could potentially fail to be semantics preserving (e.g. changing => macro_call!() to => { macro_call!() })? I can't quite see how that'd happen, though if so that'd be a separate issue we'd want to dig into as there are a few cases where rustfmt will do this today such as scenarios running up against max width with guards on the arm

calebcartwright

comment created time in 2 months

Pull request review commentrust-dev-tools/fmt-rfcs

clarify match block requirement for single mac call

 match foo { ```  If the body is a single expression with no line comments and not a control flow-expression, then it may be started on the same line as the right-hand side. If+expression nor a macro call expression, then it may be started on the same line as the right-hand side. If

This isn't quite right. Both => macro_call!() and => { macro_call!() } are fine - the issue is automatically transforming one into the other.

For example, the code:

macro_rules! expr {
	() =>  { true };
}

macro_rules! stmt {
	() => { true; };
}

fn main() {
	let _val: bool = match true {
		true => expr!(),
		false => false,
	};

	match true {
		true => { stmt!() },
		false => {}
	}
}

will compile if https://github.com/rust-lang/rust/issues/33953 is fixed. None of the match arms should be flattened/un-flattend, since that can change the meaning.

calebcartwright

comment created time in 2 months

PR opened rust-dev-tools/fmt-rfcs

clarify match block requirement for single mac call

cc @Aaron1011 re: https://github.com/rust-lang/rustfmt/pull/4496 - think this minor clarification should cover the needed change but please let me know if you think anything additional is needed for the arm body flattening

@joshtriplett if you have time to review the text that'd be most appreciated as well!

+4 -1

0 comment

1 changed file

pr created time in 3 months

more