Subteam reports 2016-03-11

announcements
1

Friend of the tree

We’d like to nominate @eddyb for Friend of the Tree. Eddy has been on a role lately: first, he authored PR #31710, which fixed a longstanding bug in how the compiler was handling functions. In typical eddyb style, the PR not only achieves its goals, but also cleans up a lot of crufty code along the way. As if that was not enough, he also implemented PR #32080, which pushes the new MIR-based backend to the point where it can bootstrap and mostly pass the test suite. As before, it also manages to leave the code a lot cleaner: for example, we can now translate fns with non-Rust ABIs without the use of a shim. No doubt about it, eddyb is truly a Friend of the Tree!

Note: eddyb was also named a FOTT once before, on 2014-01-14.

Compiler

Full report

The biggest news is that eddyb has been pushing hard on improving the backend of the compiler lately. PRs #31710 and #32080 have simultaneously cleaned up a lot of the compiler code, closed some long-standing bugs, and pushed MIR almost to the point of viability. For this reason, I am nominating @eddyb for Friend of the Tree this week!

–nmatsakis

Lang

Full report

It was a busy week this week for FCP. We decided to promote four RFCs to FCP:

  • RFC #1201: Add support for naked functions. This RFC allows functions to be declared as “naked”, meaning that the compiler will generate no prologue or epilog. This is a low-level feature that can be useful when writing kernels or other such software.
  • RFC #1422: pub(restricted) item. An extension to our privacy system that allows a wider range of public/private declarations. Instead of merely declaring items as “public to everyone” or "private to the current module", one can now declare items as "public to the current crate" (but not other crates) or “public to some module M” (where M is some enclosing module). This helps in particular to alleviate “private type in public API” errors.
  • RFC #1346: unsafe expressions. The proposal is to permit unsafe expr (without braces) rather than just unsafe { block }.
  • RFC #1321: unstable visibility. The proposal is to change how unstable methods interact with method dispatch.

In addition, the following unstable language feature is being placed in FCP. As a reminder, FCPs for unstable language features last an entire release cycle, at the end of which we will typically decide to either remove the language feature, or else stabilize it (though we may elect to defer a final decision):

  • #29638: The #[macro_reexport] attribute, which allows you to take macros from an extern crate and re-export them. This is roughly the equivalent of a pub use from the other crate, but for macros.

Thanks!

– nmatsakis

Libs

Full report

This week was focused on selecting APIs for stabilization/deprecation in the Rust 1.9 release cycle. These are the APIs entering their six week final comment period:

Tools

Full report

The major highlight of this week was Multirust 0.8 was released with cross-std installation support! The multirust-rs project is also rapidly approaching parity and will likely soon outpace multirust.sh in terms of features, more info on this over the next few weeks!

Some other notable PRs against Rust and Cargo were:

2

I don't think this is much useful... In this case I prefer the syntax uniformity of {}.

1 Like
3

So do we!

4

That’s a link to #1321 instead of #1346.

5

Fixed, thanks.

6

Congratulations @eddyb, you Friend of the Tree! :smile:

7

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.