profile
viewpoint
Steve Klabnik steveklabnik @oxidecomputer Austin, TX http://steveklabnik.com All i'm trying to do is enjoy every day to the fullest with my Pokémon.

github/opensource.guide 7164

📚 Community guides for open source creators

intermezzOS/kernel 1166

A hobby operating system, in Rust

d-unseductable/ruru 762

Native Ruby extensions written in Rust

ashleygwilliams/breakfast-repo 373

a collection of videos, recordings, and podcasts to accompany our morning coffee

jcasimir/locale_setter 122

A simple library to set request locale based on a hierarchy of factors

judofyr/timeless 120

A mixture of a blog, wiki and CMS, inspired by Christoffer Sawicki's Termos and James Adam's Vanilla.rb

nikomatsakis/office-hours 114

Help me help you!

assert-rs/dir-diff 35

Are the contents of two directories different?

rust-dev-tools/dev-tools-team 34

resources for the Rust dev-tools team

qrush/shp 28

A new UI for git. This doesn't work yet.

push eventrust-lang/book

Jahwi

commit sha c981c7174a2482bd0986599eff8a7f7bd46907ed

Correct listing 11-10: Take test module out of main function.

view details

Steve Klabnik

commit sha c0a6a61b8205da14ac955425f74258ffd8ee065d

Merge pull request #2427 from jahwi/master Correct listing 11-10: Take tests module out of main function.

view details

push time in 34 minutes

Pull request review commentrust-lang/rust

Document the unsafe keyword

 mod type_keyword {}  #[doc(keyword = "unsafe")] //-/// Code or interfaces whose [memory safety] cannot be verified by the type system.+/// Code or interfaces whose [memory safety] cannot be verified by the type+/// system.+///+/// The `unsafe` keyword has two uses: to declare the existence of contracts the+/// compiler can't check (`unsafe fn` and `unsafe trait`), and to declare that a+/// programmer has checked that these contracts have been upheld (`unsafe {}`+/// and `unsafe impl`, but also `unsafe fn` -- see below). They are not mutually+/// exclusive, as can be seen in `unsafe fn`.+///+/// # Unsafe abilities+///+/// **No matter what, Safe Rust can't cause Undefined Behavior**. This is+/// referred to as [soundness]: a well-typed program actually has the desired+/// properties. The [Nomicon][nomicon-soundness] has a more detailed explanation+/// on the subject.+///+/// To ensure soundness, Safe Rust is restricted enough that it can be+/// automatically checked. Sometimes, however, it is necessary to write code+/// that is correct for reasons which are too clever for the compiler to+/// understand. In those cases, you need to use Unsafe Rust.+///+/// Here are the abilities Unsafe Rust has in addition to Safe Rust:+///+/// - Dereference [raw pointers]+/// - Implement `unsafe` [`trait`]s+/// - Call `unsafe` functions+/// - Mutate [`static`]s (including [`extern`]al ones)+/// - Access fields of [`union`]s+///+/// However, this extra power comes with extra responsibilities: it is now up to+/// you to ensure soundness. The `unsafe` keyword helps by clearly marking the+/// pieces of code that need to worry about this.+///+/// ## The different meanings of `unsafe`+///+/// Not all uses of `unsafe` are equivalent: some are here to mark the existence+/// of a contract the programmer must check, others are to say "I have checked+/// the contract, go ahead and do this". The following+/// [discussion on Rust Internals] has more in-depth explanations about this but+/// here is a summary of the main points:+///+/// - `unsafe fn`: calling this function means abiding by a contract the+/// compiler cannot enforce.+/// - `unsafe trait`: implementing the [`trait`] means abiding by a+/// contract the compiler cannot enforce.+/// - `unsafe {}`: the contract necessary to call the operations inside the+/// block has been checked by the programmer and is guaranteed to be respected.+/// - `unsafe impl`: the contract necessary to implement the trait has been+/// checked by the programmer and is guaranteed to be respected.+///+/// As of now (Rust 1.44), `unsafe fn` also acts like an `unsafe {}` block+/// around the code inside the function. This means it is not just a signal to+/// the caller, but also promises that the preconditions for the operations+/// inside the function are upheld. Mixing these two meanings can be confusing+/// and [proposal]s exist to use `unsafe {}` blocks inside such functions when+/// making `unsafe` operations.+///+/// See the [Rustnomicon] and the [Reference] for more informations. ///-/// The documentation for this keyword is [not yet complete]. Pull requests welcome!+/// # Examples+///+/// ## Marking elements as `unsafe`+///+/// `unsafe` can be used on functions. Note that functions and statics declared+/// in [`extern`] blocks are implicitly marked as `unsafe` (but not functions+/// declared as `extern "something" fn ...`). Mutable statics are always unsafe,+/// wherever they are declared. Methods can also be declared as `unsafe`:+///+/// ```rust+/// # #![allow(dead_code)]+/// static mut FOO: &str = "hello";+///+/// unsafe fn unsafe_fn() {}+///+/// extern "C" {+///     fn unsafe_extern_fn();+///     static BAR: *mut u32;+/// }+///+/// trait SafeTraitWithUnsafeMethod {+///     unsafe fn unsafe_method(&self);+/// }+///+/// struct S;+///+/// impl S {+///     unsafe fn unsafe_method_on_struct() {}+/// }+/// ```+///+/// Traits can also be declared as `unsafe`:+///+/// ```rust+/// unsafe trait UnsafeTrait {}+/// ``` ///+/// Since `unsafe fn` and `unsafe trait` indicate that there is a safety+/// contract that the compiler cannot enfore, documenting it is important. The
/// contract that the compiler cannot enforce, documenting it is important. The
poliorcetics

comment created time in 37 minutes

Pull request review commentrust-lang/rust

Document the unsafe keyword

 mod type_keyword {}  #[doc(keyword = "unsafe")] //-/// Code or interfaces whose [memory safety] cannot be verified by the type system.+/// Code or interfaces whose [memory safety] cannot be verified by the type+/// system.+///+/// The `unsafe` keyword has two uses: to declare the existence of contracts the+/// compiler can't check (`unsafe fn` and `unsafe trait`), and to declare that a+/// programmer has checked that these contracts have been upheld (`unsafe {}`+/// and `unsafe impl`, but also `unsafe fn` -- see below). They are not mutually+/// exclusive, as can be seen in `unsafe fn`.+///+/// # Unsafe abilities+///+/// **No matter what, Safe Rust can't cause Undefined Behavior**. This is+/// referred to as [soundness]: a well-typed program actually has the desired+/// properties. The [Nomicon][nomicon-soundness] has a more detailed explanation+/// on the subject.+///+/// To ensure soundness, Safe Rust is restricted enough that it can be+/// automatically checked. Sometimes, however, it is necessary to write code+/// that is correct for reasons which are too clever for the compiler to+/// understand. In those cases, you need to use Unsafe Rust.+///+/// Here are the abilities Unsafe Rust has in addition to Safe Rust:+///+/// - Dereference [raw pointers]+/// - Implement `unsafe` [`trait`]s+/// - Call `unsafe` functions+/// - Mutate [`static`]s (including [`extern`]al ones)+/// - Access fields of [`union`]s+///+/// However, this extra power comes with extra responsibilities: it is now up to+/// you to ensure soundness. The `unsafe` keyword helps by clearly marking the+/// pieces of code that need to worry about this.+///+/// ## The different meanings of `unsafe`+///+/// Not all uses of `unsafe` are equivalent: some are here to mark the existence+/// of a contract the programmer must check, others are to say "I have checked+/// the contract, go ahead and do this". The following+/// [discussion on Rust Internals] has more in-depth explanations about this but+/// here is a summary of the main points:+///+/// - `unsafe fn`: calling this function means abiding by a contract the+/// compiler cannot enforce.+/// - `unsafe trait`: implementing the [`trait`] means abiding by a+/// contract the compiler cannot enforce.+/// - `unsafe {}`: the contract necessary to call the operations inside the+/// block has been checked by the programmer and is guaranteed to be respected.+/// - `unsafe impl`: the contract necessary to implement the trait has been+/// checked by the programmer and is guaranteed to be respected.+///+/// As of now (Rust 1.44), `unsafe fn` also acts like an `unsafe {}` block

We don't put version numbers like this in docs, removing everything before the comma is good :)

/// `unsafe fn` also acts like an `unsafe {}` block
poliorcetics

comment created time in 37 minutes

issue commentrust-lang/core-team

Discord whitepaper

No update this week

pietroalbini

comment created time in a day

issue commentrust-lang/core-team

Cloudflare whitepaper

No update this week

pietroalbini

comment created time in a day

issue commentrust-lang/core-team

CleverCloud whitepaper

No update this week

pietroalbini

comment created time in a day

issue commentrust-lang/core-team

TiKV whitepaper

No update this week

pietroalbini

comment created time in a day

issue commentrust-lang/core-team

Clarify the Rust compiler's licensing status

No update this week

pietroalbini

comment created time in a day

issue commentrust-lang/core-team

Consider pulling the Citizen Code of Conduct (partially) to a rust-lang repository

Everyone is still on board, just need to do the work.

skade

comment created time in a day

issue commentrust-lang/core-team

Target tier policy RFC

No updates this week

pietroalbini

comment created time in a day

issue commentrust-lang/core-team

2021 Edition RFC

Today: niko and I need to chat about the feedback we've gotten, stuff has died down

nikomatsakis

comment created time in a day

issue commentrust-lang/core-team

permissions on blog.rust-lang.org

People are generally in favor, especially for inside rust.

nikomatsakis

comment created time in a day

issue closedrust-lang/rust-by-example

Arc chapter

Add information about Arc<T> to https://rustbyexample.com/std.html

closed time in 2 days

japaric

issue commentrust-lang/cargo

Post-build script execution

If there is one, it's not one that's well-known to me.

I am not on the Cargo team, but IMHO, this does deserve an RFC, because even if it is a small feature on its own, it would need to be coherently designed alongside any other desired lifecycle hooks.

vosen

comment created time in 2 days

pull request commentrust-lang/rust

Document why Vec::with_capacity is useful

I pretty much agree with all of your points, @LukasKalbertodt . I think adding a section that explains this is a great idea, but this needs some tweaks.

jyn514

comment created time in 2 days

create barnchsteveklabnik/totally-not-semver

branch : the-road-to-1.0

created branch time in 5 days

push eventsteveklabnik/totally-not-semver

Steve Klabnik

commit sha 0468b87a461ce44a24844be7a539ae998ccd5509

Update README.md

view details

push time in 5 days

created repositorysteveklabnik/totally-not-semver

created time in 5 days

issue commentrust-lang/cargo

Post-build script execution

@ianrrees the general idea has been stuck in "RFC hell" for a while; I am doing the same thing (roughly) as you, but using https://github.com/matklad/cargo-xtask (which links to one of the proposals for stuff in this space) as a polyfill in the meantime.

vosen

comment created time in 7 days

issue commentrust-lang/core-team

TiKV whitepaper

update this week: @nrc has gotten access from @skade

pietroalbini

comment created time in 8 days

issue commentrust-lang/core-team

Governance WG checkin

No updates this week.

pietroalbini

comment created time in 8 days

issue commentrust-lang/core-team

2021 Edition RFC

today: just a general "hey check out this RFC, we'll have to decide on it eventually." Lots of comments!

nikomatsakis

comment created time in 8 days

issue commentrust-lang/core-team

Target tier policy RFC

No updates this week.

pietroalbini

comment created time in 8 days

issue commentrust-lang/core-team

Rust Survey for 2020

No updates this week

pietroalbini

comment created time in 8 days

issue commentrust-lang/core-team

Licensing terms for the forums

Niko's on vacation, no updates

carols10cents

comment created time in 8 days

issue commentrust-lang/core-team

Clarify the Rust compiler's licensing status

No update this week

pietroalbini

comment created time in 8 days

push eventrust-lang/book

Istratov Dmitrii

commit sha 6ffa36f9137a500ef43590d715d63859ddb93e93

update link to russian translation

view details

Steve Klabnik

commit sha 7d3c7b1f423b209eaeddc26b364bc98736e88eb5

Merge pull request #2423 from funkill/patch-1 Update link to russian translation

view details

push time in 8 days

PR merged rust-lang/book

Update link to russian translation

We rename organization and repo

+1 -1

0 comment

1 changed file

funkill

pr closed time in 8 days

startedwithoutboats/propane

started time in 8 days

issue commentrust-lang/rust

uninitialized variable in loop gives incorrect error

Triage: no changes

squirrelyman

comment created time in 9 days

Pull request review commentoxidecomputer/dropshot

formatting with rustfmt-2.0.0-rc.2

 mod test {             "project_id"         ]);         assert_eq!(result.variables.get("project_id").unwrap(), "p12345");-        assert!(router-            .lookup_route(&Method::GET, "/projects/p12345/child")-            .is_err());+        assert!(+            router+                .lookup_route(&Method::GET, "/projects/p12345/child")+                .is_err()+        );

ah, i mis-read handler.rs as router.rs, oops 😓

(I am also neutral tbh)

ahl

comment created time in 9 days

Pull request review commentrust-lang/rust

Document that slice refers to any pointer type to a sequence

 mod prim_array {} /// /// *[See also the `std::slice` module](slice/index.html).* ///-/// Slices are a view into a block of memory represented as a pointer and a-/// length.+/// A slice is any pointer/reference to a block of memory. They are represented+/// as a regular pointer and a length.

After years of this, I don't think this is the kind of thing we can change, no. But it also wouldn't be something that could be done in a PR like this, it would have to be done in the reference, get the lang team involved.

MrModder

comment created time in 9 days

issue commentrust-lang/rust

x.py expects python3.exe on Windows

Very odd; I use "python x.py" on Windows just fine.

Kixiron

comment created time in 10 days

Pull request review commentoxidecomputer/dropshot

try to give the user better failure messages

 features = [ "uuid" ]  [dev-dependencies] libc = "0.2.71"-difference = "2.0.0"+difference = "2.0"

yes, these two lines are equivalent. I personally always put all three numbers, but the tools will support either of these until the end of all time

ahl

comment created time in 10 days

Pull request review commentoxidecomputer/dropshot

formatting with rustfmt-2.0.0-rc.2

 mod test {             "project_id"         ]);         assert_eq!(result.variables.get("project_id").unwrap(), "p12345");-        assert!(router-            .lookup_route(&Method::GET, "/projects/p12345/child")-            .is_err());+        assert!(+            router+                .lookup_route(&Method::GET, "/projects/p12345/child")+                .is_err()+        );

I'm guessing this is the change youre not a fan of? because the other one actually looks good to me!

ahl

comment created time in 10 days

Pull request review commentoxidecomputer/dropshot

formatting with rustfmt-2.0.0-rc.2

 where  */ trait GetMetadata {     fn metadata(loc: ApiEndpointParameterLocation)-        -> Vec<ApiEndpointParameter>;+    -> Vec<ApiEndpointParameter>;

this.... seems like a bug to me

ahl

comment created time in 10 days

pull request commentsteveklabnik/semver

semver-parser 0.10.0

@hone checking on this; did you want me to merge it now, or did you want to try to tackle the TODOs first? It wasn't clear to me :)

hone

comment created time in 11 days

Pull request review commentrust-lang/rust

Document that slice refers to any pointer type to a sequence

 mod prim_array {} /// /// *[See also the `std::slice` module](slice/index.html).* ///-/// Slices are a view into a block of memory represented as a pointer and a-/// length.+/// A slice is any pointer/reference to a block of memory. They are represented+/// as a regular pointer and a length.

Yes, this wording is definitely incorrect, but it's also tricky, because "slice" has contextual meaning. We tend to call both [T] and &[T] "slices". The issue why this is incorrect is that a slice is more than only a pointer, it's a pointer plus a length. And, as you've noted the "regular" terminology is... irregular :)

MrModder

comment created time in 11 days

issue commentrust-lang/rust-by-example

Arc chapter

Looks like you got the mechanics right, yep! I don't have time to review right now, but I or someone else will get to it. Thank you!

japaric

comment created time in 11 days

push eventrust-lang/book

Hugh Rundle

commit sha 52b0d291d2000dfebfd0ad470bdd11bb91985439

replace commas with m-dashes to improve readability of chapter 4.1 This commit makes a minor punctuation change to make the sentence clearer to read and less ambiguous.

view details

Steve Klabnik

commit sha 363293c1c5ce9e84ea3935a5e29ce8624801208a

Merge pull request #2419 from hughrun/4-1-emdash replace commas with m-dashes to improve readability of chapter 4.1

view details

push time in 11 days

PR merged rust-lang/book

replace commas with m-dashes to improve readability of chapter 4.1

This commit makes a minor punctuation change to make the sentence clearer to read and less ambiguous.

Resolves #2412

+2 -2

0 comment

1 changed file

hughrun

pr closed time in 11 days

issue closedrust-lang/book

Chapter 4.1 - consider change to punctuation to make sentence clearer

There is potentially confusing punctuation in this section of Chapter 4.1:

Stack-Only Data: Copy

There’s another wrinkle we haven’t talked about yet. This code using integers, part of which was 
shown in Listing 4-2, works and is valid:

On my initial read this looked like a typo which should have read This code is using integers...

I suggest replacing the commas with dashes to make the sentence clearer:

This code using integers – part of which was shown in Listing 4-2 – works and is valid:

closed time in 11 days

hughrun

issue closedrust-lang/book

A command copied to the clipboard contains the `$` prefix

Hi everyone 👋

When I click on the copy button at the right of a code snippet (ex: https://doc.rust-lang.org/book/ch01-01-installation.html), the command is copied to the clipboard but with the extraneous $ sign.

People not used to a command line (or who didn't read the disclaimer carefully) might find it confusing because pasting+enter won't work Deleting the $ sign also requires an extra step.

My setup : FF 78.0.2 on MacOS

closed time in 11 days

borsini

issue commentrust-lang/book

A command copied to the clipboard contains the `$` prefix

Hi! This is something that upstream would have to deal with; please file a bug on mdbook. Thanks!

borsini

comment created time in 11 days

Pull request review commentrust-lang/rust

Slice strip

 impl<T> [T] {      /// Returns a subslice with the prefix removed.     ///-    /// This method returns [`None`] if slice does not start with `prefix`.-    /// Also it returns the original slice if `prefix` is an empty slice.+    /// If the slice starts with `prefix`, returns+    /// the subslice after the prefix, wrapped in `Some`.+    ///+    /// If the slice does not start with `prefix`, returns `None`.+    ///+    /// (If `prefix` is empty, simply returns the original slice.)

No need for parenthesis around these.

ijackson

comment created time in 11 days

Pull request review commentrust-lang/rust

Slice strip

 impl str {      /// Returns a string slice with the prefix removed.     ///-    /// If the string starts with the pattern `prefix`, `Some` is returned with the substring where-    /// the prefix is removed. Unlike `trim_start_matches`, this method removes the prefix exactly-    /// once.+    /// If the string starts with the pattern `prefix`, returns

these lines are wrapped much, much shorter than the old ones were. What column did you wrap these to?

ijackson

comment created time in 11 days

issue closedrust-lang/rust

`std::iter::count` and `std::iter::count_with` functions

It would be great to have these functions, which would behave similarly to the once / once_with and repeat / repeat_with functions, except they would iterate a fixed number of times (given by a usize) instead of just once/infinitely.

closed time in 11 days

alexreg

issue commentrust-lang/rust

`std::iter::count` and `std::iter::count_with` functions

Triage: it's been a year. If anyone is interested in implementing this and doing benchmarks, please send in a pull request if it is indeed better than the map. Thanks.

alexreg

comment created time in 11 days

issue closedrust-lang/rust

Bootstrap bug

Bootstraping rustc on cygwin failed, because cygwin use another pathes, than windows. Cargo cann't build project. It's need fix getting abspath on cygwin.

closed time in 11 days

aristarh2704

issue commentrust-lang/rust

Bootstrap bug

Hi there! It has been a long time, and there's few details in this bug. I'm going to give it a close, but if you're still seeing this issue, please open a new bug with the exact commands you're trying, error messages, and other context. Thanks!

aristarh2704

comment created time in 11 days

issue commentrust-lang/book

Chapter 4.1 - consider change to punctuation to make sentence clearer

Sure, I would happily take a PR that uses an em dash here.

hughrun

comment created time in 13 days

Pull request review commentrust-lang/book

Update paragraph about rustfmt in Chapter 1.2

 requires these around all function bodies. It’s good style to place the openin curly bracket on the same line as the function declaration, adding one space in between. -At the time of this writing, an automatic formatter tool called `rustfmt` is-under development. If you want to stick to a standard style across Rust-projects, `rustfmt` will format your code in a particular style. The Rust team-plans to eventually include this tool with the standard Rust distribution, like-`rustc`. So depending on when you read this book, it might already be installed-on your computer! Check the online documentation for more details.+If you want to stick to a standard style across Rust projects, you can use an +automatic formatter tool called `rustfmt` to format your code in a particular+style. The Rust team has included this tool with the standard Rust distribution,+like `rustc`, so it should already be installed on your computer! Check the online+documentation for more details.

I believe so; I have to actually have the time to review it again, but I think it should be fine.

rashiq

comment created time in 13 days

PR closed rust-lang/book

Looks like a typo
+1 -1

1 comment

1 changed file

imbolc

pr closed time in 13 days

pull request commentrust-lang/book

Looks like a typo

This is not a typo; closures can capture more than one variable. Thanks!

imbolc

comment created time in 13 days

issue commentrust-lang/rust-by-example

Arc chapter

Sure thing!

So, on GitHub, the main way that you send in updates is by sending a pull request, that is, a request to pull changes from your repository into the main repository. Here's GitHub's docs on how to start one: https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests

But! I can also explain. So, ....... oh wait, you just edited your comment, so looks like you know what's going on. Give it a shot and let me know :) If you get stuck, I can help!

japaric

comment created time in 13 days

issue commentrust-lang/rust

strange end span in borrowck error

Triage: that's still the output today.

nikomatsakis

comment created time in 14 days

pull request commentrust-lang/rfcs

Edition 2021 and beyond

So, thinking about this, rather than just typing out immediately, I think that my issue here isn't inherently separating the concepts, it's saying that we should talk about the at different times. Like, I do really like this "retrospective" nomenclature. It's just that I feel like, we only get so many chances to get folks' attention, and the time that we ship an edition is when people are going to pay attention anyway. Splitting the two weakens both. I think saying "hey, we're doing the 2021 edition, alongside a retrospective" makes a bunch of sense.

I still disagree with only shipping editions on a needed basis. Trains are good. Predictability is important. And having some release schedules happen on a train basis, and some happen on not, ends up being really confusing. I would also still like us to eventually adopt an LTS, and would advocate for it to be on a train schedule as well.

nikomatsakis

comment created time in 14 days

pull request commentrust-lang/rfcs

Edition 2021 and beyond

@Lokathor @SimonSapin thanks. I still disagree, but I understand your positions better, at least.

nikomatsakis

comment created time in 14 days

pull request commentrust-lang/rfcs

Edition 2021 and beyond

The entire idea is that I shouldn't need to notice.

Maybe this is where we diverge, regardless of if you should or should not need to notice, people are going to notice.

nikomatsakis

comment created time in 14 days

pull request commentrust-lang/rfcs

Edition 2021 and beyond

I would be interested in people's ideas of how they would be split, practically speaking. An edition release is going to be a big release, and is going to get a lot of marketing, regardless of anyone's opinions on it. It's a thing that happens once every three years! And due to that, people are naturally going to wonder what is different since the last three years.

It seems fundamentally unescapable to me.

nikomatsakis

comment created time in 14 days

startedcbiffle/lilos

started time in 14 days

Pull request review commentrust-lang/rfcs

Edition 2021 and beyond

+- Feature Name: N/A+- Start Date: 2020-07-29+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++* Announce plans for a Rust 2021 Edition, and for a regular cadence of editions every 3 years thereafter.+    * We will roll out an edition regardless of whether there are breaking changes.+* Unlike Rust 2018, we will avoid using editions as a "deadline" to tie together high-priority projects.+    * Instead, we embrace the train model, but editions are effectively a "somewhat bigger release", giving us an opportunity to give an overview of all the work that has landed over the previous three years.+* We specify a cadence for Edition lints.+    * "Edition idiom" lints for Edition N will warn for editions before N, and become "deny by default" in Edition N.+    * Since it would be disruptive to introduce deny-by-default lints for Rust 2018 now, the Rust 2018 lints are repurposed into Rust 2021 Edition lints.+* We specify a policy on reserving keywords and other prospective changes.+    * In short, reserving keywords is allowed only as part of an active project group.++# Motivation+[motivation]: #motivation++The plan for editions was laid out in [RFC 2052] and Rust had its first edition in 2018. This effort was in many ways a success but also resulted in some difficult lessons. As part of this year's roadmap, one of the major questions we identified was that we need to decide whether we are going to do more editions and -- if so -- how we are going to manage the process.++[RFC 2052]: https://github.com/rust-lang/rfcs/blob/master/text/2052-epochs.md++This RFC proposes a specific answer to those questions:++* We will do new Rust editions on a regular, three-year cadence.+    * We will roll out an edition regardless of whether there are breaking changes.+* Unlike Rust 2018, we will avoid using editions as a "deadline" to tie together high-priority projects.+    * Instead, we embrace the train model, but editions are effectively a "somewhat bigger release", giving us an opportunity to give an overview of all the work that has landed over the previous three years.+* We specify a cadence for Edition lints.+    * "Edition idiom" lints for Edition N will warn for editions before N, and become "deny by default" in Edition N.+    * Since it would be disruptive to introduce deny-by-default lints for Rust 2018 now, the Rust 2018 lints are repurposed into Rust 2021 Edition lints.+* We specify a policy on reserving keywords and other prospective changes.+    * In short, reserving keywords is allowed only as part of an active project group.++## Expected nature of editions to come++We believe the Rust 2018 was somewhat exceptional in that it introduced changes to the module system that affected virtually every crate, even if those changes were almost completely automated. We expect that the changes introduced by most editions will be much more modest and discrete, more analogous to `async fn` (which simply introduced the `async` keyword), or the changes proposed by [RFC 2229] (which tweaks the way that closure captures work to make them more precise).++The "size" of changes to expect is important, because they help inform the best way to ship editions. Since we expect most changes to be relatively small, we would like to design a system that allows us to judge those changes individually, without having to justify an edition by having a large number of changes combined together. Moreover, we'd like to have editions happening on a predictable cadence, so that we can take that cadence into account when designing and implementing features (i.e., so that we can try to tackle changes that may require migrations earlier, to give plenty of time).++## Key ideas of edition do not change++Just as with Rust 2018, we are firmly committed to the core concepts of an edition:++* Crates using older editions continues to compile in the newer+  compiler, potentially with warnings.+* Crates using different editions can interoperate, and people can+  upgrade to newer editions on their own schedule.+* Code that compiles without a warning on Edition N should also+  compile on Edition N + 1.+* Migration between editions should generally be automated.+* Editions make "skin-deep" changes, with all editions ultimately+  compiling to a single common representation.++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++We use this section to try and convey the story that average users will need to understand.++## What is a Rust edition?++Every three years, we introduce a new Rust Edition. These editions are named after the year in which they occur, like Rust 2015 or Rust 2018. Each crate specifies the Rust edition that it requires in its `Cargo.toml` file via a setting like `edition = "2018"`. The purpose of editions is to give us a chance to introduce "opt-in" changes like new keywords that would otherwise have the potential to break existing code.++When we introduce a new edition, we don't remove support for the older ones, so all crates continue to compile just as they ever did. Moreover, editions are fully interoperable, so there is no possibility of an "ecosystem split". This means that you can upgrade your crates to the new edition on whatever schedule works best for you.++The release of a new edition is always a celebratory affair. It gives us a chance to look back at all the work that has gotten done over the last three years. The "opt-in" changes also allow us to introduce new features or syntax that would otherwise be impossible.++## How do I upgrade between editions?++Upgrading between editions is meant to be easy. The general rule is, if your code compiles without warnings, you should be able to opt into the new edition, and your code will compile.++Along with each edition, we also release support for it in a tool called `rustfix`, which will automatically migate your code from the old edition to the new edition, preserving semantics along the way. You may have to do a bit of cleanup after the tool runs, but it shouldn't be much.++## "Migrations" in an edition vs "idiom lints"++When we release a new edition, it comes together with a certain set of "migrations". Migrations are the "breaking changes" introduced by the edition, except of course that since editions are opt-in, no code actually breaks. For example, if we introduce a new keyword, you will have to rename variables or functions using the old keyword, or else use Rust's `r#keyword` feature (which allows you to use a keyword as a regular variable/function/type name). As mentioned before, the edition comes with tooling that will make these changes for you, though sometimes you will want to cleanup the resulting code afterwards.++In addition to those migrations, editions also come with a set of "idiom lints". These lints warn against deprecated patterns that we wish to discourage, even though they continue to work. Since these are lints, they don't cause your code to stop compiling. ++To encourage folks to migrate, these lints are "stepped up" in severity based on the edition. For an idiom lint introduced as part of Edition N, the lint will warn-by-default for earlier editions, and become deny-by-default only for code in Edition N.++As an exception, the Rust 2018 idiom lints will warn-by-default during Rust 2018 and become deny-by-default in Rust 2021 (effectively, they are being "repurposed" as 2021 idiom lints). This is because we never made them into warnings by default in 2018, and it would be disruptive to suddenly have them start erroring on existing code now.++Like migrations, idiom lints are expected to come with automatic tooling for rewriting your code. However, in the limit, that tooling can be as simple as inserting an `#![allow(lint_x)]` at the crate level, although we'd prefer to avoid that.++## The edition guide++The [edition guide](https://doc.rust-lang.org/edition-guide/introduction.html) documents each of Rust's editions and the various migrations and idiom lints that were introduced as part of it. It will be updated to use the terminology from this RFC, naturally, and be updated during each edition.++# Reference-level explanation+[reference-level-explanation]: #reference-level-explanation++We use this section to answer detailed questions.++## Integrating the 3-year cadence into our roadmap planning++It is expected that the 3-year edition cadence can inform our roadmap and feature planning. In particular, larger features or features that may require migrations should be coordinated to begin work earlier in the 3-year cadence.++## Migrations++Migrations are the "breaking changes" that we make as part of an edition transition (except of course that they don't break any code). We want to ensure a smooth user experience, so each such change must either:++* Have automated, rustfix-compatible tooling that will ensure that old code continues to work in the new edition with the same semantics as before.+* Or, be expected to occur *very* rarely, as evidenced by crater runs and experience. In these cases, it is preferable if the migration causes a compilation error, rather than silently changing semantics.++In some cases, migrations can come with a combination. For example, there may be tooling to port old code that works the vast majority of the time but occasionally fails (this can happen around macros).++## Project group to manage the edition release++For each Edition release, we will create a project group to track the edition changes and decide on what features are to be included.  This group is a subgroup of the release team, and should contain representatives from the compiler, lang, and dev-tools teams. The group is empowered to set a schedule for when changes must be ready in order to be included in the edition, and to enforce that schedule as needed -- this includes removing features from the edition if they are not ready in time or the quality is judged to be insufficient (e.g., if the migration tooling is too buggy). The edition project group is also expected to ensure that the [edition guide](https://doc.rust-lang.org/edition-guide/introduction.html) is updated with accurate information.++## Idiom lint transitions++"Idiom lints" are issued in a lint group named after the edition year, such as `rust_2018_idioms`. They are warn-by-default in the previous edition, and are deny by default in the new edition.++Idiom lints are encouraged but not required to produce "rustfix"-compatible suggestions.++## Keyword reservation policy++One question that comes up around editions is whether to reserve keywords which we think we *might* want but for which we don't have a particular use in mind yet. For the Rust 2018 edition, we opted not to reserve any such keywords, and in this RFC we re-affirm that policy.++The policy is that **new keywords can be introduced in an edition only as part of a design with an accepted RFC**. Note that if there is an accepted RFC for some design that introduces a new keyword, but the design is not yet fully implemented, then the edition might still make that keyword illegal. This way, the way is clear when the time comes to introduce that keyword in the future. As an example, this is what happened with async/await: the async keyword was introduced as part of the 2018 edition, but didn't do anything until later in the release cycle.++The motivation here is that any attempt to figure out a reasonable set of keywords to reserve seems inevitably to turn into "keyword fishing", where we wind up with a long list of potential keywords. This ultimately leads to user confusion and a degraded experience. Given that editions come on a regular basis, it suffices to simply allow the keyword to be reserved in the next edition. If we really want to expose the feature earlier, then a macro or other workaround can be used in the interim (and transitioned automatically as part of the move to the next edition).++# Drawbacks+[drawbacks]: #drawbacks++The primary drawbacks of doing editions at all are as follows:++* Coordinating an edition release is a stressor on the organization, as we have to coordinate the transition tooling, documentation, and other changes. This was particularly true in the original formulation of the editions, which put a heavy emphasis on the "feature-driven" nature of the 2018 Edition (i.e., the goal was to release new and exciting features, not to look back on work that had already been completed).+* Transitioning to a new edition, even if optional, is an ask for our users. Some production users expressed frustration at having to spend the time upgading their crates to the new edition. Even with tooling, the task requires time and effort to coordinate. At this stage in Rust's life, "production use" often implies "commercial use," and time and effort means "money" to them. Asking too much could harm Rust's commercial prospects, with all of the secondary impacts that has on the not-for-profit ecosystem as well. 

When would you need a dependency to be upgraded to a new edition? Given that there's edition interoperability, it shouldn't matter, right?

nikomatsakis

comment created time in 15 days

pull request commentrust-lang/rfcs

Edition 2021 and beyond

Timing is a good question; for me, I saw this RFC as trying to set out broad policy, and then it's up to the teams to implement said policy. I'm not sure if the timing, other than being in a certain year, is worth encoding into policy yet. That being said, we do have some data that planning so late in the year makes things likely to turn into a crunch, so it's probably a good idea to try and shoot for the middle of the year, so maybe that should just be policy.

nikomatsakis

comment created time in 15 days

Pull request review commentrust-lang/rfcs

Edition 2021 and beyond

+- Feature Name: N/A+- Start Date: 2020-07-29+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++* Announce plans for a Rust 2021 Edition, and for a regular cadence of editions every 3 years thereafter.+    * We will roll out an edition regardless of whether there are breaking changes.+* Unlike Rust 2018, we will avoid using editions as a "deadline" to tie together high-priority projects.+    * Instead, we embrace the train model, but editions are effectively a "somewhat bigger release", giving us an opportunity to give an overview of all the work that has landed over the previous three years.+* We specify a cadence for Edition lints.+    * "Edition idiom" lints for Edition N will warn for editions before N, and become "deny by default" in Edition N.+    * Since it would be disruptive to introduce deny-by-default lints for Rust 2018 now, the Rust 2018 lints are repurposed into Rust 2021 Edition lints.+* We specify a policy on reserving keywords and other prospective changes.+    * In short, reserving keywords is allowed only as part of an active project group.++# Motivation+[motivation]: #motivation++The plan for editions was laid out in [RFC 2052] and Rust had its first edition in 2018. This effort was in many ways a success but also resulted in some difficult lessons. As part of this year's roadmap, one of the major questions we identified was that we need to decide whether we are going to do more editions and -- if so -- how we are going to manage the process.++[RFC 2052]: https://github.com/rust-lang/rfcs/blob/master/text/2052-epochs.md++This RFC proposes a specific answer to those questions:++* We will do new Rust editions on a regular, three-year cadence.+    * We will roll out an edition regardless of whether there are breaking changes.+* Unlike Rust 2018, we will avoid using editions as a "deadline" to tie together high-priority projects.+    * Instead, we embrace the train model, but editions are effectively a "somewhat bigger release", giving us an opportunity to give an overview of all the work that has landed over the previous three years.+* We specify a cadence for Edition lints.+    * "Edition idiom" lints for Edition N will warn for editions before N, and become "deny by default" in Edition N.+    * Since it would be disruptive to introduce deny-by-default lints for Rust 2018 now, the Rust 2018 lints are repurposed into Rust 2021 Edition lints.+* We specify a policy on reserving keywords and other prospective changes.+    * In short, reserving keywords is allowed only as part of an active project group.++## Expected nature of editions to come++We believe the Rust 2018 was somewhat exceptional in that it introduced changes to the module system that affected virtually every crate, even if those changes were almost completely automated. We expect that the changes introduced by most editions will be much more modest and discrete, more analogous to `async fn` (which simply introduced the `async` keyword), or the changes proposed by [RFC 2229] (which tweaks the way that closure captures work to make them more precise).++The "size" of changes to expect is important, because they help inform the best way to ship editions. Since we expect most changes to be relatively small, we would like to design a system that allows us to judge those changes individually, without having to justify an edition by having a large number of changes combined together. Moreover, we'd like to have editions happening on a predictable cadence, so that we can take that cadence into account when designing and implementing features (i.e., so that we can try to tackle changes that may require migrations earlier, to give plenty of time).++## Key ideas of edition do not change++Just as with Rust 2018, we are firmly committed to the core concepts of an edition:++* Crates using older editions continues to compile in the newer+  compiler, potentially with warnings.+* Crates using different editions can interoperate, and people can+  upgrade to newer editions on their own schedule.+* Code that compiles without a warning on Edition N should also+  compile on Edition N + 1.+* Migration between editions should generally be automated.+* Editions make "skin-deep" changes, with all editions ultimately+  compiling to a single common representation.++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++We use this section to try and convey the story that average users will need to understand.++## What is a Rust edition?++Every three years, we introduce a new Rust Edition. These editions are named after the year in which they occur, like Rust 2015 or Rust 2018. Each crate specifies the Rust edition that it requires in its `Cargo.toml` file via a setting like `edition = "2018"`. The purpose of editions is to give us a chance to introduce "opt-in" changes like new keywords that would otherwise have the potential to break existing code.++When we introduce a new edition, we don't remove support for the older ones, so all crates continue to compile just as they ever did. Moreover, editions are fully interoperable, so there is no possibility of an "ecosystem split". This means that you can upgrade your crates to the new edition on whatever schedule works best for you.++The release of a new edition is always a celebratory affair. It gives us a chance to look back at all the work that has gotten done over the last three years. The "opt-in" changes also allow us to introduce new features or syntax that would otherwise be impossible.++## How do I upgrade between editions?++Upgrading between editions is meant to be easy. The general rule is, if your code compiles without warnings, you should be able to opt into the new edition, and your code will compile.++Along with each edition, we also release support for it in a tool called `rustfix`, which will automatically migate your code from the old edition to the new edition, preserving semantics along the way. You may have to do a bit of cleanup after the tool runs, but it shouldn't be much.++## "Migrations" in an edition vs "idiom lints"++When we release a new edition, it comes together with a certain set of "migrations". Migrations are the "breaking changes" introduced by the edition, except of course that since editions are opt-in, no code actually breaks. For example, if we introduce a new keyword, you will have to rename variables or functions using the old keyword, or else use Rust's `r#keyword` feature (which allows you to use a keyword as a regular variable/function/type name). As mentioned before, the edition comes with tooling that will make these changes for you, though sometimes you will want to cleanup the resulting code afterwards.++In addition to those migrations, editions also come with a set of "idiom lints". These lints warn against deprecated patterns that we wish to discourage, even though they continue to work. Since these are lints, they don't cause your code to stop compiling. 

Yes, I thought the same as you, Niko. Those bullets plus your amendments :)

Maybe it's worth adding a concrete example of this, to clear up confusion.

nikomatsakis

comment created time in 15 days

Pull request review commentrust-lang/rfcs

Edition 2021 and beyond

+- Feature Name: N/A+- Start Date: 2020-07-29+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++* Announce plans for a Rust 2021 Edition, and for a regular cadence of editions every 3 years thereafter.+    * We will roll out an edition regardless of whether there are breaking changes.+* Unlike Rust 2018, we will avoid using editions as a "deadline" to tie together high-priority projects.+    * Instead, we embrace the train model, but editions are effectively a "somewhat bigger release", giving us an opportunity to give an overview of all the work that has landed over the previous three years.+* We specify a cadence for Edition lints.+    * "Edition idiom" lints for Edition N will warn for editions before N, and become "deny by default" in Edition N.+    * Since it would be disruptive to introduce deny-by-default lints for Rust 2018 now, the Rust 2018 lints are repurposed into Rust 2021 Edition lints.+* We specify a policy on reserving keywords and other prospective changes.+    * In short, reserving keywords is allowed only as part of an active project group.++# Motivation+[motivation]: #motivation++The plan for editions was laid out in [RFC 2052] and Rust had its first edition in 2018. This effort was in many ways a success but also resulted in some difficult lessons. As part of this year's roadmap, one of the major questions we identified was that we need to decide whether we are going to do more editions and -- if so -- how we are going to manage the process.++[RFC 2052]: https://github.com/rust-lang/rfcs/blob/master/text/2052-epochs.md++This RFC proposes a specific answer to those questions:++* We will do new Rust editions on a regular, three-year cadence.+    * We will roll out an edition regardless of whether there are breaking changes.+* Unlike Rust 2018, we will avoid using editions as a "deadline" to tie together high-priority projects.+    * Instead, we embrace the train model, but editions are effectively a "somewhat bigger release", giving us an opportunity to give an overview of all the work that has landed over the previous three years.+* We specify a cadence for Edition lints.+    * "Edition idiom" lints for Edition N will warn for editions before N, and become "deny by default" in Edition N.+    * Since it would be disruptive to introduce deny-by-default lints for Rust 2018 now, the Rust 2018 lints are repurposed into Rust 2021 Edition lints.+* We specify a policy on reserving keywords and other prospective changes.+    * In short, reserving keywords is allowed only as part of an active project group.

Oh, and that previous RFC: https://github.com/rust-lang/rfcs/blob/master/text/2052-epochs.md

nikomatsakis

comment created time in 15 days

Pull request review commentrust-lang/rfcs

Edition 2021 and beyond

+- Feature Name: N/A+- Start Date: 2020-07-29+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++* Announce plans for a Rust 2021 Edition, and for a regular cadence of editions every 3 years thereafter.+    * We will roll out an edition regardless of whether there are breaking changes.+* Unlike Rust 2018, we will avoid using editions as a "deadline" to tie together high-priority projects.+    * Instead, we embrace the train model, but editions are effectively a "somewhat bigger release", giving us an opportunity to give an overview of all the work that has landed over the previous three years.+* We specify a cadence for Edition lints.+    * "Edition idiom" lints for Edition N will warn for editions before N, and become "deny by default" in Edition N.+    * Since it would be disruptive to introduce deny-by-default lints for Rust 2018 now, the Rust 2018 lints are repurposed into Rust 2021 Edition lints.+* We specify a policy on reserving keywords and other prospective changes.+    * In short, reserving keywords is allowed only as part of an active project group.++# Motivation+[motivation]: #motivation++The plan for editions was laid out in [RFC 2052] and Rust had its first edition in 2018. This effort was in many ways a success but also resulted in some difficult lessons. As part of this year's roadmap, one of the major questions we identified was that we need to decide whether we are going to do more editions and -- if so -- how we are going to manage the process.++[RFC 2052]: https://github.com/rust-lang/rfcs/blob/master/text/2052-epochs.md++This RFC proposes a specific answer to those questions:++* We will do new Rust editions on a regular, three-year cadence.+    * We will roll out an edition regardless of whether there are breaking changes.+* Unlike Rust 2018, we will avoid using editions as a "deadline" to tie together high-priority projects.+    * Instead, we embrace the train model, but editions are effectively a "somewhat bigger release", giving us an opportunity to give an overview of all the work that has landed over the previous three years.+* We specify a cadence for Edition lints.+    * "Edition idiom" lints for Edition N will warn for editions before N, and become "deny by default" in Edition N.+    * Since it would be disruptive to introduce deny-by-default lints for Rust 2018 now, the Rust 2018 lints are repurposed into Rust 2021 Edition lints.+* We specify a policy on reserving keywords and other prospective changes.+    * In short, reserving keywords is allowed only as part of an active project group.

Updating the RFC to include this stuff is probably a good idea, but some of this was set in the original editions RFC, and the intention isn't really to change that.

  1. this isn't edition specific; we already reserve the right to fix soundness holes without an edition.
  2. given that we already have the edition key, and adding a new one would add even more back-compat stuff to deal with, i personally believe sticking with edition is correct. "rust" was considered and rejected during the 2018 edition process.
  3. there is no current plan to, and the design makes it such that supporting them shouldn't be a burden.
  4. this would be a breaking change, and so is not likely. you could argue that a rustc2.0 would be fine, but given that we don't have a full language spec and multiple production ready compilers, this seems unwise.
  5. this already Just Works, as far as I know.
nikomatsakis

comment created time in 15 days

push eventnikomatsakis/rfcs

Steve Klabnik

commit sha e3aa8ee9c4e9926ac24f34a441f86a5805c7b64c

Small tweaks to the 2021 edition RFC

view details

push time in 16 days

issue closedrust-lang/rust

Stage2 install issue

Install docs stage2 (i686-unknown-linux-gnu) touch: cannot touch '/usr/lib/rust-install-probe': Permission denied install: error: can't write to destination. consider sudo.

command did not execute successfully: "sh" "/var/uhubuild/work/compile/build/tmp/dist/rust-docs-1.18.0-i686-unknown-linux-gnu/install.sh" "--prefix=/usr" "--docdir=/usr/share/doc/rust" "--libdir=/usr/lib" "--mandir=/usr/share/man" "--disable-ldconfig" expected success, got: exit code: 1

Why NEED to run install 3 times, and why not works under chroot?

closed time in 16 days

rezso

issue commentrust-lang/rust

Stage2 install issue

Triage: this is a very old issue, and the last comment says "solved", so, closing!

rezso

comment created time in 16 days

issue closedrust-lang/rust

Random failures while linking

When I compile my project, I randomly get linking errors like the following:

error: linking with `cc` failed: exit code: 1                                                                                                                                                                                                                   |
= note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/home/myself/azul_demo/target/debug/deps/azul_demo-00e6ee29d5a85693.11lsptxnlzei0dbv.rcgu.o
(... here goes a very long list of files with names similar to azul_demo-00e6ee29d5a85693.11lsptxnlzei0dbv.rcgu.o ...)
  = note: /bin/ld: reopening /home/myself/azul_demo/target/debug/deps/azul_demo-00e6ee29d5a85693.3r68os0lo0vp8x47.rcgu.o: Operation not permitted
          
          /bin/ld: final link failed: Operation not permitted
          collect2: error: ld returned 1 exit status

I noticed this error both when compiling azul and when using servo's webrender. What is curious is that this error is random: often times, I just run cargo build a few times and it works properly. I never noticed this error in my other rust projects, which did not make use of webrender, but they were fairly small code bases. Therefore, I don't know if this issue happens because of webrender of because the project is large, increasing the chances to highlight some bugs.

Also, notice that this error happened both when building the dependencies and when building the code. If I change a line of my code and rebuild, it is very likely that this will happen.

I am running rustc 1.32.0 on Linux (Fedora 29).

closed time in 16 days

akiross

issue commentrust-lang/rust

Random failures while linking

Okay! I'm going to give this a close then, if anyone else sees something similar, and can reproduce today, please open a new issue. Thanks!

akiross

comment created time in 16 days

Pull request review commentrust-lang/book

Update paragraph about rustfmt in Chapter 1.2

 requires these around all function bodies. It’s good style to place the openin curly bracket on the same line as the function declaration, adding one space in between. -At the time of this writing, an automatic formatter tool called `rustfmt` is-under development. If you want to stick to a standard style across Rust-projects, `rustfmt` will format your code in a particular style. The Rust team-plans to eventually include this tool with the standard Rust distribution, like-`rustc`. So depending on when you read this book, it might already be installed-on your computer! Check the online documentation for more details.+If you want to stick to a standard style across Rust projects, you can use an +automatic formatter tool called `rustfmt` to format your code in a particular+style. The Rust team has included this tool with the standard Rust distribution,+like `rustc`, so it should already be installed on your computer! Check the online+documentation for more details.

I did not know that! I am curious when this happened, though it appears it's been the case for a fairly long time.

rashiq

comment created time in 16 days

push eventrust-lang/book

Ross MacArthur

commit sha a2e4bbfdfbdb195bf134e5a53174d7d4ab027b1f

Update TOML link to official website

view details

Steve Klabnik

commit sha 86b1aa2aed9f256ccb76e32c01f08249a26227f1

Merge pull request #2411 from rossmacarthur/ft/update-toml-link Update TOML link to official website

view details

push time in 16 days

issue commentrust-lang/rust

SystemTime conversions invite programmer error

Triage: not aware of any changes here

ssokolow

comment created time in 17 days

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

Add post on opening up the Core Team agenda

+---+layout: post+title: "Opening up the Core Team agenda"+author: Pietro Albini+team: the Core Team <https://www.rust-lang.org/governance/teams/core>

Ah, I did not see that on Inside Rust! Seems fine :)

pietroalbini

comment created time in 18 days

push eventrust-lang/rust-by-example

dajamante

commit sha 9e09f7aeca9efce3e22a9b61571b4bde09f74651

changed language to gender neutral

view details

Steve Klabnik

commit sha 2e9271981adc32613365810f3428334c07095215

Merge pull request #1363 from Dajamante/master Replaced "princess" with "royal"

view details

push time in 18 days

PR merged rust-lang/rust-by-example

Replaced "princess" with "royal"

Hi, I believe the example from chapter 18.2 would benefit of being more neutral, so I replaced the panicky princess with a panicky royal. Kind regards, Aissata

+14 -14

1 comment

1 changed file

Dajamante

pr closed time in 18 days

pull request commentrust-lang/book

mdbook version used is now 0.4.x

Thanks!

tcanabrava

comment created time in 18 days

PR merged rust-lang/book

mdbook version used is now 0.4.x

We should update the documentation in README.md with the correct version of mdbook needed to compile the book.

+1 -1

0 comment

1 changed file

tcanabrava

pr closed time in 18 days

issue commentrust-lang/rust

LLVM ERROR: unknown codeview register

Triage: are you still seeing this today?

ian-p-cooke

comment created time in 19 days

issue commentrust-lang/rust

Random failures while linking

Triage: is anyone still seeing this?

akiross

comment created time in 19 days

issue commentrust-lang/rust

Spurious error while building Rust locally

Triage: a lot has changed since 2018; are you still seeing this?

retep998

comment created time in 19 days

issue closedsemver/semver

CC

closed time in 20 days

Miu98

issue commentsemver/semver

CC

Yes, it appears so.

Miu98

comment created time in 20 days

issue commentrust-lang/docs.rs

Search for type names in dependencies

That tweet is here: https://twitter.com/steveklabnik/status/727530114607661057

rustdoc already supports a VERY LIMITED form of this http://doc.rust-lang.org/std/?search=vec%20-%3E%20usize

Dylan-DPC

comment created time in 20 days

issue closedsteveklabnik/semver

0.10.0 published to crates.io but not pushed here to github

Hello, I believe you published https://crates.io/crates/semver/0.10.0 but this repository's master is still at 0.9.0 (still at 2a9e42b3864a0628a08374c7fa410711e1bec2fe ). Could you git push the 0.10.0 commits and tag?

closed time in 20 days

Arnavion

issue commentsteveklabnik/semver

0.10.0 published to crates.io but not pushed here to github

okay pushed as https://github.com/steveklabnik/semver/commit/db822b7fc20fd3bbdac742ac8eec82162df98257 and https://github.com/steveklabnik/semver/releases/tag/v0.10.0

thanks / sorry!

Arnavion

comment created time in 20 days

push eventsteveklabnik/semver

Steve Klabnik

commit sha db822b7fc20fd3bbdac742ac8eec82162df98257

bump to 0.10.0

view details

push time in 20 days

created tagsteveklabnik/semver

tagv0.10.0

Semantic version parsing and comparison.

created time in 20 days

issue commentrust-lang/rust-by-example

Arc chapter

Ah yes, if there's already stuff about RC, honestly, adding arc to it would probably make the most sense.

japaric

comment created time in 21 days

pull request commentsemver/semver

Add guidance on non-code file changes

While I agree with this principle in general, it also feels out of scope for semver itself, which is about defining a particular API, and then communicating changes to it.

JohnTrammellTarget

comment created time in 22 days

issue commentsemver/semver.org

DNS renewed for eight years

Thanks!

haacked

comment created time in 22 days

Pull request review commentsteveklabnik/semver

semver-parser 0.10.0

 fn test_regressions() {         ("0.1.0.", VersionReq::parse("0.1.0").unwrap()),         ("0.3.1.3", VersionReq::parse("0.3.13").unwrap()),         ("0.2*", VersionReq::parse("0.2.*").unwrap()),-        ("*.0", VersionReq::any()),+        // TODO: this actually parses as '*' now, not sure if that's OK+        // ("*.0", VersionReq::any()),

Ah yes, the deprecation. Thanks :) It is probably fine to un-deprecate it, but I'd like to triple check against https://github.com/semver/semver/pull/584 real quick to see if it's acceptable in that grammar....

hone

comment created time in 22 days

issue commentsteveklabnik/semver

0.10.0 published to crates.io but not pushed here to github

Hm. Thanks for the investigation! I had a lot going on in this time period, so that's probably the deal... I was going to look at the computer I was using then to double check everything, but at least it was actually me and I'm just forgetful.

Arnavion

comment created time in 22 days

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

Add post on opening up the Core Team agenda

+---+layout: post+title: "Opening up the Core Team agenda"+author: Pietro Albini+team: the Core Team <https://www.rust-lang.org/governance/teams/core>

Historically we have used

The Rust Core Team

I like the addition of the link, but maybe for consistency's sake we should make the text the same.

pietroalbini

comment created time in 22 days

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

Add post on opening up the Core Team agenda

+---+layout: post+title: "Opening up the Core Team agenda"+author: Pietro Albini+team: the Core Team <https://www.rust-lang.org/governance/teams/core>+---++The Core Team tends to project-wide policy questions on all sorts of matters,

Something in this wording is a bit off to me, but I'm not sure what. I think "tends" is the wrong verb, or maybe it's missing something, I'm not sure 😅

pietroalbini

comment created time in 22 days

issue commentsteveklabnik/semver

0.10.0 published to crates.io but not pushed here to github

Hmm, I am actually a bit confused; I don't remember publishing 0.10.0. I am gonna have to inspect what it looks like and figure it out... Thank you for drawing this to my attention! Seems... bad.

Arnavion

comment created time in 22 days

issue commentrust-lang/rust-by-example

Arc chapter

Hey @justohdezromera !

So, yes and no. That is, I can help mechanically, but I am not sure if a chapter on arc fits into the current structure or not, nor where. Maybe @marioidival has opinions.

japaric

comment created time in 22 days

Pull request review commentsteveklabnik/semver

semver-parser 0.10.0

 fn test_regressions() {         ("0.1.0.", VersionReq::parse("0.1.0").unwrap()),         ("0.3.1.3", VersionReq::parse("0.3.13").unwrap()),         ("0.2*", VersionReq::parse("0.2.*").unwrap()),-        ("*.0", VersionReq::any()),+        // TODO: this actually parses as '*' now, not sure if that's OK+        // ("*.0", VersionReq::any()),

So, I am actually not sure what the difference here is between "parses as *" and Any, that is, they should be the same?

hone

comment created time in 22 days

more