| title | tags |
|---|---|
Triage meeting 2022-03-08 |
triage-meeting |
- Meeting date: 2022-03-08
- Team members: nikomatsakis, Felix, Josh, scottmcm
- Others: Mark, Lokathor, Urgau, Michael, Jane
- Action item scribe: Mark
- Note-taker: nikomatsakis
- Mar 9: Roadmap lang-team#140 (nikomatsakis/joshtriplett to write document)
- Mar 16: Backlog Bonanza!
- Mar 23: RPITIDT lang-team#144 (nikomatsakis/tmandry to write document)
- Mar 30: Lint policy lang-team#132 (pnkfelix to write document)
- Steps posted for creating tracking issues for project proposals:
Link: #102
Link: #116
Link: #118
Link: #125
joshtriplett: there was an extensive amount of Zulip discussion in the last week. Effectively, what do we think the appropriate way to handle this could be in order to support other targets with various properties? Conclusion that we came to on Zulip was that
- we could make an incremental step to agree that
usizeissize_tand some name that CHERI used for the size of a pointer valueptraddr_t, which is non-standard but defines the numeric size of a pointer address (on CHERI, addr space is 64 bit, but ptrs are 128 bit b/c of security tags; on that architecture,ptraddr_tis 64-bit, butuintptr_tis 128-bit). Conclusion that we roughly came to on Zulip was that we could defineusizeto besize_tandptraddr_t, and leave open the question for whether we are willing to make compromises necessary to allowusizeto not beuintptr_t.- That would unblock some things now and we can revisit the portability question.
- Would be a divergence from the original RFC that introduced usize, which defined
usizeto beuintptr_t. - That may just have been a mistake.
nikomatsakis: is the next step here an RFC?
scottmcm: sounds to me like if goal is to declare "this will be the case from now going forward" and "undoing a previous decision" that an RFC sounds appropriate
joshtriplett: I agree. If this hadn't previously been in an RFC, I would've just suggested a PR updating documentation for usize and std::ffi::size_t and similar. But given that this went through an RFC I think we need at least a minimal RFC.
nikomatsakis: would that RFC say "it's defined as ptraddr_t, which on all major architectures is uintptr_t etc?"
joshtriplett: I think we would say it's deferred until we add such an architecture. Two reasonable paths:
- we don't support
uintptr_tandusizebeing different - or, we do, but on those architectures,
usizeis notuintptr_t
scottmcm: what concretely can someone observe right now that cares?
scottmcm: if this is an RFC saying "we're thinking of doing this in the future" does that really need an RFC? FFI type aliases could in theory be u32, u64? That would break some platforms... but the platforms that would break would be the ones that don't have the same as usize ... but they already don't work...?
joshtriplett: Rust distinguishes those types, so if size_t were passed through FFI as u32 on a 32-bit platform, you couldn't swap it with usize...
scottmcm: right but that only impacts platforms that don't currently exist?
joshtriplett: No, it would impact platforms that do exist today. The practical consideration is that people are using usize to mean size_t, which seems obviously correct ("it has size in the name"). But if we tell people "you're wrong, and you should be using std::ffi::size_t (which would have to be stabilized, but it's blocked on this issue)", that would be a lot of churn. Just like it'd be a lot of churn to say "you can't store a pointer sized integer value in a usize". Both are observable today and people are doing both of them. The question is do we break one or both of those or declare them to be correct.
scottmcm: I think what I'm trying to say is, if we need a type bigger than size_t for some platform, and that type alias was usize on all our current platforms, but on other platforms it becomes u128, that would not break the current platforms.
joshtriplett: yes but it would require us to allow for that assumption to be different on other platforms.
... we're going too deep into this question.
joshtriplett: the idea is in order to give people more confidence that what they are doing is correct, or decide that it is actively wrong, we need to make a decision about what we might allow in the future, or what we commit to not allowing in the future. I think we'd get value about deciding to commit to having usize.
nikomatsakis: This seems like a case where the mythical portability lint could help. I'm not ready to say "We don't support CHERI", but people writing on mainstream targets should be able to make assumptions.
joshtriplett: Would love to see the where Target: xyz proposal move forwards, with a lang change to allow declaring that requirement for a crate.
nikomatsakis: it seems like we are driving towards a proposal for a "portability lint 2.0" that has this as an example use case, I'd be happy if we closed this proposal in favor of a slightly broader proposal driven by mara/josh and with these folks as stakeholders.
scottmcm proposes a wild idea: what would it take for the C FFI types to be newtypes instead of aliases? Any code I write with cint has the same problems, right?
joshtriplett: std 2.0 in terms of the amount of breakage (:gasp:). I don't think code you write with c-int has these problems since you expect c-int to be a size that varies by architecture. The reason core::ffi::c_int (just added!) exists is to say "I want the thing C calls an int, which I am not assuming is a fixed size". You can say "I only want to run on platforms where c-int is 32 bits."
scottmcm: since nothing protects you from making it, I would assume that assumption is made pervasively, just as it is in C
joshtriplett: quite possibly. That would be something where we could add a portability lint to help you catch that, but we might not want it on by default, since that would break a lot of code for cases that largely don't exist outside of 16-bit platforms.
lokathor: practicality issue as well, since C code is not consistent, since casting between integers is automatic. new types would be much harder to use in Rust.
joshtriplett: I think we should invite a proposal re: portability.
nikomatsakis: agreed, some minimal declarations to give folks confidence, and saying we plan to definitely resolve via portability, would be ideal
joshtriplett: going to take an action item to invite somebody from libs (e.g., mara) to explore "crate-level where Target: ... kinds of things".
scottmcm: a lot of unknowns, we'd need a concrete proposal.
Link: #126
joshtriplett: Starting a conversation next week with a researcher about usability testing.
nikomatsakis: let's also think about general guidelines for how to assess these kinds of questions, since they come up semi-regularly
Link: #129
Close, deferring.
const-eval still working on this, but this topic is not ready for a lang-team design meeting.
Link: #135
Link: #139
Link: #143
None.
None.
Check your boxes!
Link: rust-lang/rust#64926
Link: rust-lang/rust#93628
still blocked on temporary rules, consistency of let and let else
semicolon:
Several people have independently made the point that most braced blocks of code in Rust don't require a trailing semicolon, and that people are likely to regularly forget this. I'm finding myself starting to agree with that opinion.
scottmcm: every time I use this I go "why is it there", I know the answer, not against it, particularly since we can remove it later, but ...
joshtriplett: how confident are we that we can always do it later?
scottmcm: quite confident because it only appears in blocks; if you put a semicolon after the let, you get an empty statement, and let cannot be a trailing statement in the block since it is not an expression.
joshtriplett: not opposed to removing semicolon, but want to know if it's blocking...
nikomatsakis: I'm opposed to removing it if we don't also remove it from let
joshtriplett: how would that even work?
nikomatsakis: I don't think it would, which is why I don't want to remove it :)
nikomatsakis: I feel it will be surprising that you have to delete the else and add semicolon when changing from a pattern
let Some(x) = ....
else { return; }; // the second ; feels odd to scottmcm
nikomatsakis: not dead against removing the ;, but I'd rather go forward as is and then evaluate in a narrow fashion whether to remove it via some experiments or something
scottmcm: diagnostics will also be helpful, if we get a billion questions about forgetting the semicolon
nikomatsakis: what annoys me more is that I need a block in the first place, I usually want to just say else return
joshtriplett: would you like to invite someone to do an initiative?
nikomatsakis: I think it'd be nice, but I wouldn't have bandwidth to second it
Link: rust-lang/rust#94295
joshtriplett: check your boxes niko/felix, or speak up if you don't want this
Link: rust-lang/rust#90957
Link: rust-lang/rust#92472
Link: rust-lang/rust#93745
Link: #102
Link: #118
- seconded by nikomatsakis -- action item for nikomatsakis to create tracking issue!
Link: #126
- seconded by josh triplett
Link: #129
proposed to close by nikomatsakis-- close.
tl;dr: the next steps
Link: #135
- seconded by cramertj
None.
Link: rust-lang/rust#28937
allows you to do
use crate::main
or
use submodule::main
to supply main. Useful for some embedded crates.
simulacrum: compiler team was a bit concerned that it had no actual use, josh do you know of actual use?
joshtriplett: I've definitely seen people request this, I'd have to do some digging to find it.
lokathor: how would a library's main function call your code?
joshtriplett: globals, exported symbols
simulacrum: could be a submodule, too
joshtriplett: right, that's another case where folks have wanted it. I've seen people want to do #[cfg(target1)] use submod::main; #[cfg(other_target)] use othermod::main;
jlusby42: How is this different from having your own locally defined main with cfg-arms that call other functions?
joshtriplett: boiler-plate and people generally expect use to "bring in a thing with the given name". Not that you can't work around it. No massive functionality missing, just a "nice to have".
nikomatsakis: basically says "there has to be a name main bound at the root of the crate, whether it be imported or defined explicitly"
scottmcm: if the compiler people felt this is a pain, I'd say "remove it", if it's easy, then "sure"
joshtriplett: from what I saw it required removing an assumption in one place but otherwise compiler folks were happier to have this supported than to have the #[main] attribute, which was removed as a result
nikomatsakis: no strong opinion, but it feels like the model of "there's an implicit call to something call crate::main". I do think having at least a single user would be nice. Let's make sure there's at least some!
joshtriplett: can you comment to that effect?
Link: rust-lang/rust#20041
joshtriplett: Felix says that "@jackh726 says that niko has had some concerns regarding arbitrary where clause equality constraints", would Niko like to comment directly?
nikomatsakis: I do have some concerns. Adding in arbitrary equalities like A = B raises up the logic into a more complex thing. It's true that you can do where T: Eq<U>, trait Eq<X> impl Eq<Self> for Self, but that's not quite the same as T = U, because you don't necessarily the compiler to understand that T: Eq<U> implies T = U.
joshtriplett: Couldn't you do trait UniqueName; impl UniqueName for RHS; ... where LHS: UniqueName
nikomatsakis: Example that people might want to work
fn foo<T, U>(t: T)
where
T = U,
U: Debug,
{
println!("{:?}", t)
}scottmcm: I've tried to use it to extract type parameters...
nikomatsakis: the fundamental reason this is harder is that things you used to be able to infer, e.g. ?X = i32 is only true if ?X is i32, but not if you have where i32 = u32 in the environment. That's already true for assoc types, so it may not be that significant, but at least it's constrained to assoc types then. But I can't remember all the details of this right now.
nikomatsakis: maybe we could accept it but narrow it to T::Item = u32 instead of T: Iterator<Item = u32>, then it is just more convenient and leaves door open for later
pnkfelix: issue #20041 literally uses that kind of example, wanting to check for iterator items
joshtriplett: Should we defer this to WG-traits?
Link: rust-lang/rust#94081
rust-lang/rust#94081 (comment)
user visible change 1: RPIT inference from recursive call sites
fn bar(b: bool) -> impl std::fmt::Debug {
if b {
return 42
}
let x: u32 = bar(false); // this errors on stable
99
}user visible change 2: divergence between RPIT and TAIT in return statements
fn bar(b: bool) -> impl std::fmt::Debug {
if b {
return vec![42]
}
std::iter::empty().collect() // Works, magic (accidentally stabilized, not intended)
}
type Foo: Debug;
fn bar(b: bool) -> Foo {
if b {
return vec![42]
}
std::iter::empty().collect() // Error
}upshot:
- Niko to try and write a document that outlines what each change means (upside, downside) and
- to distinguish "change in behavior from stable" vs "interesting fact"