Stream: t-lang

Topic: prioritization


nikomatsakis (May 06 2020 at 15:22, on Zulip):

So @Josh Triplett and I put our heads together to try and bang out a kind of "rough draft" lang-team roadmap sort of document:

https://hackmd.io/Czx3MwkpQeiC2_e9XI8OIw

The idea was to identify big priorities and things we would like to make progress on, along with a sense of what we're actually capable of.

We started out with "big themes" that we think are important and why.

Then, we broke out ideas into "short term" (goal: stable and deployed by late 2021), "mid term" (goal: could maybe make progress but shouldn't expect to be fully done by then), and "blocked" (reconsider as we make progress).

I've found this structure quite helpful. I suspect the short term list will need some tweaking, and it's probably a bit over-ambitious. I want to be breaking that list down by who will serve as the liaison -- I can tell that I have a lot of big projects there, for example, and I'd like to discuss how best to manage that (but some of them are "close-ish" to completion..still.) It seems ok to some extent, though, as we're describing a queue, but it's a good exercise.

nikomatsakis (May 06 2020 at 15:23, on Zulip):

I'm particularly interested to hear from @T-lang if there are things you think are important that are not represented there, and if there are projects you would like to spearhead that are not on this list. I don't think that each person has to spearhead something necessarily, as many of us wear multiple hats, and it may be that our main focus is in other areas. But I think being concrete about who will do what can also help us to see where we need to grow expertise within the team to increase bandwidth.

James Munns (May 06 2020 at 16:43, on Zulip):

@nikomatsakis would you see stability/safety of non-Rust-code things as the domain of T-lang?

James Munns (May 06 2020 at 16:44, on Zulip):

For example, the safety of items that concern the linker (e.g. -Clink-args), or stability of rust-lld as a part of the distribution?

James Munns (May 06 2020 at 16:44, on Zulip):

I know it's a little unfair to request stability for LLVM's linker, but we've been bitten before on breakages in lld, which is the default linker for some targets.

Josh Triplett (May 06 2020 at 16:48, on Zulip):

In my opinion, I think -Clink-args would be, yes.

Josh Triplett (May 06 2020 at 16:49, on Zulip):

I'm not sure if rust-lld would be the domain of T-lang or T-compiler or another group entirely.

James Munns (May 06 2020 at 16:49, on Zulip):

(in this regard, -Clink-args is an example of something that could induce wildly unsafe behavior, with no use of unsafe { }).

James Munns (May 06 2020 at 16:50, on Zulip):

It's not really a rust thing, though there have been some suggestions to "lift" those commands into compile time directives/attributes, where at least the compiler could take a look at it.

Josh Triplett (May 06 2020 at 16:50, on Zulip):

True, but I'm not sure how fixable that is, or if that's even considered incorrect.

Josh Triplett (May 06 2020 at 16:51, on Zulip):

I think it'd make sense to take the most common things people want to do with it, and turn them into dedicated command-line options or crate options.

Josh Triplett (May 06 2020 at 16:51, on Zulip):

But in the fully general case, I'd still want to pass arbitrary options to the linker.

Josh Triplett (May 06 2020 at 16:51, on Zulip):

And that includes arbitrary linker scripts.

James Munns (May 06 2020 at 16:51, on Zulip):

For example, basically every embedded systems crate needs link args to provide a linker script: https://github.com/jamesmunns/tiny-nrf52/blob/master/.cargo/config#L7-L9

James Munns (May 06 2020 at 16:53, on Zulip):

however, it would be good for a crate (either the main/application crate, or even a dependency, like cortex-m-rt) to provide one, something like

unsafe {
    #![linker_script("link.x")]
}

or something

James Munns (May 06 2020 at 16:53, on Zulip):

(I know that's a lot of imaginary syntax, but it's just illustrative)

Josh Triplett (May 06 2020 at 16:55, on Zulip):

Or for that matter, providing the text of a linker script rather than a filename, and generating the linker script with Rust. :)

James Munns (May 06 2020 at 16:55, on Zulip):

Josh Triplett said:

But in the fully general case, I'd still want to pass arbitrary options to the linker.

Yeah, I think this is pretty necessary. It's unlikely Rust will gain full feature parity with a complete linker

James Munns (May 06 2020 at 16:56, on Zulip):

I mean, to be fair, we already generate the linker script using a build.rs script and some templates :)

Josh Triplett (May 06 2020 at 16:56, on Zulip):

It's not that, so much as that anything with full parity with a linker will have effectively all the same options. :)

Josh Triplett (May 06 2020 at 16:56, on Zulip):

And be just as unsafe.

James Munns (May 06 2020 at 16:56, on Zulip):

The real linker script only ever lives in the out/ directory.

Josh Triplett (May 06 2020 at 16:56, on Zulip):

I'd love to have more control over linking. And I do think we could take some of the common cases and make them easier.

James Munns (May 06 2020 at 16:56, on Zulip):

I guess my suggestion is that at least then rustc can "see" the unsafety.

James Munns (May 06 2020 at 16:57, on Zulip):

I mean, if I use something like --wrap, I can induce some really awesome unsafe behavior, really quickly.

Josh Triplett (May 06 2020 at 16:57, on Zulip):

I'm not sure we've ever made an #![attribute] be unsafe.

James Munns (May 06 2020 at 16:57, on Zulip):

Yeah, #[no_mangle] was flagged as a particularly unsafe one.

James Munns (May 06 2020 at 16:58, on Zulip):

#[link_section], etc. etc.

Josh Triplett (May 06 2020 at 16:58, on Zulip):

Why would #[no_mangle] be unsafe, exactly? Just because you can potentially conflict with an existing symbol name that something expects?

James Munns (May 06 2020 at 16:58, on Zulip):

allows you to alias data

Josh Triplett (May 06 2020 at 16:58, on Zulip):

...ah. That's fun.

Josh Triplett (May 06 2020 at 16:59, on Zulip):

OK. So, generalizing, "better linker support, including full linker scripts and simple attributes for common options"?

Josh Triplett (May 06 2020 at 16:59, on Zulip):

That seems worth adding. Interested in working on it?

James Munns (May 06 2020 at 16:59, on Zulip):

I was mostly asking if that even makes sense as a T-Lang item

Josh Triplett (May 06 2020 at 17:00, on Zulip):

I think it absolutely does.

James Munns (May 06 2020 at 17:00, on Zulip):

Link time has been the sort of "not many eyes, because most people don't actively interact with the linker"

Josh Triplett (May 06 2020 at 17:00, on Zulip):

#![attributes] are definitely T-lang.

James Munns (May 06 2020 at 17:01, on Zulip):

At least, from the perspective of "totally end-to-end safe rust"

Josh Triplett (May 06 2020 at 17:01, on Zulip):

/me would love to see rust-lld become the default, as well.

Josh Triplett (May 06 2020 at 17:01, on Zulip):

Linker options that involve Cargo.toml and similar will be T-cargo instead, but I'd like to see those happen too, with my T-cargo hat on. :)

Josh Triplett (May 06 2020 at 17:02, on Zulip):

I added a bullet point under "C parity".

James Munns (May 06 2020 at 17:02, on Zulip):

Josh Triplett said:

That seems worth adding. Interested in working on it?

Not sure to what extent you mean :) I don't do a lot of work in rustc, personally

James Munns (May 06 2020 at 17:02, on Zulip):

Happy to help discuss or with an RFC, etc.

Josh Triplett (May 06 2020 at 17:04, on Zulip):

Yeah, I'm talking about making a proposal, helping to specify its behavior, up to the point of an RFC.

Josh Triplett (May 06 2020 at 17:04, on Zulip):

See https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Lang.20team.20proposals.2C.20project.20groups.2C.20and.20active.2Fbacklog

Josh Triplett (May 06 2020 at 17:05, on Zulip):

I'd love to see a "linker parity" project group, which could develop and submit RFCs for linker options a few at a time.

nikomatsakis (May 06 2020 at 17:06, on Zulip):

@James Munns I'd prefer not to get too fixed on which team's job is this and think more about "what should be done". Compiler flags definitely straddle a line between compiler/lang, but that's not the high order bit I guess.

nikomatsakis (May 06 2020 at 17:06, on Zulip):

I suspect that having a project group that involves folks from the relevant teams is ultimately the right thing

James Munns (May 06 2020 at 17:07, on Zulip):

Fair! I just wanted to make sure I was barking up the right tree :)

Josh Triplett (May 06 2020 at 17:07, on Zulip):

I think you're in the right place for this.

James Munns (May 06 2020 at 17:08, on Zulip):

(as this was described a "t-lang prioritization")

Josh Triplett (May 06 2020 at 17:08, on Zulip):

Also, if you're up for it, I'd also love to see more work on the properties of the default generated binaries, such as being able to strip them by default.

Josh Triplett (May 06 2020 at 17:09, on Zulip):

(Goal: the output of cargo build --release should be unchanged by running strip on it.)

James Munns (May 06 2020 at 17:11, on Zulip):

Oh, nice!

James Munns (May 06 2020 at 17:14, on Zulip):

Other things I don't see from the embedded wish list:

Something that's probably a longer discussion, but might be worth reserving keywords for:

Josh Triplett (May 06 2020 at 17:21, on Zulip):

@James Munns The first one meaning a replacement for the concept of volatile?

Josh Triplett (May 06 2020 at 17:21, on Zulip):

Could you explain the second item?

Josh Triplett (May 06 2020 at 17:21, on Zulip):

Also, can I suggest that we start a new thread for this?

Josh Triplett (May 06 2020 at 17:22, on Zulip):

(I'd love to have the explanation for multicore send/sync, but not in this thread.)

James Munns (May 06 2020 at 17:24, on Zulip):

First one would be around the fact that references can allow for spurious reads, so taking references can cause side effects in hardware.

Second one would be for pointers in non-contiguous address spaces, for example, AVR has a different address space for flash (.text, .data), and RAM, so you can't compare pointers; or Arm has SecureZone, where you have domains of trust with different, incompatible address spaces.

Multicore Sync/Send is best described in this RFC: https://github.com/rust-embedded/wg/blob/master/rfcs/0419-multi-core-soundness.md

btw, all of these are from the embedded meeting notes, here: https://github.com/rust-embedded/wg/blob/master/minutes/2020-04-28.md#embedded-lang-item-wish-list

James Munns (May 06 2020 at 17:24, on Zulip):

But yeah, I didn't know where the right place to discuss this was. @ me somewhere and I will move to chatting there :)

James Munns (May 06 2020 at 17:27, on Zulip):

"Multicore" topics also apply to IPC, so it's not just an embedded thing (different processes may have disparate address spaces)

Charles Lew (May 06 2020 at 17:27, on Zulip):

Thanks! really nice to see these listed, and i feel i can see some "core values" of rust design in the list. May i suggest re-raising structural typing ergonomics (e.g. dealing with tuples or unnamed structs (records)) in the longer range section?

Charles Lew (May 06 2020 at 17:33, on Zulip):

There's also method call forwarding (delegation) and Fn* traits implementations

Charles Lew (May 06 2020 at 17:36, on Zulip):

And I'm not sure SIMD is a language-level thing. Maybe?

nikomatsakis (May 06 2020 at 17:38, on Zulip):

Thanks @Charles Lew -- those are really good suggestions

Josh Triplett (May 06 2020 at 17:38, on Zulip):

James Munns said:

Second one would be for pointers in non-contiguous address spaces, for example, AVR has a different address space for flash (.text, .data), and RAM, so you can't compare pointers; or Arm has SecureZone, where you have domains of trust with different, incompatible address spaces.

Oh, I see. __attribute__((address_space(...))) in GCC?

nikomatsakis (May 06 2020 at 17:39, on Zulip):

Thinking about this more, I think in some kind of ideal world, actually, we would try to "slot" most every idea we here about, or at least the "major ones", somewhere in this list, even if it's a "never" category

Lokathor (May 06 2020 at 17:41, on Zulip):

(I was under the impression that the volatile / mmio thing was largely "solved", but maybe my needs are more modest than the needs of others. I've certainly never had any trouble lately)

nikomatsakis (May 06 2020 at 17:41, on Zulip):

Solved in what sense?

nikomatsakis (May 06 2020 at 17:42, on Zulip):

that is, solved by changes to libraries?

Lokathor (May 06 2020 at 17:42, on Zulip):

As in, a total non issue, we have good abstractions already in various crates and we don't need any more to build up the support for a particular device.

Lokathor (May 06 2020 at 17:44, on Zulip):

But if I'm wrong we can fork that conversation into another thread because it's probably a rabbit hole.

mark-i-m (May 06 2020 at 19:56, on Zulip):

First-class C compiler: rustc foo.rs bar.c

This made my mouth water (literally!)

Last update: Jun 05 2020 at 23:10UTC