profile
viewpoint

lalrpop/lalrpop 1183

LR(1) parser generator for Rust

graydon/bors 338

Integration robot for buildbot and github

brson/rust-sdl 167

SDL bindings for Rust

dslomov/typed-objects-es7 109

ES7 typed objects spec draft

nikomatsakis/borrowck 50

Modeling NLL and the Rust borrowck

nikomatsakis/bidir-type-infer 27

Implementing the type system described in the paper "Complete and Easy Bidirectional Type Inference" in Rust

jbclements/rust-redex 19

A Redex Model of Rust, or more specifically an encoding of Patina, the formal model for rust's type safety

nikomatsakis/ascii-canvas 13

simple canvas for drawing lines and styled text and emitting to the terminal

push eventrust-lang/rustc-guide

Deployment Bot (from Travis CI)

commit sha 58de73b546a72afc8363afdf390a60b2e80a07dc

Deploy rust-lang/rustc-guide to github.com/rust-lang/rustc-guide.git:gh-pages

view details

push time in 7 hours

pull request commentrust-lang/team

add myself to UCG

Yes, definitely, though we should discuss membership and organization here again at some point. But I feel like I'm always saying that.

RalfJung

comment created time in 17 hours

push eventrust-lang/team

Ralf Jung

commit sha 63ba4617a98dc4aa7b8f6a3711817eb084c3ddbd

add myself to UCG (#261) * add myself to UCG * add my email address

view details

push time in 17 hours

PR merged rust-lang/team

add myself to UCG

Also making myself co-lead. I think this matches @nikomatsakis' intent when he proposed I could be something like the UCG "shepherd/liaison/ambassador" to the lang team, or so.

+3 -2

0 comment

2 changed files

RalfJung

pr closed time in 17 hours

push eventrust-lang/rustc-guide

Deployment Bot (from Travis CI)

commit sha 632db336a0aa19eb2b1c0a3187896ec18d93f1ed

Deploy rust-lang/rustc-guide to github.com/rust-lang/rustc-guide.git:gh-pages

view details

push time in a day

push eventrust-lang/rustc-guide

Deployment Bot (from Travis CI)

commit sha 744ed933bab8b0ad85dfabb5487e40f767b7f845

Deploy rust-lang/rustc-guide to github.com/rust-lang/rustc-guide.git:gh-pages

view details

push time in 2 days

push eventrust-lang/rustc-guide

Deployment Bot (from Travis CI)

commit sha 4ced0e8af7fa3cd8d3bffdc11b6f199c6cd8607c

Deploy rust-lang/rustc-guide to github.com/rust-lang/rustc-guide.git:gh-pages

view details

push time in 3 days

push eventrust-lang/team

Niko Matsakis

commit sha d8a328df4865cc3db40817712a40ffc93eb77b4d

Record the Async Foundations WG (#253) * rename wg-async-await to wg-async-foundations * add in folks who've been contributing to the implementation lately * add github team * update link for web site

view details

push time in 4 days

PR merged rust-lang/team

Record the Async Foundations WG

So, the "wg-async-await" compiler group has kind of morphed and combined with the "Async Foundations WG" that was announced in this blog post.

To start, I included folks who have been hacking on the compiler -- but in building this, I found (for the first time) this list of folks who were working on futures 0.3 and the book. I've not heard from those folks though for all I know they are still active! We should figure out final scope and grow participant list as needed.

+31 -12

0 comment

5 changed files

nikomatsakis

pr closed time in 4 days

push eventnikomatsakis/team

Niko Matsakis

commit sha 05fa0132686a914b462478137cbf3bbc19e97ad1

update link for web site

view details

push time in 4 days

push eventrust-lang/team

Robbie Clarken

commit sha 0554076641c12a35c80eedaf689c34eea21776d1

Add RobbieClarken to Cleanup Crew ICE-breaker group (#257)

view details

push time in 4 days

PR merged rust-lang/team

Add RobbieClarken to Cleanup Crew ICE-breaker group

Adding myself to the cleanup crew. Thanks!

+5 -0

0 comment

2 changed files

RobbieClarken

pr closed time in 4 days

push eventrust-lang/team

Michał Siedlaczek

commit sha 91f315275be65a87f08dfd52dc8b5dadb409b885

Add user elshize (#256)

view details

push time in 4 days

PR merged rust-lang/team

Add user elshize
+4 -0

2 comments

2 changed files

elshize

pr closed time in 4 days

push eventnikomatsakis/skill-tree

Niko Matsakis

commit sha a0ac4dc6c0769e9677f83eda7f028166de040c07

encapsulate loading skill tree so I can give it some context

view details

push time in 4 days

push eventnikomatsakis/skill-tree

Niko Matsakis

commit sha d8ba8a02e1c99473588e8d2bcc85a55f1b90ff6f

adopt anyhow/fehler and supply some context for error reporting

view details

push time in 4 days

push eventrust-lang/rustc-guide

Deployment Bot (from Travis CI)

commit sha d203ca96ab608fc3d3193fd6a71d6fe76e57e489

Deploy rust-lang/rustc-guide to github.com/rust-lang/rustc-guide.git:gh-pages

view details

push time in 4 days

push eventrust-lang/rustc-guide

Deployment Bot (from Travis CI)

commit sha 8f8000a70cef3ec137d79532f9b57cde445c4a95

Deploy rust-lang/rustc-guide to github.com/rust-lang/rustc-guide.git:gh-pages

view details

push time in 4 days

push eventrust-lang/wg-traits

Niko Matsakis

commit sha a76074a680a0d8287b6f03a22418aee964663ad1

add the roadmap and buid it

view details

Niko Matsakis

commit sha bd521a83c46517425c7ddb468e3265b4cac5921a

create link to the intern methods take self issue, remove example

view details

Niko Matsakis

commit sha b9838479d345d7fb78a5c454b4cfbf73e349e07d

Merge pull request #4 from nikomatsakis/roadmap add the roadmap and build it

view details

push time in 4 days

push eventnikomatsakis/wg-traits

Niko Matsakis

commit sha bd521a83c46517425c7ddb468e3265b4cac5921a

create link to the intern methods take self issue, remove example

view details

push time in 4 days

push eventnikomatsakis/wg-traits

Niko Matsakis

commit sha a76074a680a0d8287b6f03a22418aee964663ad1

add the roadmap and buid it

view details

push time in 4 days

push eventnikomatsakis/wg-traits

Niko Matsakis

commit sha 3ebe3073f918bc8c7139530df8e98860868e0d48

use version 1.0

view details

push time in 4 days

push eventnikomatsakis/skill-tree

Niko Matsakis

commit sha b3ca77614ec59593cd90578ec4560b6d1f7e0146

declare 1.0

view details

push time in 4 days

push eventnikomatsakis/skill-tree

Niko Matsakis

commit sha b9f5936bd96d394aba558e3917fb10111d823cb5

fix cargo toml

view details

Niko Matsakis

commit sha 06fef894c844c1e5c755334fd894bc2a6b2ed659

rename package to skill-tree

view details

Niko Matsakis

commit sha ec8bbd17719b4b231b2422678ccf74f6dfc5d4aa

add cargo.lock

view details

Niko Matsakis

commit sha 1ac4718ab4a04adb0d55a87c0df3a4fb793e19ea

declare this as 1.0, what the heck

view details

push time in 4 days

PR opened rust-lang/wg-traits

add the roadmap and build it
+59 -0

0 comment

3 changed files

pr created time in 4 days

create barnchnikomatsakis/wg-traits

branch : roadmap

created branch time in 4 days

push eventrust-lang/chalk

Jane Lusby

commit sha b84f8620d903699ac64192bbd1b99a528962bf46

Rename TypeFamily to Interner

view details

Jane Lusby

commit sha 2df01cf16ea380fdc8067cdbb2fcef6a978a4e6a

Get those pesky _TTFs

view details

Jane Lusby

commit sha 4aad300b8d307e1a6072487cfb7cf371d597c5e4

got another one

view details

Niko Matsakis

commit sha f85bb2ed57b78728bf14fc1f0101ac5415752e4d

Merge pull request #329 from yaahc/type-interner Rename TypeFamily to Interner

view details

push time in 4 days

PR merged rust-lang/chalk

Reviewers
Rename TypeFamily to Interner
+1429 -1538

1 comment

56 changed files

yaahc

pr closed time in 4 days

pull request commentrust-lang/chalk

Rename TypeFamily to Interner

Heroic.

yaahc

comment created time in 4 days

push eventnikomatsakis/skill-tree

Niko Matsakis

commit sha d8274a6543a1111ae789dfb908f1d43d004ca833

emit the output directory

view details

push time in 4 days

push eventnikomatsakis/skill-tree

Niko Matsakis

commit sha 30ab9f2116cdb2b3dc473751d0bd4d181136ac5d

reindent

view details

Niko Matsakis

commit sha a56ea0a01b983cb7f1d61addfe49c1165009bf6f

try to add encrypted deploy key...

view details

push time in 4 days

push eventnikomatsakis/skill-tree

Niko Matsakis

commit sha 4d2b59cd97c01d04329374dce8c531af47709311

delete older content

view details

Niko Matsakis

commit sha c9f9ef3379792bdc68f1661a88429213e79ef099

add a travis configuration

view details

push time in 4 days

push eventnikomatsakis/skill-tree

Niko Matsakis

commit sha 6f7e89a57345880b94dbacf85d8e837fb7d54f40

make a no-worker that seems to kind of work

view details

Niko Matsakis

commit sha 9ca915721180962f8984a1fa42cb0ba2056a7a92

generate the output in a directory, huzzah

view details

push time in 4 days

push eventrust-lang/wg-traits

Niko Matsakis

commit sha d5806c7fb3c902039287c9bf27d5bbfef9976e21

first book commits

view details

Niko Matsakis

commit sha 69e0542add913eadacba9b74e8a80c87176c209d

link to minutes directory

view details

Niko Matsakis

commit sha 2c992aecfed391e416e402e97bb6a4d04dbfee30

add travis.yml to deploy the website; I stole this from the all-hands page

view details

Niko Matsakis

commit sha ab7b597eea50d165d0857d2fff40f563eed240eb

Merge pull request #3 from nikomatsakis/book create + publish a book

view details

push time in 4 days

PR merged rust-lang/wg-traits

create + publish a book
+37 -0

0 comment

6 changed files

nikomatsakis

pr closed time in 4 days

PR opened rust-lang/wg-traits

create + publish a book
+37 -0

0 comment

6 changed files

pr created time in 4 days

push eventnikomatsakis/wg-traits

Niko Matsakis

commit sha 2c992aecfed391e416e402e97bb6a4d04dbfee30

add travis.yml to deploy the website; I stole this from the all-hands page

view details

push time in 4 days

create barnchnikomatsakis/wg-traits

branch : book

created branch time in 4 days

fork nikomatsakis/wg-traits

Home of the "traits working group", affiliated with the compiler and lang teams.

fork in 4 days

issue commentrust-lang/chalk

Extend `TypeFamily` with some context

Proposed design to start is this. We will move from

trait TypeFamily {
    type InternedType;
    ...

    fn intern_ty(data: TyData<Self>) -> Self::InternedType;
    fn ty_data(ty: &Self::InternedType) -> &TyData<Self>;
}

to

trait TypeFamily {
    type InternedType;
    ...

    fn intern_ty(&self, data: TyData<Self>) -> Self::InternedType;
    fn ty_data(ty: &Self::InternedType) -> &TyData<Self>;
}

Note that I left ty_data alone -- I do expect to add &self there too, but not as part of this issue. We'll do that next. Also, I only talked about types, but eventually we'll want to add this to all the other sorts of interned things. But the first step will be the hardest.

nikomatsakis

comment created time in 4 days

issue openedrust-lang/chalk

Extend `TypeFamily` with some context

The various intern methods on TypeFamily do not currently permit any context. See e.g. intern_ty. We want that to take an &self parameter. This is going to be a somewhat extensive refactoring, however, because it's going to require threading a value around so that we can invoke the methods on it.

created time in 4 days

issue closedrust-lang/chalk

inference, lazy normalization, and occurs check

One interesting question is how the occurs check interacts with lazy normalization. Consider the inference unit test projection_eq. It attempts to solve an equation like exists(A -> A = Item0<<A as Item1>::foo>), which is currently rejected. In some sense, this is obviously an infinitely sized type, and indeed <A as Item1>::foo might normalize to A. But it could also normalize to u32, in which case normalization would make the type finite size.

Perhaps the best answer is to substitute a new variable (and a new normalization obligation). So that after processin that result, A would be bound to A = Item0<B> where <A as Item1::Foo> == B? If B wound up including A, then the occurs check would fail then.

(We just have to be wary of this recurring infinitely...)

closed time in 4 days

nikomatsakis

issue commentrust-lang/chalk

inference, lazy normalization, and occurs check

Yeah, I'm going to close this. We may indeed find some problems relating to this underlying pattern in practice, but we may not -- my concern would be that maybe there is something that we are able to type-check if we eagerly normalize (as rustc does) but which produces an "infinite type" if we are lazy. But the best way to find that would be to be converted rustc to a more lazy approach, I think.

nikomatsakis

comment created time in 4 days

pull request commentrust-lang/rust

Infer regions for opaque types in borrowck

r=me -- sorry for the excessive delay, @matthewjasper

matthewjasper

comment created time in 4 days

issue commentrust-lang/rust

StorageLive (and even StorageDead) may be unnecessary in MIR.

I guess from the perspective of the borrow checker, we treat StorageDead as if it were a kind of "deallocate" statement. We don't really care about the "CFG range", which is more LLVM's problem. In other words, I think the borrow checker is compatible with your view point, though as you point out there is some sort of implication (independent from borrow checking, but required if you want to allocate overlapping stack ranges and the like) that the uses of a borrow are post-dominated by the set of StorageDead blocks or whatever.

eddyb

comment created time in 4 days

issue commentzulip/zulip

New Feature: "My Topics"

I would like to add my voice here -- I would love this feature! It would I think address the largest "usability challenge" I find with Zulip, which is simply that there are often individual topics I wish to participate in without having to keep up with an entire stream.

I think in my ideal world:

  • whenever I participate or am @-mentioned, the topic would be "bumped" in "My topics"; only the top N topics would be shown
  • I would be able to add topics explicitly that I wish to follow, which would get bumped whenever anybody comments -- this might however be equally well served by #4271 (starred topics)

I think starred topics are complementary but I would probably keep them distinct, and it is definitely important to have a version where there is no explicit need to star things.

nwshane

comment created time in 4 days

issue openedrust-lang/compiler-team

document what team membership means, responsibilities, and how to adjust

We should be documenting

  • what it means to be a compiler team member
  • what it means to be a compiler team contributor
  • the responsibilities and guidelines for reviewing
  • the procedure for compiler team leads to add new members (see my notes below)

Most of this was in the compiler contributors RFC.

image

created time in 4 days

pull request commentrust-lang/rust

Use generator resume arguments in the async/await lowering

I'm excited to see this, thanks @jonas-schievink

jonas-schievink

comment created time in 4 days

issue commentrust-lang/rust

ICE on beta and nightly as result of use of `yield` in combination with macro call in `async` block

If I had to guess, I would guess #64830 (cc @estebank) triggered this regression, but #64859 or #64802 are possibilities. I would guess #64830 because it caused the compiler to keep compiling when it might've aborted, and maybe it would've aborted in these cases and hence never reached the code that causes an ICE.

If indeed I am correct, then this could be fixed by adding a delay_span_bug call at the point of the ICE (i.e., basically asserting that some error has occurred but otherwise just try to not crash).

olegnn

comment created time in 4 days

issue commentrust-lang/rust

ICE on beta and nightly as result of use of `yield` in combination with macro call in `async` block

@chrissimpkins thanks for the bisection!

Annoyingly, it regressed in a rollup PR, which means there are many candidates:

  • #64703 (Docs: slice elements are equidistant)
  • #64745 (Include message on tests that should panic but do not)
  • #64781 (Remove stray references to the old global tcx)
  • #64794 (Remove unused DepTrackingMap)
  • #64802 (Account for tail expressions when pointing at return type)
  • #64809 (hir: Disallow target_feature on constants)
  • #64815 (Fix div_duration() marked as stable by mistake)
  • #64818 (update rtpSpawn's parameters type(It's prototype has been updated in libc))
  • #64830 (Thou shallt not .abort_if_errors())
  • #64836 (Stabilize map_get_key_value feature)
  • #64845 (pin.rs: fix links to primitives in documentation)
  • #64847 (Upgrade env_logger to 0.7)
  • #64851 (Add mailmap entry for Dustin Bensing by request)
  • #64859 (check_match: improve diagnostics for let A = 2; with const A: i32 = 3)
olegnn

comment created time in 4 days

pull request commentrust-lang/rust

[WIP] polonius: adapt to the new fact format

@bors delegate=albins

r=me but travis is unhappy. @albins, I've delegated bors to you, so if you are able to fix these errors you should be able to tell bors r+ yourself!

albins

comment created time in 4 days

pull request commentrust-lang/rust

Correct inference of primitive operand type behind binary operation

Good question @varkor, what did I mean... I'm not sure, but the tests seem good.

@bors r+

varkor

comment created time in 4 days

issue commentrust-lang/rust

incremental: hash items' source tokens to generate DefId's.

I think the answer this is still an interesting idea, still not the most urgent problem.

eddyb

comment created time in 4 days

issue commentrust-lang/rust

Tracking issue for RFC #1909: Unsized Rvalues

Good question! I don't think we can permit unsized locals in that case. In some of the original versions of this feature, the intent was to limit unsized locals to cases where they could be codegen'd without alloca -- but I seem to remember we landed on a more expansive version. This seems like an important question to resolve before we go much farther. I'm going to add it to the list of unresolved questions.

aturon

comment created time in 4 days

pull request commentrust-lang/rust

Use a `ParamEnvAnd<Predicate>` for caching in `ObligationForest`

Apologies for the long delay. This is a good PR, and actually an important step as part of the "move rustc closer to chalk goal", so .. great! The perf impacts look small, though I'm not sure on what basis we can declare them to be noise? But I hope you're right!

@bors r+

Aaron1011

comment created time in 4 days

pull request commentrust-lang/rust

Parallel tweaks

I believe this is blocked on #68171, so updating status accordingly.

Zoxc

comment created time in 4 days

pull request commentrust-lang/rust

Canonicalize inputs to const eval where needed

I think the status is that we are waiting for @skinny121 to do the following:

skinny121

comment created time in 4 days

Pull request review commentrust-lang/rust

Move generic arg/param validation to `create_substs_for_generic_args` to resolve various const generics issues

 LL | struct Dl<'a, 'b, 'c, T, U, V, M: ThreeWithLifetime<T, 'a, A=(), B=(), U, '    |                                                            |     this associated type binding should be moved after the generic parameters    |                                                            this associated type binding should be moved after the generic parameters -error: lifetime arguments must be declared prior to type arguments-  --> $DIR/suggest-move-types.rs:34:46+error[E0747]: type provided when a lifetime was expected

I find this error quite a bit more confusing than the old one. It suggests to me that the fix is to change T into a lifetime -- but that won't help.

varkor

comment created time in 4 days

Pull request review commentrust-lang/rust

Move generic arg/param validation to `create_substs_for_generic_args` to resolve various const generics issues

 impl<'o, 'tcx> dyn AstConv<'tcx> + 'o {             self_ty.is_some(),             self_ty,             // Provide the generic args, and whether types should be inferred.-            |_| (Some(generic_args), infer_args),+            |did| {+                if did == def_id {+                    (Some(generic_args), infer_args)+                } else {+                    // The last component of this tuple is unimportant.+                    (None, false)

(Annoying, it'd be nice to change this to a custom enum -- but obviously pre-existing for this PR.)

varkor

comment created time in 4 days

Pull request review commentrust-lang/rust

Move generic arg/param validation to `create_substs_for_generic_args` to resolve various const generics issues

 LL | struct Dl<'a, 'b, 'c, T, U, V, M: ThreeWithLifetime<T, 'a, A=(), B=(), U, '    |                                                            |     this associated type binding should be moved after the generic parameters    |                                                            this associated type binding should be moved after the generic parameters -error: lifetime arguments must be declared prior to type arguments-  --> $DIR/suggest-move-types.rs:34:46+error[E0747]: type provided when a lifetime was expected

I'm not quite sure what the "mental model" is that we are trying to convey to users.

varkor

comment created time in 4 days

Pull request review commentrust-lang/rust

Move generic arg/param validation to `create_substs_for_generic_args` to resolve various const generics issues

 impl<'o, 'tcx> dyn AstConv<'tcx> + 'o {         let mut explicit_lifetimes = Ok(());         if !infer_lifetimes {             if let Some(span_late) = def.has_late_bound_regions {-                explicit_lifetimes = Err(GenericArgCountMismatch);                 let msg = "cannot specify lifetime arguments explicitly \                            if late bound lifetime parameters are present";                 let note = "the late bound lifetime parameter is introduced here";                 let span = args.args[0].span();                 if position == GenericArgPosition::Value                     && arg_counts.lifetimes != param_counts.lifetimes                 {+                    explicit_lifetimes = Err(GenericArgCountMismatch(Some(ErrorReported)));                     let mut err = tcx.sess.struct_span_err(span, msg);                     err.span_note(span_late, note);                     err.emit();

Oh, that'd be cute. :)

varkor

comment created time in 4 days

Pull request review commentrust-lang/rust

Move generic arg/param validation to `create_substs_for_generic_args` to resolve various const generics issues

 struct Bar<'a>(&'a ());  fn main() {     Foo::<'static, 'static, ()>(&0); //~ ERROR wrong number of lifetime arguments

why does this error go away?

varkor

comment created time in 4 days

Pull request review commentrust-lang/rust

Move generic arg/param validation to `create_substs_for_generic_args` to resolve various const generics issues

 impl<'o, 'tcx> dyn AstConv<'tcx> + 'o {         constness: Constness,         self_ty: Ty<'tcx>,         bounds: &mut Bounds<'tcx>,-    ) -> Option<Vec<Span>> {+    ) -> Vec<Span> {

as above

varkor

comment created time in 4 days

Pull request review commentrust-lang/rust

Move generic arg/param validation to `create_substs_for_generic_args` to resolve various const generics issues

 impl<'o, 'tcx> dyn AstConv<'tcx> + 'o {         trait_def_id: DefId,         self_ty: Ty<'tcx>,         trait_segment: &'a hir::PathSegment<'a>,-    ) -> (SubstsRef<'tcx>, Vec<ConvertedBinding<'a, 'tcx>>, Option<Vec<Span>>) {+    ) -> (SubstsRef<'tcx>, Vec<ConvertedBinding<'a, 'tcx>>, Vec<Span>) {

as above

varkor

comment created time in 4 days

Pull request review commentrust-lang/rust

Move generic arg/param validation to `create_substs_for_generic_args` to resolve various const generics issues

 impl<'o, 'tcx> dyn AstConv<'tcx> + 'o {         self_ty: Ty<'tcx>,         bounds: &mut Bounds<'tcx>,         speculative: bool,-    ) -> Option<Vec<Span>> {+    ) -> Vec<Span> {

Same in all these cases -- it'd be great to document what spans are being returned.

varkor

comment created time in 4 days

Pull request review commentrust-lang/rust

Move generic arg/param validation to `create_substs_for_generic_args` to resolve various const generics issues

 impl<'o, 'tcx> dyn AstConv<'tcx> + 'o {         position: GenericArgPosition,         has_self: bool,         infer_args: bool,-    ) -> (bool, Option<Vec<Span>>) {+    ) -> (bool, Vec<Span>) {

Pre-existing but can we document what the heck is being returned here? It's tough for me to tell

varkor

comment created time in 4 days

pull request commentrust-lang/blog.rust-lang.org

[Inside Rust] Intro to rustc's self-profile feature

We had some brief conversation in Discord on this topic. I think the conclusion was that this could indeed be a nice fit for the main blog, but if so, it could use a bit more of an intro. @wesleywiser how would you feel about adding some sort of intro to help explain to people what this feature is all about?

I was imagining something like this:

We often hear requests to know where compilation time is going. This is useful to use when optimizing the compiler, but also useful to users who want to refactor their crate so that it will compile faster. We've been working on an experimental feature that will help with us. This blog post gives a preview of how it works. Be warned, though: this is still experimental, and we expect the interface to change over time. We'll be adding these examples to the Rust unstable book, as well, and we plan to keep that up to date, so you can always find the latest instructions here.

wesleywiser

comment created time in 4 days

pull request commentrust-lang/blog.rust-lang.org

[Inside Rust] Intro to rustc's self-profile feature

I'm wondering if this ought to be promoted to the main Rust blog. It feels like the audience is more "people using Rust" than "people developing Rust". I asked this over on Discord, too.

wesleywiser

comment created time in 4 days

pull request commentrust-lang/blog.rust-lang.org

[Inside Rust] Intro to rustc's self-profile feature

This post is great!

wesleywiser

comment created time in 4 days

push eventrust-lang/blog.rust-lang.org

Niko Matsakis

commit sha ac8638254a5544e1554960206ed1853aeab81a06

announce compiler team design meetings 2020-02-14

view details

Niko Matsakis

commit sha 41f9f1b7d2e65e0aa38273226a383be7a82d870d

Merge pull request #517 from nikomatsakis/master announce compiler team design meetings 2020-02-14

view details

push time in 5 days

push eventnikomatsakis/blog.rust-lang.org

Niko Matsakis

commit sha 544037d148131e0d547b2b2287c8ebb920dcef47

Merge pull request #497 from nikomatsakis/master announce upcoming lang/compiler design meetings

view details

Zexbe

commit sha 3e1b56876ef31fe14c65a5bf3ac823e5008bb540

Make updated time unique I split published, and updated time, and made it so duplicate updated times get different seconds.

view details

Zexbe

commit sha 29b16a28cbe39188840abfeecb665d7905e5bcc8

Make sure the seconds add up to less then a day

view details

Zexbe

commit sha 0930b0ba84f773c75313d429582c876a6f232ba0

Fixes the blog url format

view details

Ivan Babrou

commit sha adbd7eb6b7f0ba33d12cee87f2b99fbd7f03d857

Sort posts as YYYY-MM-DD-TITLE, not YYYY-M-D-TITLE Previously all December, November and October posts were buried below February, because `2019/2/1` (Feb 1) is lexicographically above (in front of?) `2019/10/1` (Oct 1). This is not how mother nature intended it in ISO8601: * https://en.wikipedia.org/wiki/ISO_8601 Let's correct this mistake by sorting dates with zero prefixed month and day numbers to make all dates of fixed size. Among other things, this puts Rust 1.40 (released `2019-12-19`) as the version newer than Rust 1.38 (released `2019-09-26`), which is now linked as the latest version on rust-lang.org, despite link saying it's Rust 1.40. Closes #500

view details

Mark Rousskov

commit sha b65bdc5eccaced2ee4da52f84c3985e9b06c270d

Merge pull request #501 from bobrik/ivan/sort-dates-like-the-mother-nature-intended-in-iso8601 Sort posts as YYYY-MM-DD-TITLE, not YYYY-M-D-TITLE

view details

Mark Rousskov

commit sha e6c568997a3114c72f095a1d15a7650995198388

Merge pull request #499 from Zexbe/fix-blog-url Fix blog post urls

view details

Zexbe

commit sha 6caa522331156e63dc951b0c72052e04d8b4e87e

Fix blog folder name generating

view details

Mark Rousskov

commit sha 275d19584ca77f0fabe32f9e800c5e62da2be012

Merge pull request #503 from Zexbe/fix-blog-file-paths Fix blog folder name generating

view details

Santiago Pastorino

commit sha 7d355ffa0a7e24dab79d191190386569433a2a5a

announce Cleanup Crew ICE-breaker group

view details

Zexbe

commit sha 15790c770b7c29b6b3a9c4de8de2d3bd04bfcd6a

Fix h3 on blog posts The css was setting h3 to inline-block, this caused it to sometimes combine headers.

view details

Alex Crichton

commit sha b06f8d5e4a87860cbd34580ae7a471d2c22fd211

Merge pull request #506 from Zexbe/fix-inline-header Fix h3 on blog posts

view details

Pietro Albini

commit sha 39d5dd953591110e507e1e4a53ed2d1fc61e479b

add post about the release of rust 1.41.0

view details

Zexbe

commit sha 769d0adbde12333b656012d29dba02ce7bc6c322

2020 Rust Event Lineup [Draft] (#505) * Created 2020 Rust Event Lineup Draft * Fixing typos in Rust Event Lineup 2020 Co-Authored-By: apiraino <apiraino@users.noreply.github.com> * Added Rust+GNOME Hackfest * Fix name for timetill to timetill.rs Co-Authored-By: XAMPPRocky <4464295+XAMPPRocky@users.noreply.github.com> * Add Rust Oxidize Conference * Added Rusty Days conference * Add RustFest Netherlands * Update file date to 2020-01-29 * Update file date to 2020-01-30 Co-authored-by: apiraino <apiraino@users.noreply.github.com> Co-authored-by: XAMPPRocky <4464295+XAMPPRocky@users.noreply.github.com>

view details

Pietro Albini

commit sha c1fcf73965acb3704091f05534080f55b3b481ab

Update posts/2020-01-30-Rust-1.41.0.md Co-Authored-By: Jonas Schievink <jonasschievink@gmail.com>

view details

Pietro Albini

commit sha f6abece02d2644eb89ff29d92fcdd6eda938bf17

Revert "2020 Rust Event Lineup [Draft] (#505)" The post will be published tomorrow.

view details

Pietro Albini

commit sha 64347b2f8f8ebed89d9fc81956425f8b62f44922

Merge pull request #507 from pietroalbini/rust-1-41-0 Rust 1.41.0 announcement

view details

Zexbe

commit sha 8ccbc94b7a92f151dfd1d5560942fec1e6eb9df2

Re-add blog post to be deployed on 2020/01/31 (#510) * Revert "Revert "2020 Rust Event Lineup [Draft] (#505)"" This reverts commit f6abece02d2644eb89ff29d92fcdd6eda938bf17. * Change date for event lineup to tommorow.

view details

Santiago Pastorino

commit sha 53f83e0a650d7b3b74a7b624901bb39f5694aa1c

Update posts/inside-rust/2020-01-27-Cleanup-Crew-ICE-breakers.md Co-Authored-By: Niko Matsakis <niko@alum.mit.edu>

view details

Santiago Pastorino

commit sha 329ece6f8c89989b11543c41c9dc170e971ba607

Fix link

view details

push time in 5 days

issue commentrust-lang/compiler-team

design of the chalk-ty library

We discussed this in our planning meeting today and concluded that we should schedule this meeting for March 6th (calendar event).

nikomatsakis

comment created time in 5 days

issue commentrust-lang/compiler-team

Focused and efficient triage

We discussed this in our planning meeting today and concluded that we should schedule this meeting for February 28th (calendar event).

nikomatsakis

comment created time in 5 days

issue commentrust-lang/compiler-team

merge llvm.sideeffect change

We discussed this in our planning meeting today. The conclusion was that scheduling a meeting on this would not yet be productive, but that a good next step would be to draft a blog post summarizing:

  • What is the problem
  • What efforts have been done to resolve it
  • What is the impact of those efforts on compillation time

which we can then use to circulate amongst LLVM devs and try to get some ideas for better directions, and/or at least capture the status of our efforts. @Mark-Simulacrum has volunteered to try and draft that post. 🎉

nikomatsakis

comment created time in 5 days

push eventrust-lang/rustc-guide

Deployment Bot (from Travis CI)

commit sha 3bd2a01d0ecd4e71c3037819a7226e1ebeacc41f

Deploy rust-lang/rustc-guide to github.com/rust-lang/rustc-guide.git:gh-pages

view details

push time in 5 days

pull request commentrust-lang/rfcs

RFC for unsafe blocks in unsafe fn

Dear RFC thread,

In our @rust-lang/lang meeting on 2020-01-23, we discussed this RFC. I wanted to write up our thoughts -- my apologies that it's taken me a few weeks. ❤️

TL;DR

The high-level summary is this. There is definite sympathy for the aims of this RFC. Moreover, we identified some immediate steps we can take regardless of whether we accept this RFC or not (I'll outline those below).

Immediate option: stop linting against unsafe blocks in unsafe functions

Currently, we actively lint against writing unsafe blocks in the body of an unsafe function. One clear immediate step we can take would be to convert that lint into a "accept-by-default" lint, so that we stop warning people into writing code that may soon be deprecated (we would instead be expressing no opinion).

Distinguishing "unsafe to call"

There was some sympathy expressed in the meeting for finding some "new way" to denote functions that are "unsafe to call" but whose bodies are not considered trusted by default (i.e., where unsafe blocks are still needed in the body). The primary motivation was avoiding "breakage" -- not technical breakage, perhaps, but the sense of the language changing underfoot. We discussed the idea of a #[unsafe] attribute, for example, though it would require some changes because we do not presently permit keywords in attribute names.

To be clear, this was not a universal opinion. For one thing, if the primary motivation is to avoid people being surprised by a new way to do it, then adding a new (recommended) syntax may be counterproductive -- people are accustomed to writing unsafe fn, so if they start seeing something like #[unsafe] fn, that in itself could be confusing. Moreover, it introduces the "more than one way to do it" phenomen -- is there an important distinction being expressed between unsafe fn and #[unsafe] fn? If so, what is it, and how do you guide people to which one they should be using?

Downsides

We discussed some of the downsides of adopting this proposal. I'd love it if people could help to complete the list. These are the ones we covered.

  • Change to people's muscle memory (as discussed above)
  • Rightward drift: for simple functions, unsafe fn foo() { .. } now becomes unsafe fn foo() { unsafe { .. } }, and that could be a lot of overhead, especially for FFI
    • It's not clear how big a problem this is; one possibility might be using a (third party) procedural macro #[unsafe_fn] fn foo() { .. } to rewrite things into something closer to the old style for those specific cases where it's a concern.

Editions

If we did decide to adopt the spirit of this RFC, we obviously have some choice here in how we approach this. In order of "more change", I think the range of options are:

  • Just use lints to encourage people to write unsafe function bodies (but don't require it), no edition change
  • Use lints in 2018, make it a hard error in 2021 to omit unsafe in function bodies
  • In Rust 2021, transition to trusted { ... } for unsafe blocks and to trusted impl for implementing unsafe traits, but keep unsafe fn and unsafe trait.
    • This would capture the distinction where we use unsafe to indicate "defines additional proof obligations" and trusted to mean "proves those obligations"
RalfJung

comment created time in 5 days

push eventrust-lang/lang-team

Niko Matsakis

commit sha b7cbe5315b5fc366e3ea22b5514818b846921619

more markdown cleanup

view details

push time in 5 days

push eventrust-lang/lang-team

Niko Matsakis

commit sha f90c85eec3260eaae24aa7ac5d0f9f8b36a77970

cleanup markdown

view details

push time in 5 days

push eventnikomatsakis/team

Niko Matsakis

commit sha 1892d4661cbb70d7e89aeaa57bb7d0045ecb271f

add github team

view details

push time in 5 days

pull request commentrust-lang/team

Add user elshize

@elshize can you rebase this PR?

elshize

comment created time in 5 days

push eventrust-lang/team

Redblueflame

commit sha 43a6314d1cdddcbe95a8d09a4a1af3e44c85930a

Add Redblueflame to Cleanup Crew ICE-breakers (#255)

view details

push time in 5 days

issue openedrust-lang/compiler-team

Focused and efficient triage

Meeting proposal info

  • Title: Focused and efficient triage
  • Type: non-technical

Summary

Proposal

At the broadest level, discuss the following questions:

  • What are our goals with compiler team triage?
  • Are we achieving those goals efficiently?

Hypothesis

More specifically, we would like feedback on the following hypothesis:

  • Goal of compiler team triage should be to avoid shipping catastrophic bugs
    • i.e., things that are really embarassing or which will effect a lot of users
  • Goal of compiler team triage is NOT to ensure "overall quality" of the compiler
    • that goal is maintained in a distributed way through reviews
    • but also by the working groups dedicated to a particular feature
  • We should focus triage meeting time on "here is a critical bug that is not being fixed"

More details

See this hackmd.

About this issue

This issue corresponds to a meeting proposal for the compiler team steering meeting. It corresponds to a possible topic of discussion. You can read more about the steering meeting procedure here.

Comment policy

These issues are meant to be used as an "announcements channel" regarding the proposal, and not as a place to discuss the technical details. Feel free to subscribe to updates. We'll post comments when reviewing the proposal in meetings or making a scheduling decision. In the meantime, if you have questions or ideas, ping the proposers on Zulip (or elsewhere).

created time in 5 days

issue commentrust-lang/rust

Tracking issue for `#![feature(maybe_uninit_ref)]`

@SimonSapin did you want to resolve the docs concern? I think @dtolnay tried to but you registered them =)

Centril

comment created time in 5 days

push eventrust-lang/rustc-guide

Deployment Bot (from Travis CI)

commit sha 32be53cb6023afd5f4350b864f797abf6c2a9521

Deploy rust-lang/rustc-guide to github.com/rust-lang/rustc-guide.git:gh-pages

view details

push time in 5 days

pull request commentrust-lang/team

Add nmccarty to Cleanup Crew ICE-breakers

BTW @nmccarty there were some recent cleanup crew issues -- check out the list here

nmccarty

comment created time in 6 days

push eventrust-lang/team

Nathan McCarty

commit sha 016c12aa09d834eb32ca7b9913617b111de65bce

Add nmccarty to Cleanup Crew ICE-breakers (#254) * Add nmccarty to Cleanup Crew ICE-breakers * Fix schema error pointed out by the CI The toml schema document said irc-nickname, but the CI is demanding irc

view details

push time in 6 days

PR merged rust-lang/team

Add nmccarty to Cleanup Crew ICE-breakers
+6 -0

0 comment

2 changed files

nmccarty

pr closed time in 6 days

issue closedrust-lang/rust

30-60% perf regression in ctfe-stress

This happened on 2020-01-11: https://perf.rust-lang.org/compare.html?start=bfd04876b93ad5c013d90bc46937e28b6ee1a3f4&end=1389494ac145a84dba025ff65969f7ab150c3f02&stat=instructions:u

Caused by https://github.com/rust-lang/rust/pull/67000

cc @oli-obk @spastorino

(I could've sworn we already tracked this regression, but apparently not)

screenshot-2020-02-09-00:03:41

closed time in 6 days

jonas-schievink

issue commentrust-lang/rust

30-60% perf regression in ctfe-stress

Visited during compiler-team triage. Based on @oli-obk's comment, going to close as "won't fix". Thanks @jonas-schievink!

jonas-schievink

comment created time in 6 days

issue commentrust-lang/rust

'index out of bounds: the len is 1 but the index is 1': libcore/slice/mod.rs

Tagging as P-high for now because the ICE gives so little actionable information to guide the user as to how to correct the problem.

harrisonthorne

comment created time in 6 days

issue commentrust-lang/rust

'index out of bounds: the len is 1 but the index is 1': libcore/slice/mod.rs

Also would be good to know if this is a regression.

harrisonthorne

comment created time in 6 days

issue commentrust-lang/rust

'index out of bounds: the len is 1 but the index is 1': libcore/slice/mod.rs

@rustbot ping icebreakers-cleanup-crew

Dear cleanup crew, it would be great to try and narrow this down to a self-contained example. @threecgreen has a crate here that reproduces the problem, but it's not a small, workable example.

harrisonthorne

comment created time in 6 days

issue closedrust-lang/rust

Suspicious lifetime inference.

I'm not sure whether there's a duplicate issue. Currently this code doesn't compile:

pub fn main() {
    let mut s = "s".to_owned();
    let a = &mut s;
    *a += "";
    let b: _ = a;
    *a += "";
}

However it seems to me that a new lifetime variable should be introduced by the _? Is there any reason behind this current behavior?

@matthewjasper @nikomatsakis

closed time in 6 days

crlf0710

issue commentrust-lang/rust

Suspicious lifetime inference.

Visiting from compile triage. I believe this is "working as expected" (for better or worse). In particular, since we don't know the type of the variable b, we do indeed register this as a move of a. Closing.

crlf0710

comment created time in 6 days

issue commentrust-lang/rust

Rustc overflow its stack when using impl Trait and the struct containing the function itself

Tagging as P-high since this is a regression, though it might be considered P-medium otherwise (not an active soundness hole, for example).

lszxb

comment created time in 6 days

issue commentrust-lang/rust

Rustc overflow its stack when using impl Trait and the struct containing the function itself

@rustbot ping icebreakers-cleanup-crew

There is already a minimal example here, but it'd be great to figure out the PR (or at least nightly) that caused it regress.

lszxb

comment created time in 6 days

more