profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/cjgillot/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

cjgillot/rtti 2

Implementation of multimethods in C++.

cjgillot/cacolac 0

Gyrokinetic linear analysis based on trajectory computation

cjgillot/ChefDep 0

Logiciel pour le suivi du dépannage à la 12F

cjgillot/fipy 0

FiPy is a Finite Volume PDE solver written in Python

cjgillot/fruits 0

Plus de fruits :)

cjgillot/measureme 0

Support crate for rustc's self-profiling feature

cjgillot/mycas 0

A small symbolic manipulation library inspired from GiNaC.

cjgillot/openfisca-france 0

French tax and benefit system for OpenFisca

cjgillot/rust 0

A safe, concurrent, practical language.

cjgillot/rust-analyzer 0

An experimental Rust compiler front-end for IDEs

Pull request review commentrust-lang/rustc-dev-guide

Document -Zunpretty=thir-tree

 The THIR ("Typed High-Level Intermediate Representation"), previously called HAI [it may also soon be used for unsafety checking][thir-unsafeck] as a replacement for the current MIR unsafety checker. ++You can get a human-readable repersentation of the THIR by passing the `-Zunpretty=thir-tree` flag

I wouldn't necessarily say it's "human readable" though. Maybe

You can get a debug representation of the THIR by passing the `-Zunpretty=thir-tree` flag
Smittyvb

comment created time in 7 minutes

pull request commentrust-lang/rfcs

Add a `let...else` expression, similar to Swift's `guard let...else`

I haven't re-read all the hundreds of comments here, but to summarize the most prominent syntactic hurdle:

The RFC proposes the syntax let PAT = EXPR else { BODY }. The problem arises when EXPR is an if expression: let PAT = if EXPR { B1 } else { B2 } can be parsed either as (let PAT (if EXPR B1 B2)) or (let-else PAT (if EXPR B1) B2). The same ambiguity exists for if let as well.

The most natural compromise is to say that the first parse must always be chosen (not just for compatibility with existing code, but also because it's what users would naturally expect).

The syntax for this feature would need to be changed from EXPR to some subset of expressions that excludes if and if let. Usefully, Rust's syntax already contains such a subset: see https://doc.rust-lang.org/reference/expressions.html#expressions and note that the Expression class is composed of ExpressionWithoutBlock and ExpressionWithBlock. For maximum expedience, the syntax for this feature could instead be let PAT = EXPR_WITHOUT_BLOCK else { BODY }. This would cause the if and if let forms to parse as expected, and would additionally cause let foo = loop { break bar } else { qux }; to be rejected (IMO, totally reasonable) but would also cause let foo = unsafe { bar } else { qux }; to be rejected (possibly controversial). Of course, a more precise class of expressions that contains only if and if let could be defined, but it would be both easier and backwards-compatible to start with EXPR_WITHOUT_BLOCK for now and expand the definition later.

mbrubeck

comment created time in 16 minutes

PR opened rust-lang/rustc-dev-guide

Document -Zunpretty=thir-tree

This flag is useful for debugging the THIR.

+4 -0

0 comment

1 changed file

pr created time in 20 minutes

pull request commentrust-lang/rfcs

eRFC: Crate name transfer

So this is about letting few people play God? Well with such thing like this would anyone use rust? Well I think it would best to implement what everyone wants, if package wasn't updated within 6 months let anyone request for the name and inform the owner and if not replied within 2 months transfer name, but lock to major semver version unless the version was abused, have ability to request for version clean up. All these process need to programmed and no person should intervene unless program fails. To avoid spam person can only able to request once a year and to be open it should be publicly informed it's under request for transfer and who are the previous owners. Some of these ideas are taken from community so thank you. I write this because I can't find any good available namespaces. Thank you for your time. I hope this resolves soon.

dtolnay

comment created time in an hour

pull request commentrust-lang/rfcs

Add a `let...else` expression, similar to Swift's `guard let...else`

I still feel quite good about this feature too. i would like it if someone would produce a short summary of the grammar challenges we encountered, I remember them being quite minor.

mbrubeck

comment created time in an hour

pull request commentrust-lang/rfcs

Simple postfix macros

I think at this point i would be in favor of landing this change. Type-based macros would be nice but I think this notation would unlock enough times and be super useful. We could potentially add type-based macro dispatch in the future via macro associated items or other features, I don't think it's blocked by having a lexical version of this sort of dispatch.

joshtriplett

comment created time in an hour

issue commentrust-lang/project-thir-unsafeck

Implement the THIR unsafety checker

@Smittyvb thanks for your help on this! If you plan on working on more unsafe operations, it would be great if you posted a comment here saying that you're doing it so we don't risk duplicate work. Or, if you intend to work regularly on this, you can ask to join the project group so you can edit the comment above directly.

LeSeulArtichaut

comment created time in 2 hours

pull request commentrust-lang/rfcs

Destructuring assignment

The most obvious advantage of that is that the same syntax would have easily been usable in any position where a pattern can appear

@fstirlitz What situations are you imagining here? I don't think this would actually be useful in a lot of places other than assignment. In Rust, patterns can occur in:

  • match arms: I would find something like match(x) { Some(reassign *y.foo()) => {}, None => {} } much harder to read than match(x) { Some(z) => *y.foo() = z, None => {} }. What is a situation where you imagine this construct being clearer/beneficial?
  • if let, while let, for: This reminds me of the C construct if((result = foo()) != 0) { ... }, which I've always found difficult to read. Under your proposal, this would allow if let Some(reassign result) { ... }, which I find less clear than if let Some(inner) { result = inner; ... }. Out of all the places that patterns can occur, I think this would be the most useful one (but still not useful enough) to have reassign though.
  • function parameters: I'm not sure how you'd make use of the reassign there, given that no local variables are defined yet. Apart from that I would find it very confusing if mutation could already happen in the line of the program just declaring the function.
  • let statements: I find (x, y) = foo() (the RFC proposal) much more ergonomic than let (reassign x, reassign y) = foo() (your proposal). In the latter case, there is a risk that people would not use reassign at all and go with let (x2, y2) = foo(); x = x2; y = y2 instead.

All those listed languages embrace mutability in their idiomatic forms, where Rust tries to gently steer the user away from it. In light of this, destructuring assignment taking more characters to express is a feature, not a bug.

I totally agree with you about Rust steering users away from using mutation and that's a good thing. However, assignment has always been an exception to this. We just write let mut x; ...; x = foo() and not let mut x; ...; let reassign x = foo(), which would be quite painful in my opinion.

In addition, allowing reassign in all patterns makes mutable assignment easier, not harder (which seems to be your goal). Currently, it can only happen in assignments expressions; with reassign it can potentially happen in any pattern.

varkor

comment created time in 4 hours

pull request commentrust-lang/rfcs

A new prelude for the 2021 edition (trait-only edition)

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC will be merged soon.

djc

comment created time in 5 hours

pull request commentrust-lang/rfcs

Scrape code examples from `examples/` directory for Rustdoc

@shepmaster Seeing how difficult it is to get https://github.com/rust-lang/rust/pull/84176 merged because some rustdoc team members aren't very favorable to the feature, I think it's going to be complicated (even though I agree).

willcrichton

comment created time in 5 hours

issue commentrust-lang/rfcs

Wishlist: functions with keyword args, optional args, and/or variable-arity argument (varargs) lists

@dbsxdbsx The point of the 2021 edition is not to include every feature, but to make minor breaking changes that some features may need. The edition will remove some legacy panic! behavior to enable implicit format arguments, but the feature itself can come in later Rust versions. Also note that the current implementation will not provide "real" f-strings like f"{name}", but only special support for format!-style macros.

@lebensterben Sure, that was implied in the "what the requirements are" section.

pnkfelix

comment created time in 11 hours

issue commentrust-lang/rfcs

Wishlist: functions with keyword args, optional args, and/or variable-arity argument (varargs) lists

@tanriol, maybe I missed the point? I just saw the f-string like feature in new plan for Rust 2021.

pnkfelix

comment created time in 11 hours

issue commentrust-lang/rfcs

Wishlist: functions with keyword args, optional args, and/or variable-arity argument (varargs) lists

@tanriol There's no consensus whether to include kwargs or optional args in the first place.

pnkfelix

comment created time in 11 hours

issue commentrust-lang/rfcs

Wishlist: functions with keyword args, optional args, and/or variable-arity argument (varargs) lists

@dbsxdbsx I don't think f-strings are coming soon, only implicit format arguments are. As for default/optional/keyword arguments, that's really unlikely - Rust 2021 is too soon and there's no consensus yet on a final design for this (and even no consensus what the requirements actually are, I think).

pnkfelix

comment created time in 11 hours

create barnchrust-lang/rust-forge

branch : dependabot/cargo/blacksmith/serde-1.0.126

created branch time in 12 hours

PR opened rust-lang/rust-forge

Bump serde from 1.0.125 to 1.0.126 in /blacksmith

Bumps serde from 1.0.125 to 1.0.126. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/serde-rs/serde/releases">serde's releases</a>.</em></p> <blockquote> <h2>v1.0.126</h2> <ul> <li>Resolve conflict with <code>forbid(future_incompatible)</code> lint setting in generated code (<a href="https://github-redirect.dependabot.com/serde-rs/serde/issues/2026">#2026</a>, thanks <a href="https://github.com/hyd-dev"><code>@​hyd-dev</code></a>)</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/serde-rs/serde/commit/d9c338ec4abd1dd6fdd305e208bff1fd7faaabff"><code>d9c338e</code></a> Release 1.0.126</li> <li><a href="https://github.com/serde-rs/serde/commit/699bf3a75dab3fe41de0f356b17ec08bf4d33bf2"><code>699bf3a</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/serde-rs/serde/issues/2026">#2026</a> from hyd-dev/warning</li> <li><a href="https://github.com/serde-rs/serde/commit/dd29825217e0bb91a82687847509758f377c4ad8"><code>dd29825</code></a> Allow only <code>unused_extern_crates</code> instead of the whole <code>rust_2018_idioms</code> lin...</li> <li><a href="https://github.com/serde-rs/serde/commit/6366f17da719a0efa5117c780fdd5469b903929d"><code>6366f17</code></a> Ignore clone_instead_of_copied pedantic clippy lint</li> <li><a href="https://github.com/serde-rs/serde/commit/1120e5af4aa6fd2269459137f01f3b60dcd080eb"><code>1120e5a</code></a> Remove suppression of removed clippy lint</li> <li><a href="https://github.com/serde-rs/serde/commit/1093f7e2325398288f4c1ea116a7b6cfcc5b282f"><code>1093f7e</code></a> Resolve flat_map_option pedantic clippy lint</li> <li><a href="https://github.com/serde-rs/serde/commit/2ea132b8c417ac282885499a75e1bf9ceb2915d4"><code>2ea132b</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/serde-rs/serde/issues/2018">#2018</a> from dtolnay/nonascii</li> <li><a href="https://github.com/serde-rs/serde/commit/2ebc771b881bb1529b6e4baec71b477d4bebccde"><code>2ebc771</code></a> Remove non_ascii_idents feature gate from test suite</li> <li><a href="https://github.com/serde-rs/serde/commit/c17c4eef1872a4e864198d03c94760f050f6edcf"><code>c17c4ee</code></a> Unify stable and beta CI workflow</li> <li><a href="https://github.com/serde-rs/serde/commit/7aa4950504e64dc3987f0c69718d97b4b106d650"><code>7aa4950</code></a> Release serde_derive_internals 0.26.0</li> <li>Additional commits viewable in <a href="https://github.com/serde-rs/serde/compare/v1.0.125...v1.0.126">compare view</a></li> </ul> </details> <br />

Dependabot compatibility score

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)

</details>

+5 -5

0 comment

2 changed files

pr created time in 12 hours

pull request commentrust-lang/rfcs

Destructuring assignment

I would have preferred a reassign x syntax in patterns (or similar), as mentioned in the alternatives section, and I regret not having been able to respond here before this RFC was merged. Oh well.

The most obvious advantage of that is that the same syntax would have easily been usable in any position where a pattern can appear; this is not discussed at all in the alternatives section, and it’s far from obvious how it could possibly be replicated with this RFC.

As for prior art,

  • JavaScript supports destructuring assignment.
  • Python supports destructuring assignment.
  • Perl supports destructuring assignment.
  • And so on...

All those listed languages embrace mutability in their idiomatic forms, where Rust tries to gently steer the user away from it. In light of this, destructuring assignment taking more characters to express is a feature, not a bug.

varkor

comment created time in 12 hours

issue commentrust-lang/rfcs

Wishlist: functions with keyword args, optional args, and/or variable-arity argument (varargs) lists

@Spleeding1 @pnkfelix , I hope this feature could be added as a feature in the coming version RUST 2021 just like the feature fstring:implicit format arguments. Hopefully, this could make it more feasible to transfer python code to rust.

pnkfelix

comment created time in 13 hours

pull request commentrust-lang/rfcs

Allow Overloading || and &&

:bell: This is now entering its final comment period, as per the review above. :bell:

Nokel81

comment created time in 21 hours

pull request commentrust-lang/rfcs

Scrape code examples from `examples/` directory for Rustdoc

I hope to leave a more useful comment at some point, but I wanted to at least jot these thoughts down before I lose them:

  • It would be nice to extend this to all code blocks in the docs.
  • It would be nice to click on the types / methods inside the code block and link back to the function.
  • I worry about the medium- and long-tail of customization. Some possible things people are going to want:
    • #[cfg] directives
    • the ability to hide / show pieces of code
    • the ability to add prose into the example (rustdoc /// comments inside the example; recursively. shudder)
willcrichton

comment created time in a day

PR opened rust-lang/rustc-dev-guide

not all tools require waiting for a nightly release before they can be fixed

For example, Miri installs a recent toolchain directly from the master branch using rustup-toolchain-install-master.

This fixes the docs so they are no longer incorrect for Miri. I do not know what other tools do.

+10 -6

0 comment

1 changed file

pr created time in a day

pull request commentrust-lang/rfcs

Scrape code examples from `examples/` directory for Rustdoc

How about a configurable limit on the number of examples for any given function? Like --max-scraped-examples N as a flag to Rustdoc.

That's an option on top of another option, definitely not a fan. I think the solution here would be in the UI.

Yes, I discussed this in the RFC. Currently I match on the domain of the package.repository field of the manifest and special-case generate a link to the source viewer for that repo. However, if Rustdoc were changed to include examples in HTML, then I could just link to those.

Well, nothing prevents us to generate it. Currently we don't because we have no use for them.

willcrichton

comment created time in a day

pull request commentrust-lang/rfcs

Scrape code examples from `examples/` directory for Rustdoc

Other related issues:

  • https://github.com/rust-lang/docs.rs/issues/132
  • https://github.com/rust-lang/docs.rs/issues/238 (the title says binary, but examples are just special cases of binaries and I mention in the issue that we could generate documentation for all the example crates in the package too).

For docs.rs specifically we already host all the source files from the package independently of rustdoc's source html output. So we could use something like --example-src-base-path=/crate/foobar/0.1.0/source/ to tell rustdoc how to generate links to the source files.

willcrichton

comment created time in a day

pull request commentrust-lang/rfcs

Scrape code examples from `examples/` directory for Rustdoc

In some crates, it could lead to a lot of links. I like idea though, not just a big fan of the current approach. If we wanted to use it on gtk-rs for example, some items would have a lot of examples, very likely too many.

How about a configurable limit on the number of examples for any given function? Like --max-scraped-examples N as a flag to Rustdoc.

Also, in your current implementation, you seem to link to the file using a github URL. I don't think this is the right approach considering that it would force us to support other repositories host websites (exposing us to URL scheme change if any), and that would simply not work if there is no website. I guess we could generate the examples in HTML like we do for source code?

Yes, I discussed this in the RFC. Currently I match on the domain of the package.repository field of the manifest and special-case generate a link to the source viewer for that repo. However, if Rustdoc were changed to include examples in HTML, then I could just link to those.

willcrichton

comment created time in a day

pull request commentrust-lang/rfcs

Scrape code examples from `examples/` directory for Rustdoc

In some crates, it could lead to a lot of links. I like idea though, not just a big fan of the current approach. If we wanted to use it on gtk-rs for example, some items would have a lot of examples, very likely too many.

Also, in your current implementation, you seem to link to the file using a github URL. I don't think this is the right approach considering that it would force us to support other repositories host websites (exposing us to URL scheme change if any), and that would simply not work if there is no website. I guess we could generate the examples in HTML like we do for source code?

willcrichton

comment created time in a day

pull request commentrust-lang/rfcs

Scrape code examples from `examples/` directory for Rustdoc

What prevents MyType::new from linking to every example?

Nothing -- under this proposal, MyType::new would be linked to every call to it. If every example calls MyType::new, then every example will get linked.

How do you choose which examples are in line and which are in the see more link?

Currently, it's arbitrary, whichever example happens to get found first. I'm open to suggestions for more systematic ways to decide how to sort the examples.

willcrichton

comment created time in 2 days

pull request commentrust-lang/rfcs

Scrape code examples from `examples/` directory for Rustdoc

What prevents MyType::new from linking to every example? How do you choose which examples are in line and which are in the see more link?

willcrichton

comment created time in 2 days

pull request commentrust-lang/rfcs

Scrape code examples from `examples/` directory for Rustdoc

@shepmaster I don't think those issues are closely related. Those are about making it easier to manually write examples and guides, this is about automatically generating docs for existing examples. Manual docs will always be used less than automatic docs just because they take more effort to write.

willcrichton

comment created time in 2 days

pull request commentrust-lang/rfcs

Scrape code examples from `examples/` directory for Rustdoc

See also:

  • https://github.com/rust-lang/docs.rs/issues/1293

  • https://github.com/rust-lang/rfcs/pull/3081

  • https://github.com/rust-lang/rust/issues/66249

willcrichton

comment created time in 2 days

PR opened rust-lang/rfcs

Scrape code examples from `examples/` directory for Rustdoc
+139 -0

0 comment

1 changed file

pr created time in 2 days