T-lang meeting agenda
Attendance
- Team members: nikomatsakis, Taylor, scott, Josh
- Others: simulacrum
Meeting roles
- Action item scribe: simulacrum
- Note-taker: nikomatsakis
Scheduled meetings
"Generators planning" lang-team#92- Tomorrow: "May updates" lang-team#93
- Niko posted requests for updates, many of which arrived
- Next week: "Rust language "guiding principles"" lang-team#91
Action item review
Pending proposals
"MCP: Allowing the compiler to eagerly drop values" lang-team#86
Link: https://github.com/rust-lang/lang-team/issues/86
Pending rfcbot FCPs
Nominated RFCs
No nominated RFCs this time.
Lexical reservation RFC (edition dependent)
- Consistency with current behavior of
r#:
- Original proposal was "put a space on either side" to avoid the reservation, but:
r# foo currently fails to compile.
- What does this mean for
foo# bar?
- This would then reserve additional syntactic space.
- Allowing this to hash means that you can write
foo# bar and don't have to write foo # bar or foo #bar.
- No known examples where anybody cares.
- Only example people have raised is
f#"..." which is a distinct thing from this question.
- Meeting consensus:
- Lexing error to have
foo# for consistency with r#
- Action item: scott to report meeting consensus to the thread.
- https://github.com/rust-lang/rust/issues/84979
proc_macro::TokenStream::from_str takes a string and has no way to specify the edition- currently uses the edition of the invocation site of the procedural macro
- cramertj/niko: decent choice, but the function is flawed
- would expect this to take a span as an argument – i.e., this trait impl should not exist
- one problem in practice:
- macro invocation sometimes "redirects" and hence you would get the edition
- another alternative: make this behavior work across all editions
- impact: existing procedural macros that rely on
f"foo" would be broken without migration
- crater run did terminate that
k#foo will not break any existing code
- decision:
- ask matklad + petrochenkov to elaborate a bit more on the downsides of edition-dependent lexing
- how much more difficult
- are there fundamental aspects of the design that are interrupted
- scottmcm: if we don't do edition-dependent lexing, can we ever introduce new tokens?
- conclusion: that seems hard =)
- what has been tested?
- started with everything and found
f"..", that's why we tested k#foo
- should check for other things like
ident#ident, we don't necessarily have to deal with f"..." at this time
P-high issues on rust-lang/rust
No new issues or major updates.
Nominated PRs and issues on rust-lang/reference
No nominated items this time.
Nominated PRs and issues on rust-lang/rust
"Tracking issue for RFC 2345, "Allow panicking in constants" (const_panic)" rust#51999
Link: https://github.com/rust-lang/rust/issues/51999
- Nomination removed but moved to #85194
- Question:
- Should we have a way to specify a constant whose value is not yet known?
- e.g.,
const FOO: T = todo!();
- Josh: this could be useul, maybe it wants its own feature?
- Given the concern around catching panics, do we want a "force compilation error"?
- Maybe, but we don't have a concrete example yet.
- Use sys::exit!!
- scottmcm has an existing action item
"Tracking issue for unsizing casts in const fns" rust#64992
Link: https://github.com/rust-lang/rust/issues/64992
"Implement new lint for detecting buggy pointer-to-int casts" rust#81789
Link: https://github.com/rust-lang/rust/pull/81789
- Mark summarized previous discussion
- Libs thread opened, no clear conclusions
- Libs response:
- We are amenable to proposed concrete functions that serve specific conversion purposes.
- It would be fine to have them proposed individually.
- Also nice if somebody had a more comprehensive of "valuable uses of as" with proposed functions for all of them.
- Niko's opinion:
- This sounds like a project group with the goal of "deprecating as" (or "limiting as" to safer semantics).
- But we can do it bit by bit.
- Meeting consensus:
- Close the PR
- Suggest adding APIs to stdlib for these sorts of casts (convey the general approval of libs team)
- Ideally, do this comprehensively, but this is a libs team approval question
- Once APIs exist, lints to deprecate parts of
as can be considered.
- Design note documenting the direction we would like to go.
- Josh to follow up.
"Stabilize "RangeFrom" patterns" rust#83918
Link: https://github.com/rust-lang/rust/pull/83918
- FCP complete but bstrie left a comment about range patterns in slice position:
- The pattern
[..] means "match any array"
- vs the pattern
[0..] means "match an array with something >= 0 in it"
- slice notation:
[3, 4, 5, \[x @\] .., 6, 7]
- bstrie proposes the following patterns should be an error:
match [0] {
[0..10] => (),
[..255] => (),
[0..] => (),
[..=10] => (),
}
- Josh: seems unlikely to be what you want. We could disallow them without parentheses.
- If what you mean is "match a single element array with values in this range" then use parens:
[(0..)]
- Niko: feels like a lint to me.
- Josh: note this only applies to single element cases. If you write this:
[0.., 5.., 10..]- it's pretty clear what you want
- Meeting consensus:
- FCP stands but we would request a warn-by-default lint for the single element case.
- Open an E-mentor issue.
- Action item (Mark):
- Comment that we believe this would be sufficiently addressed by a warn-by-default lint and request bstrie open an issue.
"rustc: Allow safe #[target_feature] on wasm" rust#84988
Link: https://github.com/rust-lang/rust/pull/84988
- Motivation:
- WASM target features are not understood by all WASM targets.
- However, they will not misinterpret them, they will simply fail to load the WASM code.
- Using WASM target features (when targeting WASM) is hence not unsafe, but it may block your code from loading.
- scott:
- People want this for non-WASM, isn't this a special case of target feature 1.1?
- josh:
- target feature 1.1 allows you to call AVX from a fn that already requires AVX
- but separately, there is "should you be able to call a fn that requires SSE from a platform that has SSE mandatory"
- niko: are we concerned about the fact that it is target specific, and we generally try to avoid target specific errors and things?
- mark: target feature is already relative to your target (no namespaceing, etc), so if you are using target-feature without cfg, you are probably doing something wrong
- scott: what happens if you use target feature SSE on x86-64?
- josh: assuming that exists, it should just be a no-op, because all x86_64 targets have SSE
- scott: ok, this is different from WASM because not all WASM engines will have these instructions
- another point: wasm prevents a lot of UB, but we still don't want to make everything safe (e.g., dangling pointers)
- niko: still feels like UB, even if the scope is somewhat narrower
"Uplift the invalid_atomic_ordering lint from clippy to rustc" rust#84039
Link: https://github.com/rust-lang/rust/pull/84039
"Deny float matches" rust#84045
Link: https://github.com/rust-lang/rust/pull/84045
- Update: const generics group had a discussion today, likely to be a design meeting proposal
"Add expr202x macro pattern" rust#84364
Link: https://github.com/rust-lang/rust/pull/84364
"Allow struct and enum to contain inner attrs" rust#84414
Link: https://github.com/rust-lang/rust/pull/84414
"stabilize member constraints" rust#84701
Link: https://github.com/rust-lang/rust/pull/84701
"implement Default for all arrays" rust#84838
Link: https://github.com/rust-lang/rust/pull/84838
"add back support for inner attributes on non-block expressions?" rust#84879
Link: https://github.com/rust-lang/rust/issues/84879
"Ignore derived Clone and Debug implementations during dead code analysis" rust#85200
Link: https://github.com/rust-lang/rust/pull/85200
"Check for union field accesses in THIR unsafeck" rust#85263
Link: https://github.com/rust-lang/rust/pull/85263
Initial summary comment: https://github.com/rust-lang/rust/pull/85263#issuecomment-842549594
-
Any changes
Be notified of any changes
-
Mention me
Be notified of mention me
-
Unsubscribe
Subscribe