---
title: Triage meeting 2022-02-22
tags: triage-meeting
---

# T-lang meeting agenda

* Meeting date: 2022-02-22

## Attendance

* Team members: Josh, Scott, Felix
* Others: Mark, Lokathor, Connor, Michael, yaahc, lcnr

## Meeting roles

* Action item scribe: Felix
* Note-taker: simulacrum

## Scheduled meetings

* Feb 23rd -- "Never type next steps" lang-team#141
* doc available - https://hackmd.io/9sTGmQ_VQ_mX_bdQhuqVRA

## Announcements or custom items

(Meeting attendees, feel free to add items here!)

* roadmap/ambitions planning/scheduling?
* Compiler team blog post is out
* Is there any concrete timeline on a lang post?
* Josh: No timeline yet, but roughly next month would be good
* Fairly complete draft from Josh + Niko, with 2-3 weeks before posting
* Draft by March 9th
* Published by ~March 30th

### Add supported Directives list reference#1168

**Link**: https://github.com/rust-lang/reference/pull/1168

* inline asm is stabilizing in 1.59, this thursday
* Original RFC indicated that supported directives are intersection of LLVM ASM and GNU AS, but due to expected lack of validation in rustc did not list anything more specific
* Point was raised that documenting intentional support for particular subset of directives would be good, both for future validation and other backends
* Main motivator is a full macro system built-in to asm
* We can extend the list in the future
* Please check boxes!
* Felix: If we do add linting, best to do so soon (next release or so)
* Josh: Originally didn't want to add lints to do it, hard to do accurately. But best-effort is likely easier, and documentation helps with obvious cases of using the 'unsupported' parts
* List helps with implementation, too.
* Can get reports from people who hit the lint, and decide whether to add more directives or confirm that we don't want to add one
* Proposing to merge this this afternoon if there's no objection
* Josh: To merge and coordinate submodule bump
* Will be in nightly docs

## Action item review

* [Action items list](https://hackmd.io/gstfhtXYTHa3Jv-P_2RK7A)

## Pending lang team project proposals
### "Deprecate target_vendor " lang-team#102

**Link:** https://github.com/rust-lang/lang-team/issues/102

### "Async fundamentals initiative" lang-team#116

**Link:** https://github.com/rust-lang/lang-team/issues/116

### "Attribute for trusted external static declarations" lang-team#118

**Link:** https://github.com/rust-lang/lang-team/issues/118

### "Support platforms with size_t != uintptr_t" lang-team#125

**Link:** https://github.com/rust-lang/lang-team/issues/125

### "Positional Associated Types" lang-team#126

**Link:** https://github.com/rust-lang/lang-team/issues/126

### "Heap allocations in constants" lang-team#129

**Link:** https://github.com/rust-lang/lang-team/issues/129

### "Interoperability With C++ Destruction Order" lang-team#135

**Link:** https://github.com/rust-lang/lang-team/issues/135

### "inner crates, aka multiple crates per file" lang-team#139

**Link:** https://github.com/rust-lang/lang-team/issues/139

### "allow construction of non-exhaustive structs when using functional update syntax" lang-team#143

**Link:** https://github.com/rust-lang/lang-team/issues/143

## PRs on the lang-team repo

None.

## RFCs waiting to be merged

None.

## Proposed FCPs

**Check your boxes!**
### "Tracking Issue for RFC #2972: Constrained Naked Functions " rust#90957

**Link:** https://github.com/rust-lang/rust/issues/90957

### "proc-macro: Stop wrapping `ident` matchers into groups" rust#92472

**Link:** https://github.com/rust-lang/rust/pull/92472

### "Stabilize `let else`" rust#93628

**Link:** https://github.com/rust-lang/rust/pull/93628

### "Stabilize ADX target feature" rust#93745

**Link:** https://github.com/rust-lang/rust/pull/93745

### "Stabilize const_fn_fn_ptr_basics, const_fn_trait_bound, and const_impl_trait" rust#93827

**Link:** https://github.com/rust-lang/rust/pull/93827

## Active FCPs
### "Positional Associated Types" lang-team#126

**Link:** https://github.com/rust-lang/lang-team/issues/126

### "Interoperability With C++ Destruction Order" lang-team#135

**Link:** https://github.com/rust-lang/lang-team/issues/135

## P-critical issues

None.

## Nominated RFCs, PRs and issues

### "Stabilize --pretty=expanded" rust#43364

**Link:** https://github.com/rust-lang/rust/issues/43364

* `--pretty=expanded` has been around for years
* Originally just intended to be human-readable, for debugging of macros
* Over time this has become used in programmatic contexts (e.g., cbindgen) to find Rust functions that are macro-generated
* Nominated to get general opinions
* Felix has a separate proposal for embedding spans/hygiene into idents
* Likely even the format for this proposal is not stabilizable
* Would avoid coupling
* Scott: Issue notes both human and program consumption; which is the primary use?
* Josh: Both are primary users -- and both motivate stabilizing. Another case of stabilizing "some output" vs. *specific* output.
* Josh: instrument-coverage is similar, we stabilized the options without stabilizing the exact output format
* Felix: But instrument coverage doesn't have the same expectations for reliable inclusion, can extend easily
* Felix: Will we be unable to close the gap with a specified format, because we cannot encode some parts of the output?
* Josh: Can we have a stable option to emit Rust code, which will always include unstable feature declarations at the top. Forces tools to effectively 'opt in' by parsing those feature gates.
* Felix: Feels like that sidesteps the question of hygiene -- output code does not represent AST semantics.
* Josh: I would want to include hygiene identifiers as some unstable feature (per your proposal, for example). Can evolve in the future with some inclusion of unstable features.
* Scott: Why is parsing Rust code the right way for someone to retrieve information about items? Seems like emit=item-json is better than parsing arbitrary Rust code
* Felix: Could people just use RLS (Josh: or r-a) for that?
* Scott: Could be, but maybe something new, too.
* Scott: Extensible by providing a subset of the names and pieces of information in some fields.
* Felix: One use case is very high level analysis (e.g., item names, function params, etc.) vs. semantic analysis (function bodies necessary)
* Josh: nightly feature gate at the top for humans doesn't hurt, lets machines 'opt in' a little
* Could decide later that machines should use something else (e.g. JSON), and never stabilize the nightly features in the output
* Scott: I want to avoid encouraging machine case on this output; the use cases are too different for us to incentivise this parsing.
* Josh: If we want to avoid encouraging machines, what does that look like? Is a comment enough?
* Mark: If we're orienting towards a machine use case, the hygiene stuff is more important, whereas for the human use case we may want something different
* Felix: Humans may be *annoyed* by the hygiene information; how often would they want/need it to make sense of their macro expansions?
* Josh to summarize today's discussion onto the thread

Previous action item:

- [ ] [2022-02-15]: Niko to summarize discussion onto https://github.com/rust-lang/rust/issues/43364

### "Automatically implement AsRepr and allow deriving FromRepr for fieldless enums" rust#81642

**Link:** https://github.com/rust-lang/rust/pull/81642

* Mark: Does this need to be nominated? There's a background task going on to propose a full design, but unclear that immediate in-meeting action relevant
* Josh: Is blocked on lang team, but no need to leave nominated
* jswrenn is working on a more complete proposal, but currently busy with other things
* Felix to drop nomination and assign jswrenn as owner

### "Stabilize const_fn_fn_ptr_basics, const_fn_trait_bound, and const_impl_trait" rust#93827

**Link:** https://github.com/rust-lang/rust/pull/93827

* Nomination is older than FCP, FCP is more recent.
* Can drop nomination in favor of the FCP discussion.
* Now in FCP

### "Stabilize guaranteed compile time evaluation of unnamed constant items" rust#93838

**Link:** https://github.com/rust-lang/rust/issues/93838

* Dropped nomination
* Needs a PR with exact language to FCP
* perhaps to the reference
* may need tests
* Nominated for T-compiler to verify we can safely make this guarantee

### "Tracking issue for RFC 2137: Support defining C-compatible variadic functions in Rust " rust#44930

**Link:** https://github.com/rust-lang/rust/issues/44930

* Discussed in a previous meeting and some comments added;
* just needs nominated label dropped.

### "`no_mangle`/`used` static is only present in output when in reachable module" rust#47384

**Link:** https://github.com/rust-lang/rust/issues/47384

> 2022-02-08: Josh to write up summary for https://github.com/rust-lang/rust/issues/47384

* Want to avoid making guarantees that this makes it all the way to the linker, but do want a regression fix.
* PR maybe already posted to fix the regression?