# T-compiler RFC Day 2020-11-13

Zoom link: https://zoom.us/j/96764377915

## Announcements

## Pending T-compiler RFCs; Goals

(List from [T-compiler open RFC PRs](https://github.com/rust-lang/rfcs/pulls?q=is%3Apr+is%3Aopen+label%3AT-compiler):)

1. [RFC PR #2951](https://github.com/rust-lang/rfcs/pull/2951): "Linking modifiers for native libraries"
2. [RFC PR #2841](https://github.com/rust-lang/rfcs/pull/2841): "-C export executable symbols"
3. [RFC PR #2803](https://github.com/rust-lang/rfcs/pull/2803): "Target tier policy"
4. [RFC PR #2794](https://github.com/rust-lang/rfcs/pull/2794): "Environment variable sandboxing"
5. [RFC PR #2777](https://github.com/rust-lang/rfcs/pull/2777): "Scope prints in diagnostics"
6. [RFC PR #2400](https://github.com/rust-lang/rfcs/pull/2400): "Zero Page Optimization"
7. [RFC PR #2154](https://github.com/rust-lang/rfcs/pull/2154): "Debuginfo-based panic locations"

#### Establish goals of this meeting

Primary question: Today, do we guarantee traveral of all RFCs, potentially at shallow level? Or do we dive deep as necessary to each?

* Secondary question: Longer term, are T-compiler RFC's actually necessary? Or does the MCP process subsume RFC process, at least *for tasks solely under our team's purview?*

## RFC PR #2951: "Linking modifiers for native libraries"
(link: [RFC PR #2951](https://github.com/rust-lang/rfcs/pull/2951), [2951 rendered](https://github.com/petrochenkov/rfcs/blob/link-modifiers/text/0000-native-link-modifiers.md))

### Summary

> Provide an extensible mechanism for tweaking linking behavior of native libraries
> both in `#[link]` attributes (`#[link(modifiers = "+foo,-bar")]`)
> and on command line (`-l static:+foo,-bar=mylib`).

### Status

* This has an associated MCP: [compiler-team#356](https://github.com/rust-lang/compiler-team/issues/356)
* (basically petrochenkov did a smart hack and leveraged the MCP process in order to force progress on the RFC)
* That MCP was approved and its final comment period ended 14 days ago.
* *pnkfelix's proposal:* just merge [RFC PR #2951](https://github.com/rust-lang/rfcs/pull/2951) and move on.

##
## RFC PR #2841: "-C export executable symbols"
(link: [RFC PR #2841](https://github.com/rust-lang/rfcs/pull/2841), [2841 rendered](https://github.com/MaulingMonkey/rfcs/blob/pr/export-executable-symbols/text/0000-export-executable-symbols.md))

### Summary

> Add the ability to export symbols from executables, not just dylibs, via a new
> compiler flag: `-C export-executable-symbols`.

### Status

* Various edits to the document have been proposed.
* The T-compiler team has generally agreed in triage meeting 8 days ago that we should move forward with experimetnal implementation here.
* pnkfelix proposed an FCP merge for this 8 days ago; it is mostly waiting on T-lang team members, but the T-lang team already said they see this as mostly a T-compiler matter.
* *pnkfelix's proposal:* cancel FCP. remove T-lang label. re-start FCP. Re-add checkboxes from previous FCP.
* (This will leave 3 T-compiler member checkboxes unchecked, based on its current status.)

##
## RFC PR #2803: "Target tier policy"
(link: [RFC PR #2803](https://github.com/rust-lang/rfcs/pull/2803), [2803 rendered](https://github.com/joshtriplett/rfcs/blob/target-tier-policy/text/0000-target-tier-policy.md))

### Summary

> We should have an official policy for adding new tier targets, and for
> raising targets to tier 2 (with `rustup` builds) or even tier 1. This RFC
> codifies the requirements for targets at each tier.

### Status

* This RFC cross-cuts many teams (tagged with T-lang, T-infra, and T-release)
* The author has stated their intent, as of September 9th, to incorporate feedback, but Rust Foundation work has taken precedence.
* *pnkfelix proposal*: T-compiler members should read and provide any further feedback; but we do not need to take action on this at this time.

##
## RFC PR #2794: "Environment variable sandboxing"
(link: [RFC PR #2794](https://github.com/rust-lang/rfcs/pull/2794), [2794 rendered](https://github.com/jsgf/rfcs/blob/env-sandbox/text/0000-sandbox-environment.md))

### Summary

> This proposes a mechanism to precisely control what process environment is available to Rust programs at compilation time

(i.e. the the `env!`/`option_env!` macros.)

### Status

* [RFC PR #2794](https://github.com/rust-lang/rfcs/pull/2794) has been dormant for a little over a year
* The discussion thread gives explanations for why the command line flags (`--env-set VAR=VALUE`, ``--env-allow REGEX`, `--env-deny REGEX`) are necessary/desirable.
* Notably, matklad has pointed out rust_analyzer needs something along these lines.
* *pnkfelix proposal*: We should move forward with an experimental implementation here.

##
## RFC PR #2777: "Scope prints in diagnostics"
(link: [RFC PR #2777](https://github.com/rust-lang/rfcs/pull/2777) [2777 rendered](https://github.com/da-x/rfcs/blob/scope-prints-in-diagnostics/text/0000-scope-prints-in-diagnostics.md))

### Summary

> The diagnostics messages emitted by the Rust compiler make a very good effort
> for quoting relevent pieces of code when emitting about warnings and errors.
> Attached to these are annotated fragments of code, with filenames and line
numbers.
>
> However, the context in which the fragments reside is not mentioned, i.e.
> whether a function or another item. This proposal calls for adding that as
> well.

(In short, this proposes two changes: 1. add the text "in ITEM PATH" to the end of the lines that currently say ` --> test.rs:13:13` in diagnostic output, and 2. include the first line of the span for the item's definition in the output.)

### Status

* The "in ITEM PATH" addition seems like a small UX change with potentially big benefit to our users.
* (pnkfelix is less convinced about the utility of always including the first line of the item definition.)
* estebank left feedback about implementation concerns
* but pnkfelix thinks that might have just been a commentary on how the effect is achieved today, not necessarily a strike against the RFC itself as written?
* *pnkfelix proposal*: Get clarity about estebank's concerns, then RFC merge?
* Conclusion: encourage a move to MCP to focus on the impl details, the change to UI doesn't rise to level of RFC

##
## RFC PR #2400: "Zero Page Optimization"
(link: [RFC PR #2400](https://github.com/rust-lang/rfcs/pull/2400), [2400 rendered](https://github.com/ishitatsuyuki/rfcs/blob/null-page/text/0000-zero-page-optimization.md))

### Summary

> Extend the null pointer optimization to any value inside the zero page (which a
> reference cannot have the value).

### Status

* There is a lot of feedback, much of it concerned, on the discussion thread
* pnkfelix doesn't think this is in a state where we could FCP merge it today.
* To discuss: What can/should we do here?
* Conclusion: Niko to read over the thread and capture main points, potentially open issues on unsafe code guidelines repository, or else encourage thread participants to do so if they feel there are uncovered points. RFC will be closed.

##
## RFC PR #2154: "Debuginfo-based panic locations"
(link: [RFC PR #2154](https://github.com/rust-lang/rfcs/pull/2154), [2154 rendered](https://github.com/main--/rust-rfcs/blob/3b6495113ac1725e40eb02433329e18baf773a43/text/0000-debuginfo-based-panic.md))

### Summary

> Instead of generating location strings for panic information, read it at runtime from debug information. To make this work in release builds, introduce symbol files (external debug symbols) which are built in release mode by default.

### Status

* T-compiler discussed this back in September, and suggested that this RFC be reformed as an MCP
* From pnkfelix's skim, the comment thread is probably worth reading
* There is both enthusiastic support, and also concerns about blocking issues (but those concerns date from 2017; its possible the current rustc has resolved them)
* *pnkfelix proposal*: We should create a project group for this task. Let them make an MCP, prototype implementation, etc. If project group is formed, presumably we can close this RFC.
* Recommendations:
* Encourage MCP for design discussion around support for external debuginfo
* this is independently desired
* was previously blocked because libbacktrace but may be unblocked by move to gimli
* linux distros in particular would like this
* Close this RFC but suggest there could be independent RFCs focusing on the "policy questions":
* cargo release defaults
* panic UI, whether to include full backtrace