Edit the schedule here: https://github.com/orgs/rust-lang/projects/31/views/7.
None.
! to a type (RFC 1216)" rust#35121Link: https://github.com/rust-lang/rust/issues/35121
tmandry: For Rust 2024, I want to know the status of this.
CE: I'm working with Waffle on adding a lint about fallback. He knows how to do this now.
TC: That would indeed help remove one of the largest hurdles to stabilizing the never type.
tmandry: I'll mark this as accepted on the 2024 tracking board.
CE: We should be sure to track dependencies on all things we need for the 2024 edition.
Link: https://github.com/rust-lang/rfcs/pull/3373
tmandry: For 2024, I want to know the status of this.
TC: As far as I know, and I've been tracking this for its relationship to TAIT, there hasn't been movement on this since February.
Link: https://github.com/rust-lang/rust/pull/119037
In #115476 we had an extensive discussion that led to us documenting rules for ABI compatibility. RalfJ now wants us to retract a piece of that in a hurry. Specifically this bit:
- If
T1andT2are ABI-compatible, then tworepr(C)types that only differ because one field type was changed fromT1toT2are ABI-compatible.
TC: RalfJ:
…I added it because from how I understand calling conventions, this should actually be safe in practice. However I entirely forgot to actually allow this in Miri, and in the mean time I have learned that too much ABI compatibility can be a problem for CFI (it can reject fewer calls so that gives an attacker more room to play with).
So I propose we take back that part about ABI compatibility in
repr(C). It is anyway something that C and C++ do not allow, as far as I understand.In the future we might want to introduce a class of ABI compatibilities where we say "this is a bug and it may lead to aborting the process, but it won't lead to arbitrary misbehavior – worst case it'll just transmute the arguments from the caller type to the callee type". That would give CFI leeway to reject such calls without introducing the risk of arbitrary UB. (The UB can still happen if the transmute leads to bad results, of course, but it wouldn't be due to ABI weirdness.)
#115476 hasn't reached beta yet so if we land this before Dec 22nd we can just pretend this all never happened. ;) Otherwise we should do a beta backport (of the docs change at least).
TC: What do we think?
scottmcm: If there's a concern about a guarantee we might make, let's just retract it. We can always add it later.
CE/TC/tmandry: +1.
scottmcm: I'll just r+ this then.
Consensus: Let's retract this for now.
REDUNDANT_LIFETIMES lint to detect lifetimes which are semantically redundant" rust#118391Link: https://github.com/rust-lang/rust/pull/118391
TC: We discussed this on 2023-12-06. Our consensus was that we wanted this, but we thought maybe the new lint and some existing lints should be split to distinguish lifetimes that are unused from those that are unneeded.
TC: CE has now done that, so there are two lints, unused_lifetimes and redundant_lifetimes.
TC: With this change, do we agree this should go forward?
tmandry: Let's do it. Does it need an FCP?
CE: It's just a lint.
scottmcm: We should do this change.
tmandry: We have been FCPing lints lately. I'm not sure when we started doing that.
tmandry: I'll propose FCP merge.
Consensus: Let's do this, and do it via FCP.
Link: https://github.com/rust-lang/rust/issues/64586
TC: In the design meeting on 2023-12-13, we discussed many details but maybe skipped over our points of agreement. The limited quorum consensus at the end of the meeting was:
Consensus: We may have agreement about the goals here. We probably want & patterns everywhere, and we probably want to fix the problem of mut resetting the binding mode, i.e. to make it such that adding mut doesn't change the type of the binding. We'll want to verify that consensus with the fuller group. With agreement on that goal, Nadri can invest further time for writing code, performing crater runs, etc.
TC: Do we have a full consensus on this? If so, Nadri can invest more effort.
tmandry: I agree with all of that.
scottmcm: +1.
TC: And it looks like we did cover this on Zulip:
Consensus: Let's encourage Nadri to move forward on doing more work here.
Link: https://github.com/rust-lang/rfcs/pull/3535
TC: On the basis of our 2023-10-18 design meeting, RalfJ wrote up this RFC and nominated it for us.
TC: Probably everyone should have a look asynchronously. I've bumped a thread to remind us about that, and to give a place for us to leave any notes we might want to discuss in a triage meeting:
tmandry: This does look reasonable.
scottmcm: I remember being torn in lots of directions in the design meeting. So it's good to see this now consolidated.
Consensus: We should all go and read the RFC.
unstable_features and make use of it in the compiler" rust#118639Link: https://github.com/rust-lang/rust/pull/118639
TC: fmease wants us to remove the deprecation from the unstable_features lint to better support rust-analyzer working on stable Rust while depending on parts of the compiler. In detail:
There exist some rustc crates that ought to compile on stable for use in rust-analyzer. These crates (namely:
rustc_lexer,rustc_parse_format) should not use any#![feature]s. Currently this is only enforced by comments which lead to a mass-update PR to accidentally disregard this policy (it was missed by the author and the reviewer).I propose to undeprecate the lint
unstable_featuresto enforce this rule automatically. According to #117937 (comment), the lint was previously deprecated because it was replaced by a hard error (#![feature]may not be used on the stable release channel).Alternative: In CI, build those crates with
RUSTC_BOOTSTRAP=0instead. CON: Bootstrap needs to hard-code a list of “stable crates”. PRO: Nothing needs to be undeprecated.There also exists
rustc_type_irwhere we could use the lint in the form of#.
TC: It's worth noting that there's also been recent discussion on Zulip about whether rust-analyzer should consider moving to nightly Rust. It will, e.g., presumably want to use the new trait solver eventually.
TC: What do we think?
CE: The question for T-lang probably should be whether the lint is generally useful. Whether or not we use or need this for RA is probably a separate thing that's less relevant to T-lang.
tmandry: I don't have an objection to this in general.
scottmcm: This seems different than a normal deny lint because it's impossible to violate it or do anything about it on stable.
scottmcm: We'd want this to be a forbid lint?
CE: Yes, that would make sense.
CE: The better question is, why was this deprecated in the first place?
fmease: This may go far back to when there was a less rigid night/stable distinction.
scottmcm: As long as compiler thinks this is OK to implement…
CE: It's probably the easiest lint to implement.
tmandry: I'll start FCP.
Consensus: Let's do this.
Link: https://github.com/rust-lang/rust/pull/119044
TC: RalfJ nominated this for us since the change would allow new code on stable Rust:
This entirely replaces our const-eval interner, i.e. the code that takes the final result of a constant evaluation from the local memory of the const-eval machine to the global
tcxmemory. The main goal of this change is to ensure that we can detect mutable references that sneak into this final value – this is something we want to reject forstaticandconst, and while const-checking performs some static analysis to ensure this, I would be much more comfortable stabilizing const_mut_refs if we had a dynamic check that sanitizes the final value.…
This PR does have the immediate effect of allowing some new code on stable, for instance:
const CONST_RAW: *const Vec\<i32> = &Vec::new() as *const _;Previously that code got rejected since the type-based interner didn't know what to do with that pointer. It's a raw pointer, we cannot trust its type. The new interner does not care about types so it sees no issue with this code; there's an immutable pointer pointing to some read-only memory (storing a
Vec<i32>), all is good. Accepting this code pretty much commits us to non-type-based interning, but I think that's the better strategy anyway.
…Please let me know if you think FCP is necessary.
TC: What do we think?
scottmcm: This reminds me of RFC 3535, in terms of being related to value-based restrictions.
tmandry: What would be an example of a pointer that would not be allowed in const.
scottmcm: That'd be a great thing to write on the PR.
TC: Perhaps we should start by explaining to ourselves why this doesn't compile today.
CE: (Discussion of some reasons that might be.)
CE: It has something to do with the intersection of interior mutability and const pointers.
CE: I'm unclear about the full set of rules here.
TC: Let's ask Ralf about, why step by step this doesn't compile today, why it would compile after the change, and an example of what still would not compile and why.
tmandry: I'll type something out to that effect.
Consensus: We're all a bit unclear about the semantics here. Let's ask Ralf.
}, as the RFC said" rust#119057Link: https://github.com/rust-lang/rust/issues/119057
TC: We discussed this in the meeting on 2023-12-13 but were uncertain about the ask. dtolnay has since replied with a detailed history and motivation.
TC: Do we want to take a few minutes to read this?
A design aspect of the let-else RFC that was important enough to feature in the 6-sentence summary is that the
EXPRESSIONin the syntaxlet PATTERN: TYPE = EXPRESSION else DIVERGING_BLOCK;must not end in}.This restriction ended up in the RFC based on multiple rounds of feedback.
- The feature originally envisioned by the author did not have this restriction. It only had the essential restriction that
EXPRESSIONmust not beif … {…}(+else if) because in that case the new syntax would collide with stable syntax that already had a different meaning.- Based on a suggestion in Zulip by bstrie shortly before the publication of the RFC, the syntax was made more restrictive to say
EXPRESSIONmust not be what the Reference calls ExpressionWithBlock. The change was made in rust-lang/rfcs@3438586 and means the expression must not be any of{…},unsafe {…},loop {…},while … {…},for … in … {…},if … {…}(+else if+else), ormatch … {…}.- The wording to disallow the above expressions was made more precise in response to Niko's non-blocking concern. The wording improvement was made in rust-lang/rfcs@89c5b6e without changing the intent of the restriction.
- In response to steffahn's insightful comment and a related older unresolved review by nagisa and followup, followed by several +1 comments in GitHub and Zulip, and digama0's review, the syntax was made more restrictive again to disallow
EXPRESSIONfrom being anything having the last token}. This change was rust-lang/rfcs@c0c2fcc. It disallowsasync {…},try {…},const {…},Struct {…},|…| {…},&{…},break {…},return {…}and many others. This restriction was not implemented by the compiler. Later fixed by More expressions correctly are marked to end with curly braces #118880 in Rust 1.76.- With further iteration from Zulip, the wording was clarified in rust-lang/rfcs@b6b87d6 to emphasize that any expression ending in
}before macro expansion is not allowed.mac! {…}is one such example. This restriction was not implemented by the compiler and the cases in More expressions correctly are marked to end with curly braces #118880 (comment) all violate it.The compiler's implementation of let-else did not implement the restriction described by the accepted RFC, so some programs that the RFC says are invalid syntax are accepted by stable Rust compilers since 1.65.0.
To understand why disallowing only ExpressionWithBlock is not sufficient, see the code samples containing
-ifin steffahn's comment.Separately from the ambiguities explained in that comment, steffahn also was I think the first to note a human value in having
} else {always mean anelsecorresponding to anif, as opposed to anelsecorresponding to alet. This is voiced in steffahn's comment linked above, as well as subsequent discussion on Zulip arriving at agreement about the final strengthenings ("on the grounds that it makes it easy to distinguish let from let-else by looking for anelsenot preceded by}").rust-lang/rfcs#3137 (comment) has a summary of the consensus from Zulip and the state of the RFC after the second strengthening of the restriction.
rust-lang/rfcs#3137 (comment) expresses the author's fondness in favor of the second strengthened restriction, "to be clear to human readers", which I also agree with, and is further reinforced by a lang team consensus expressed by Josh in Zulip: "Based on the lang team consensus, the thing we wanted to avoid was
let PAT = some_construct_with { braces } else { diverge };"At the time, only one single exception to the must-not-end-in-
}form of the restriction was still being considered, and that was very explicitly the specific case of{…}, i.e.let … = {…} else {…};with nothing between the=and first{. "So, nothing that ends in}and doesn't start with{unless it's wrapped in parentheses or braces." Ultimately there was not consensus about this exception, there was strong opposition in Zulip and it was never written into the RFC or implemented in the compiler.The issue of
}beforeelsedid not get listed as an unresolved question in the final draft of the RFC which got merged. This is because the topic was sufficiently resolved by the discussion described above and the lang team consensus via Zulip, and all parties were in agreement about this iteration of the restriction. So there was no further discussion of it in the tracking issue nor during stabilization aside from one brief comment reinforcing that the restriction is intentional and future possibilities are left open.@dtolnay: If there's a specific rule that you would propose here for the handling of this kind of thing, please describe that and why it would be better and then renominate this issue for further discussion.
The rule I like is that
EXPRESSIONmust not end in}, which was the RFC final draft.To the extent that the compiler is going to accept some
EXPRESSIONwhich end in}(which is not my preference), I think those cases should be approved by the lang team since so far no exceptions to must-not-end-in-}have been through team approval.#118880 (comment) has stats on the prevalence of the incorrectly accepted syntax on crates.io. Currently there are 0 occurrences of
let … = mac! {…} else {…}, or any other form that would be broken by implementing the} elserestriction, such aslet … = … + &mac!{…} else {…}.
TC: What do we think?
CE: The problem is the last time we talked about this, we were unsure about what was ambiguous here. But the real argument here isn't ambiguity, it's that in the original RFC we had decided we didn't want this stylistically. So there's just one exception to this. dtolnay has done a "crater run" with syn looking for cases of this. We should just do it.
CE: The last PR only denied unstable expressions. I r+ed that since it's consistent with the RFC.
CE: So the question here for T-lang is, do we consider rejecting macro calls as consistent with the RFC, and do we care about the breakage, which has been measured to be low or zero.
CE: This is arguably a bug fix, if we consider this as having not followed the RFC.
tmandry: Right, if this was not changed in the stabilization report, then it's a bug.
CE: This is such a detail I doubt it was mentioned in the stabilization report.
tmandry: We can FCP this.
CE: It'd be good to FCP my PR then:
https://github.com/rust-lang/rust/pull/119062
Consensus: Let's do this, and we'll FCP it.
Link: https://github.com/rust-lang/rfcs/pull/3543
TC: This proposed RFC has relevance for Rust for Linux:
This RFC proposes support for
patchable-function-entryas present inclangandgcc. This feature is generally used to allow hotpatching and instrumentation of code.The Linux kernel uses
-fpatchable-function-entryheavily, including forftraceandFINEIBTfor x86. Today, enabling these features alongside Rust will lead to confusing or broken behavior (ftracewill fail to trace Rust functions when developing,FINEIBTwill conflict with thekcfisanitizer, etc.). It also uses theclangandgccattributepatchable_function_entryto disable this padding on fragile functions or those used for instrumentation.Integrating Rust code into this and other large projects which expect all native code to have these nop buffers will be made easier by allowing them to request the same treatment of native functions they get in C and C++.
TC: Josh nominated this for us. What do we think?
scottmcm: Is there anything to discuss in triage?
TC: Josh nominated this for us, but isn't here to say what he wanted to discuss.
tmandry: I have some context, but have one question.
scottmcm: Feel free to propose FCP merge if you have context.
scottmcm: It may be the sort of thing that's difficult to write a Rust AM spec for.
tmandry: I'll propose FCP merge and file a concern.
Consensus: We'll all have a look now that there is a proposed FCP merge.
Link: https://github.com/rust-lang/rust/pull/118699
TC: nnethercote wants to make some string and character literals that today are parsing errors into semantic errors. This would allow macros to assign meaning to these literals, but that might also limit our flexibility to assign new meaning at the language level later. nnethercote:
It changes some errors related to literals from syntactic to semantic. In the compiler, this is all the errors in the
EscapeErrortype. These all relate to char/byte/string literals, and mostly relate to escape sequences, plus a couple of others (e.g. having more or less than one char/byte in a char/byte string literal, or having a NUL char in a C string literal.)Here is example code showing how things change. This covers some of the relevant errors, but not all; the missing ones would be affected in the same way.
fn main() { ''; //~ error: empty character literal b'ab'; //~ error: character literal may only contain one codepoint "\a"; //~ error: unknown character escape: `a` b"\xzz"; //~ error: invalid character in numeric character escape "\u20"; //~ error: incorrect unicode escape sequence c"\u{999999}"; //~ error: invalid unicode character escape } sink! { ''; // was an error, now allowed b'ab'; // was an error, now allowed "\a"; // was an error, now allowed b"\xzz"; // was an error, now allowed "\u20"; // was an error, now allowed c"\u{999999}"; // was an error, now allowed }; #[cfg(FALSE)] fn configured_out() { ''; // was an error, now allowed b'ab'; // was an error, now allowed "\a"; // was an error, now allowed b"\xzz"; // was an error, now allowed "\u20"; // was an error, now allowed c"\u{999999}"; // was an error, now allowed }This means a macro can assign meaning to arbitrary escape sequences, such as
foo!("\a\b\c").This change is consistent with a general trend of delayed literal checking:
- Floating point literals have had this delayed checking behaviour for a long time (forever?)
- This PR did a similar thing for numeric literals.
- The NUL char checking for C string literals is implemented in this semantic (delayed) fashion.
There's been substantial follow-on discussion between scottmcm and nnethercote in the issue that is worth reading.
TC: What do we think?
CE: I don't really understand the motivation here. It feels weird to allow invalid tokens that don't end up in rustc code.
scottmcm: The numeric literal case I really liked. It's obvious that a bunch of 9s should be an integer literal. If there are too many for a number of a particular size, it's still an integer literal. So I liked that change.
scottmcm: But I'm far less convinced here, because I'm unclear what the value of allowing '' to be a character literal is.
CE: Maybe we should split that one out, since that's the weirdest one.
scottmcm: It seems like nnethercote was not a fan of the inconsistency.
TC: We should probably look at what the lang design space we'd be giving up would be.
scottmcm: That is important. We had discussed, e.g., adding ''a. I'm not saying we want to do that, but we did discuss that, and this would be ruling that out. We plausibly do want to reserve lexical space here.
CE: There maybe doesn't seem a compelling enough reason to close these doors.
CE: We could ask Nick about breaking these up.
scottmcm: Nick wants to go one direction or the other.
TC: What's the cost to being consistent in the other direction.
CE: It's difficult to handle C strings consistently that way, since we need to handle older editions, so we don't know it's a C string after after parsing rather than after lexing.
tmandry: We should negative across the board.
scottmcm: There are pieces of this I find compelling. Just not all of it.
tmandry: Agreed, I could see loosening some of it.
CE: It might be better to hear from Nick about his thoughts on the difficult of going the other direction.
scottmcm: I kind of like c"\x00" is rejected semantically, though. It's clear what it means and it doesn't seem it needs to be rejected lexically.
TC: It's kind of the same as the others in that regard, similar to your example with the 9s.
scottmcm: I don't want this to be a token "\u{'}", nor "\u{" – and how many tokens is '\u{'}'?
Consensus: Let's give feedback to Nick, perhaps about his thoughts on going in the other direction, or about breaking these out, since there were parts of this that we might like.
(The meeting ended here.)
wasm_c_abi future-incompat lint" rust#117918Link: https://github.com/rust-lang/rust/pull/117918
TC: daxpedda gives the context:
This is a warning that will tell users to update to
wasm-bindgenv0.2.88, which supports spec-compliant C ABI.The idea is to prepare for a future where Rust will switch to the spec-compliant C ABI by default; so not to break everyone's world, this warning is introduced.
TC: Is this something we want to do?
#[expect] attribute" rust#115980Link: https://github.com/rust-lang/rust/issues/115980
TC: @nikomatsakis gives this background:
This issue is spun out from #54503 to serve as the decision issue for a specific question. The question is what the 'mental model' for the
expectattribute should be. Two proposed options:
- The expectation is fulfilled, if a #[warn] attribute in the same location would cause a diagnostic to be emitted. The suppression of this diagnostic fulfills the expectation. (src) (Current implementation in rustc)
- The expectation is fulfilled if removing the
#[expect]attribute would cause the warning to be emitted. (src)@xFrednet created a list of use cases to help with the discussion of these two models; they found both models work equally well, except for use case 4 which would only be possible with the first model.
TC: …and proposes that we adopt option 1.
warnings level for a specific lint via command line" rust#113307Link: https://github.com/rust-lang/rust/pull/113307
TC: We discussed in the 2023-09-26 meeting, but were unsure of the question we were being asked. @jieyouxu has since replied:
I believe I wanted to ask that if the command line indeed forms the root of the tree, or if it actually overrides the source annotations.
TC: On that basis, @tmandry replied:
Nesting
I think the command line (specifically
-A,-W,-Dflags) should form the root of the tree. We have--cap-lints,--force-warn, and-F(forbid) for overriding the source. (Actually the mental model documented in the rustc book is thatforce-warnandforbidstill form the root of the tree, but cannot be overridden; I think the distinction is mostly academic.)That's almost all the expressive power one could want along this axis. One wrinkle is that
--forbidis overridden by--cap-lints, while--force-warnis not. If we wanted full fine-grained control we could always add--force-allowand--force-deny.
warningsRegarding the meaning of
warnings, it is a simpler mental model for this to mean "the set of things that are warn-by-default". But this ignores what I perceive to be a common (and valid) use case, which is to disallow all warnings in a codebase: In other words, prevent code from being checked in that causes warnings to be printed to a user's screen. Of course, for this to be practical one must control the version of rustc being used to build a codebase, but that is common in monorepo setups.Conclusion
Given that there is an existing use case that relies on documented behavior, I think we should continue to treat
warningsas a "redirect" for all warnings that come out of a particular level of the tree. Interpreting-Awarnings -Wfooin the way proposed by this PR would muddy the (already complicated) mental model and add inconsistency between CLI and the command line, as noted by @oli-obk.A different group, like
default-warnings, could be used to mean "the set of things that are warn-by-default". The compiler could further warn users that specify-Awarnings -Wfooon the command line to use-Adefault-warnings -Wfooinstead.
TC: Where do we want to go from here?
.await does not perform autoref or autoderef" rust#111546Link: https://github.com/rust-lang/rust/issues/111546
TC: This was nominated for T-lang by WG-async. @tmandry said:
We discussed this in a recent wg-async meeting (notes). The consensus was that we thought the change was well-motivated. At the same time, we want to be cautious about introducing problems (namely backwards compatibility).
There should probably be a crater run of this change, and we should also work through any problematic interactions that could be caused by this change. (@rust-lang/types should probably weigh in.)
The main motivation for the change is the analogy to
.method(), as well as to wanting async and sync to feel similarly convenient in most cases.Note that there is another analogy that works against this, the analogy to
IntoIterator, where the lang-effect form (for _ in foo {}) does not do autoref/autoderef. However, given that this looks very different fromfoo.await, and taking a reference with that form is significantly more convenient (for x in &fooorfor x in foo.iter()vs(&foo).await), it seemed the analogy was stretched pretty thin. So we elected to put more weight on the above two considerations.That being said, this change would need lang team signoff. You can consider this comment wg-async's official recommendation to the lang team.
TC: There's now been a crater run done for this. The result was that this breaks a small number of crates, but at least one of those crates has a large number of dependencies (aws-smithy-runtime). It can be fixed in the dependency in such a way that dependent crates do not have to make changes, but those dependent crates would need to update to a fixed version of the dependency.
(See this discussion.)
TC: What do we think?
Link: https://github.com/rust-lang/rfcs/pull/3503
TC: We discussed this for most of one triage meeting in November without reaching any consensus. There is a design meeting proposal, but we have not yet scheduled it for a date. At Josh's suggestion, Ed Page has renominated this for us.
TC: With the T-lang-ops hat on, my feeling is that this would benefit from further asynchronous discussion before we reapproach this in a meeting, so I've opened a thread for that:
Back in November, we discussed proposed RFC 3503 for most of one triage meeting. We didn't reach a consensus. @scottmcm raised these interesting points:
My biggest question here is how much it should be thought of as tied to the script use, and thus to the
#!.My instinct is that either
- This is tied to the shebang, so there's only one of them, to be consumed only by whatever tool is in the shebang, and rustc completely ignores it, like we completely ignore the shebang line. And thus the "
```right after the shebang" syntax seems entirely reasonable to me.- This is a general tool feature, for which there will be multiple of them, and for which they'd want something like tool attribute namespacing so there's a clear route to lots of them under understood namespaces, and are a full part of the parsed structure of the crate, maybe included in rustdoc, etc. (Like perhaps
--document-private-itemson a crate would show an embeddedrustfmt::configblock somewhere, one day.)@nikomatsakis noted that, even if it's tied to a shebang, he doesn't see a reason to limit it to only one.
@tmandry suggested that:
With my lang hat on, I don't see a reason we should RFC a feature that only allows
cargofront matter, without specifying a path to generalizing it to other tooling. If we want to be conservative in what we stabilize, let's approach that in the stabilization rather than in the RFC.In the meeting, @nikomatsakis suggested that we seem misaligned on the purpose of this. Others in the meeting suggested that the syntax should derive from a clear understanding of that purpose and the eventual goals for it.
TC: Do we want to first make progress async, or do we think we can make progress in the meeting here?
Link: https://github.com/rust-lang/rust/issues/117860
TC: The question is whether this should be true:
Unless and until RFC PR 3373 is accepted and scheduled for stabilization in some future edition, items nested inside of other items may define the hidden type for opaques declared outside of those items without those items having to recursively be allowed to define the hidden type themselves.
The context is that we allow this:
trait Trait {}
struct S;
const _: () = {
impl Trait for S {} // Allowed.
};
Should we accept spiritually-similar TAIT code unless and until we decide to go a different direction with the language?
Link: https://github.com/rust-lang/rust/issues/117861
TC: The question is whether this should be true:
At least until the new trait solver is stabilized, any item that is allowed to define the hidden type of some opaque type must define the hidden type of that opaque type.
TC: This is important for the new trait solver.
TC: Here's one reason for that. The new trait solver treats strictly more code as being a defining use. It's also more willing to reveal the hidden type during inference if that hidden type is defined within the same body. This rule helps to avoid inference changes when moving from the old solver to the new solver. Adding this restriction makes TAIT roughly equivalent to RPIT with respect to these challenges.
TC: (This question is entirely orthogonal to how we notate whether an item is allowed to define the hidden type of an opaque.)
Link: https://github.com/rust-lang/rust/issues/117865
TC: The question is whether this should be true:
The compiler is allowed to rely on whether or not an item is allowed to define the hidden type of an opaque type to guide inference.
Here's the door that this would close:
If this rule is adopted, then after TAIT is stabilized, it will not be possible in a fully backward compatible way to later change the rules that determine whether or not an item is allowed to define the hidden type in such a way that an item in existing code that uses an opaque type could switch (without any code changes) from being not allowed to define its hidden type to being allowed to define it.
TC: This is of importance to the new trait solver.
TC: Here's one reason for this. When we're type checking a body and we find an opaque type, we sometimes have to decide, should we infer this in such a way that this body would define the hidden type, or should we treat the type as opaque (other than auto trait leakage) and infer based on that? Depending on that, we can get different answers.
TC: If we did not let inference rely on this, then we would be closing the door on later allowing inference to rely on this without provoking changes in inference.
TC: (This question is entirely orthogonal to how we notate whether an item is allowed to define the hidden type of an opaque. Answering this question in the affirmative would update one element of the #107645 FCP.)
Link: https://github.com/rust-lang/rust/issues/117866
TC: The question is whether the following should be true:
If the body of an item that may define the hidden type of some opaque does define that hidden type, it must do so syntactically before using the opaque type in a non-defining way.
One of the big design questions on TAIT is whether we'll be able to later lift the "may define implies must define" rule after we land the new trait solver. The answer to that question could inform other design decisions, such as how to notate whether an item is allowed to define the hidden type of an opaque.
The restriction here is designed to make it more likely (hopefully much more likely) that we can later lift the "may define implies must define" restriction.
clippy::precedence lint" rust#117161Link: https://github.com/rust-lang/rust/pull/117161
TC: The proposal is to lint against:
-2.pow(2); // Equals -4.
1 << 2 + 3; // Equals 32.
These would instead be written:
-(2.pow(2)); // Equals -4.
1 << (2 + 3); // Equals 32.
Prompts for discussion:
rustc?Link: https://github.com/rust-lang/rust/issues/116557
TC: nikomatsakis nominated this:
We had some discussion about types/lang team interaction. We concluded a few things:
- Pinging the team like @rust-lang/lang is not an effective way to get attention. Nomination is the only official way to get attention.
- It's ok to nominate things in an "advisory" capacity but not block (e.g., landing a PR), particularly as most any action can ultimately be reversed. But right now, triagebot doesn't track closed issues, so that's a bit risky.
Action items:
- We should fix triagebot to track closed issues.
Link: https://github.com/rust-lang/rust/pull/116584
TC: RalfJ nominated this one, and he has a corresponding design meeting proposal:
We'd like to remove the ability to disable certain target features. The broad goal we are going for here is that code built for the same target is ABI-compatible no matter the target features. This is an easy rule to remember and a principle that it seems reasonable to enforce. This principle is currently violated in several ways (for x86, that's tracked in #116344 and #116558). This PR is one part of achieving that, this pre-RFC is another part, and then one final piece is needed to reject
+x87/+sseonx86_64-unknown-none(or to reject float-taking/float-returning-functions) as that would similarly change the ABI.…
I have created a design meeting proposal for the wider problem space here, in case you think this needs more fundamental discussion.
TC: We have this scheduled for a design meeting on 2023-12-20.
None.
Link: https://github.com/rust-lang/lang-team/pull/236
Link: https://github.com/rust-lang/lang-team/pull/237
None.
S-waiting-on-teamanonymous_lifetime_in_impl_trait" rust#107378Link: https://github.com/rust-lang/rust/pull/107378
Link: https://github.com/rust-lang/rust/pull/116284
non_camel_case_types for screaming single-words" rust#116389Link: https://github.com/rust-lang/rust/pull/116389
Link: https://github.com/rust-lang/rust/pull/116863
unstable_features and make use of it in the compiler" rust#118639Link: https://github.com/rust-lang/rust/pull/118639
Link: https://github.com/rust-lang/rust/pull/119062
Check your boxes!
Link: https://github.com/rust-lang/rfcs/pull/2375
Link: https://github.com/rust-lang/rfcs/pull/3325
Link: https://github.com/rust-lang/rfcs/pull/3336
Link: https://github.com/rust-lang/rfcs/pull/3379
Link: https://github.com/rust-lang/rfcs/pull/3514
Link: https://github.com/rust-lang/rust/issues/37854
Link: https://github.com/rust-lang/rust/pull/104087
PartialOrd and Ord for Discriminant" rust#106418Link: https://github.com/rust-lang/rust/pull/106418
anonymous_lifetime_in_impl_trait" rust#107378Link: https://github.com/rust-lang/rust/pull/107378
Link: https://github.com/rust-lang/rust/pull/112879
c_unwind full stabilization request: change in extern "C" behavior" rust#115285Link: https://github.com/rust-lang/rust/issues/115285
#[expect] attribute" rust#115980Link: https://github.com/rust-lang/rust/issues/115980
non_camel_case_types for screaming single-words" rust#116389Link: https://github.com/rust-lang/rust/pull/116389
Link: https://github.com/rust-lang/rust/pull/116677
Link: https://github.com/rust-lang/rust/pull/116935
Link: https://github.com/rust-lang/rust/pull/117457
Link: https://github.com/rust-lang/rust/pull/117468
Link: https://github.com/rust-lang/rust/pull/117614
Link: https://github.com/rust-lang/rust/pull/117905
Link: https://github.com/rust-lang/rust/pull/117703
None.
-
Any changes
Be notified of any changes
-
Mention me
Be notified of mention me
-
Unsubscribe
Subscribe