No more meetings planned until end of year.
Holiday schedule
Zip. Nada. Zilch.
None.
None.
dyn Trait values" rfcs#3324Link: https://github.com/rust-lang/rfcs/pull/3324
Link: https://github.com/rust-lang/rfcs/pull/3327
Check your boxes!
Team member @pnkfelix has proposed to merge this. The next step is review by the rest of the tagged team members:
- @cramertj
- @joshtriplett
- @nikomatsakis
- @pnkfelix
- @scottmcm
No concerns currently listed.
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
See this document for info about what commands tagged team members can give me.
Before this change, there was a hard error associated with hitting the internal const-eval limit. And thus there was a notion that every rust compilation is "always" guaranteed to terminate. (Note this was a flawed notion, since proc-macros do not currently have any such limit imposed on their execution.)
This PR changes that by turning this limit into a lint that can be allowed by the user.
I want lang team to sign off explicitly on the idea of introducing some kind of user-exposed limit that 1. allows the user to change the limit on how long const-eval can proceed (where the values it can change to in this PR are limited to either ∞ via allow or 1,000,000 via deny) and 2. can introduce a new way for the compiler to infinite loop (i.e. by the user turning off the limit)
Things I want to discourage as being "out of scope" for this fcp discussion:
- This PR also changes the underlying mechanism that drives the diagnostic machinery, namely by using exponential backoff, but I want to treat that as a detail associated with the lint=warn case; the lang team currently should focus solely on the question on whether we expose this as a user-controllable thing at all. In other words, the focus for this fcp should be on the fact that the lint can be set to
allow.- The specific details of what metric is used is not under fcp. (@nikomatsakis and I agree that counting terminators executed is not a good metric to expose to users in the long term (it is too coupled to the internal details of MIR).)
- This fcp is not committing us to never exposing a finer-grain control. I.e. it may be a good idea to revise this lint to allow someone to override the threshold, rather than keeping the hard-coded limit of 1,000,000. But I do not want to side-track this fcp with discussions of that; I think exposing the ability to control the specific number should only come after the metric itself has been revisited.
(I am willing to consider "what should this lints default be: is it allow-by-default or deny-by-default" as something in scope for lang team discussion.)
@rfcbot fcp merge
scottmcm: how does this interact with parallel compilation RFC? more of a compiler problem.
joshtriplett: I feel we should change this to "exponent backoff progress indicator" and leave the mechanism to the compiler.
pnkfelix: idea of using lint mechanism to specify constraints.
joshtriplett: lints don't take parameters, how would you do that?
pnkfelix: I just meant allow/deny
scottmcm: deny means .. machine dependent?
nikomatsakis: I continue to be unenthusiastic about this approach, I think we could have a predictable limit that we can just raise, which avoids these complications.
joshtriplett: If we can have a limit that is independent from optimization or machine, then by all means, let's talk about it. in the meantime, the current fuzzy limit is something we should drop. I don't think we should tie those two together.
nikomatsakis: we do have a reasonable plan, but once we drop the limit, we can't go back there, right?
pnkfelix: changing the metric now is a breaking change, right?
nikomatsakis: we're counting every step today, we'd be counting a strict subset of those steps, right?
scottmcm: I thought we didn't even run CTFE on optimized MIR?
joshtriplett: what if we change how we desugar things?
nikomatsakis: what we're counting is loops and function calls, it's not really something that we change
pnkfelix: if we do that and keep the end the same, I agree we can assert it will accept strictly a superset of what is accepted before, but whether that's the correct threshold is a question?
joshtriplett: I'm concerned because now number of backedges is a semver breaking change. Any kind of limit is a breaking change.
nikomatsakis: Given timeouts and limits also kind of true, but yes, that's true.
pnkfelix: current situation where you can't adjust the limit is worst of both worlds.
scottmcm: a bit of a law vs fact thing. Anything that depends on time is so much more breaking than anything we could do that depends on the code you're running. If what we're trying to solve: if there's a limit, and we make it advisory, not something you can deny, we can use a smarter limit that's not time, that provides more information, be more consistent.
joshtriplett: if we're pointedly not giving a deny, only giving a progress indicator, I think time is the correct threshold. Every minute of compile we say "hey, still doing CTFE…".
pnkfelix: some people want the ability to deny, e.g., fuzzers.
joshtriplett: maybe the fuzzer wants to timeout…?
joshtriplett: can we get it down to what is compiler vs lang?
nikomatsakis: I feel the lang part is "will there be a limit" (and to a secondary degree, what is limit).
pnkfelix: if we say that whether there'll be a metric is lang team, and we are also going to say we don't want to allow for any breaking change here, ie., the threshold might be something we could strictly raise now, my concern now is that if we're going to say lang team responsibility to define that we need a stable metric, it's also up to us to decide if we are willing to accept a breaking change?
nikomatsakis: is this motivated by one specific thing, or by general streak of annoying breakages?
pnkfelix: one specific customer that has deliberately downgraded.
nikomatsakis: can they make a workaround today?
simulacrum: I think they have an attribute but it's not exposed on stable today
tmandry: goal of this is to prevent infinite loops?
nikomatsakis: basically, yes
pnkfelix: some folks have expectation that compilation will return a result. I've been pushing to say an answer here is to provide right level of feedback to say "hey, code is taking a long time, here is how you can adjust things so that you force it to finish with an error, or let it keep going".
nikomatsakis: ok, I do feel like this solution meets all the hard constraints, even though I don't love it…
the main argument in favor of this is–-
the main argument against is–-
scottmcm: the macro limit doesn't seem to cause big problems in practice; being "pretty close" is probably ok
pnkfelix: can add warn, but not hard error by default, that's part of this, right?
scottmcm: could add deny-by-default technically, but prob shouldn't, though we've done it before
tmandry: is it possible to write code that infinitly loops? do we prevent that?
scottmcm: It's easy; this is stable today:
pub const fn demo() -> ! { loop {} }
nikomatsakis: whether code terminates is highly relevant to proving things, but the limit doesn't really help there
pnkfelix: our official suggestion is that we don't approve of using lints…?
joshtriplett: we leave it up to compiler to provide appropriate progress indicators, but lints are not a great fit, as we expect them to be available even for stuff in crates
scottmcm: I think we're saying "no deny-able time-based limit"
joshtriplett: can't have a deny limit based on an unpredictable metric that varies from system to system, at the very least, and don't have consensus on whether we have a denyable lint even if it is, since it wouldn't be consistent from library to library
scottmcm: the more we approach that we have a defined lowering from rust to mir the more this becomes predictable, in the future we'd have more consistency about it, would be close enough to be stable as any other lint – we always can change them between compiler versions, right?
simulacrum: I know a lot of people experience the lints changing from version to version as very painful at scale. I think this would be annoying if you upgraded your compiler and you have to regularly bump some limit.
joshtriplett: I've seen the case made that we should consider being stricter about whether lints becoming stricter is a breaking change. I've seen people make the case that warning should be a breaking change.
scottmcm: leads to the C problem…
joshtriplett: not arguing with it, just observing
pnkfelix to report consensus to the PR and request change from "lint" to "progress indicator from the compiler"
Link: https://github.com/rust-lang/rfcs/pull/3323
Link: https://github.com/rust-lang/rust/pull/103293
Link: https://github.com/rust-lang/rust/pull/103578
None.
Link: https://github.com/rust-lang/rust/pull/103293
Removing nomination.
c"…" string literals" rfcs#3348Link: https://github.com/rust-lang/rfcs/pull/3348
josh: Came up in a previous meeting and said "well, vaguely in favor of this, but prob not quickly enough for libs to skip the macro". Mara took that as a challenge and wrote the RFC.
scottmcm: How do we feel about fat cstr? Seems totally fine but I'd be sad if c"foo" becomes the wrong type later?
josh: if we get thin cstr, should be the same cstr
scottmcm: are we sure we can do that?
mara: could block stabilization
scottmcm: or use an edition, wouldn't be fun though. Don't know the state of extern type though.
mara: I'm hoping that if we do this RFC with the c string literals, would give motivation to work on &CStr being a thin pointer.
josh: I left a pointer that we should make it block stabilization. We should either decide we are not making it a thin pointer (and change what C string literals mean) or decide that we are.
mara: regardless, if this will happen, we can say no to the cstr! macro.
nikomatsakis: I feel like this thin question can be resolved post RFC, I think the real question is whether we want this syntax for explicit C string literals.
scottmcm: which I also want, but FFI is imp't enough
nikomatsakis: even if we make them inferred, we prob want some form of explicit syntax anyway
scottmcm: perhaps type ascription
joshtriplett: would be nice to have p string literals for Path literals
mara: complicated because not in core, but yes
(conversation switched to rfc#3349 "UTF-8 characters and escape codes in (byte) string literals")
mara: someone proposed they should accept both utf-8 and non-utf-8, there's a related RFC bringing that to byte string literals. If we do that, there is no longer a difference between escape codes, which makes parser/macros easier, and we can enforce it later.
scottmcm: given our previous thing we FCP'd around tokens should accept whatever and make it a semantic error, at very least I think we'd accept "token can have whatever escapes you want and it's only when you use it as a non-token that it matters"
mara: tokenizer does need to understand where the string ends
scottmcm: I meant it would understand all the escape sequences and not emit errors until you use it as a non-token
nikomatsakis: in other words, all the escape sequences that any string supports, not all possible escape sequences
mara: roughly what I propose here but also not rejecting it later on, even, at least for byte strings
scottmcm: just splitting it in my brain since first part is comparatively easy. second part is more of a conversation.
joshtriplett: for future work, should we have some mechanism for macros to convert b-string to c-string and vice versa?
mara: my future plan is to fix the concat macro in the next edition, make it always use the string type of the first argument, so you can use do concat!(b"", ...) to concat whatever.
joshtriplett: ah, interesting. digresses a bit on whether this is a bug anyway, ok, we can handle that later.
(back to rfc#3348)
joshtriplett: anybody see a reason not to FCP this once we feel ready?
scottmcm: seems fine for someone to pfcp it
joshtriplett: can Rust source files contain embedded literal null characters inside a string?
mara: ummmmmmmm, let's try it out
joshtriplett: I hope you can't just a null ..?
scottmcm: seems no worse than a nbsp.
joshtriplett: at very least, for same reason we disallow \0 in a c string, can we also explicitly disallow a literal null inside a c string?
mara: I want to stop giving rules about what escape codes are allowed, and start giving rules about what bytes are allowed (e.g., disallow invalid utf-8).
mara: it already says that null byte is disallowed.
joshtriplett: ok.
Link: https://github.com/rust-lang/compiler-team/issues/570
nikomatsakis: this adds checks to catch deref of unaligned pointers
joshtriplett: debug-assertions are related to debug builds of crates?
nikomatsakis: yes.
joshtriplett: this would make debug builds check raw pointer alignment before dereferencing …?
joshtriplett: right now you can turn on/off integer overflows without changing other things
pnkfelix: but integer overflows have a semantics (in Rust)
nikomatsakis: is the motivation for turning off performance of debug builds or is it I want to be able to deref aligned pointers?
joshtriplett: not performance. I'm not too worried about this making debug builds too slow, prob not a big deal, we may be able to optimize away check sometimes too. I'm thinking of existing code that does this and isn't actually wrong to do so.
nikomatsakis: I don't think that if code does this, it is wrong
joshtriplett: I think it's false to always deref an unaligned pointer if you're on a platform
scottmcm: but it's still wrong because we tell LLVM that
joshtriplett: how do we stop doing that?
scottmcm: you use the "read unaligned" function, which tells it to be alignment 1
joshtriplett: we've already made default raw pointer reads commit to be aligned, even when it's unnecessary. when did we decide that?
nikomatsakis: we decided it pre-1.0 but in an ad-hoc way
joshtriplett: feels like there's a meaningful difference between we made this decision intentionally or this happens to be the case and we're not questioning it. I'd like to stop having that pattern
pnkfelix: I think that's an unfair characterization. I'm sure this decision was made on the basis of "Rust is going to raise the bar on how languages work"
joshtriplett: (Was going based on niko's characterization as "ad-hoc".)
nikomatsakis: I meant there wasn't an RFC, it was discussed, but prob on a GH issue.
simulacrum: matches the semantics of all pointer dereferences in rust, right? they're generally required to be aligned unless you use the intrinsic, no real distinction for raw pointers.
scottmcm: clang will also make unaligned derefs UB even if your platform supports it.
simulacrum: fwiw, I don't know about raw pointers, but for regular references LLVM uses it to SIMD optimize etc.
joshtriplett: I am on board with regular references being mandatory aligned, and I'd like to even use those for niches, just talking about raw pointers.
simulacrum: my point is that slice-iter, vector, if we wanted to go back here, we'd want to use a read-aligned intrinsic to help LLVM along. In theory it might be able to infer that the pointer originated in a reference.
scottmcm: I would say dropping to a pointer shouldn't make your performance worse.
joshtriplett: I'm hoping LLVM should be able to track where it came from. Anyway, i'm not proposing that I definitely want to change this back, I'm proposing we have historical ad-hoc things like this that the default is the status quo, even though we haven't had a language level evalution.
nikomatsakis: (5 minutes over)
scottmcm: this one is so core, this isn't some corner case that basically nobody's thought of for 2 years, this is like ralf's models of everything include this, miri has checked this for as long as miri has checked UB, etc. I don't think of this one as "oh, that's weird", this is a lots of people have seen that for many years. Some things in miri that it allowed through for a while because we weren't sure but this doesn't fall into that category.
joshtriplett: we should wrap up, but I do think we should figure out why this pattern keeps occurring.
Link: https://github.com/rust-lang/rfcs/pull/3318
Link: https://github.com/rust-lang/rust/pull/97373
MaybeUninit::uninit().assume_init()" rust#100423Link: https://github.com/rust-lang/rust/pull/100423
Link: https://github.com/rust-lang/rust/pull/102318
Link: https://github.com/rust-lang/rust/pull/103413
Link: https://github.com/rust-lang/rust/pull/103735
instruction_set MIR inline rules" rust#104121Link: https://github.com/rust-lang/rust/pull/104121
-
Any changes
Be notified of any changes
-
Mention me
Be notified of mention me
-
Unsubscribe
Subscribe