jiebi/CodeConvo huggingface dataset:
Change:
<ins> #![crate_type = "lib"] pub trait Decoder { type Error; fn read_enum<T, F>(&mut self, name: &str, f: F) -> Result<T, Self::Error> where F: FnOnce(&mut Self) -> Result<T, Self::Error>; fn read_enum_variant<T, F>(&mut self, names: &[&str], f: F) -> Result<T, Self::Error> where F: FnMut(&mut Self, usize) -> Result<T, Self::Error>; } pub trait Decodable: Sized { fn decode<D: Decoder>(d: &mut D) -> Result<Self, D::Error>; } </ins>

Discussion:
In chrono we have support for behind a feature flag. As a workaround for I the line: It now gives a new error: cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The derived implementation for an enum is using . Manually implementing and using is a workaround.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
cc
I'm actually not sure this is a T-libs issue. I suspect it's related to , but I haven't had a chance to look into it yet.
I have confirmed this is an issue with the expansion of on s and aim to have a PR up tonight. As is a built-in macro, it is technically in T-compiler land, I believe. claim
PR is up, including a regression test:
Change:
impl Stdout { pub fn new() -> io::Result<Stdout> { <del> get(c::STD_OUTPUT_HANDLE).map(Stdout) </del> <ins> Ok(Stdout) </ins> } pub fn write(&self, data: &[u8]) -> io::Result<usize> { <del> write(&self.0, data) </del> <ins> write(c::STD_OUTPUT_HANDLE, data) </ins> } pub fn flush(&self) -> io::Result<()> {

Discussion:
Over time the value of may change (e.g. see ) and we should likely reload the value over time instead of caching the return value to catch cases like this.
There's very little value in caching the result. takes 3 nanoseconds for me according to a quick bench.
Change:
// This is because here `self` has a `Binder` and so does our // return value, so we are preserving the number of binding // levels. <del> ty::Binder(self.0.projection_ty.trait_ref.clone()) </del> <ins> ty::Binder(self.0.projection_ty.trait_ref) </ins> } }

Discussion:
This takes ~2 seconds to type check (according to ): Doubling (respectively, halving) the number of invocations multiplies (resp. divides) the time by 4. It applies to arithmetic in s/s too which is, I imagine, where this will occur most often in practice (it's how I found it). Observations: for , , and , annotating either side (e.g. ) or both sides makes it take only 0.03s and behave linearly (AFAICT) for and : annotating the LHS () reduces the time to ~1.5s, annotating the RHS () reduces it to ~1.1s but both are still quadratic, annotating both takes it to 0.04s and linear it seems to only be dependent on the number of operations in a single function/item, separating the 4 big chunks above across 4 functions reduces the time to ~0.5s. there's no significant difference between using the macro or writing the operations inline (I only use to allow easier experimentation) cc
This must be what's making my old macro-abusing inflate implementation take almost 300 seconds in typeck. It almost sounds like type-checking a function is quadratic over the number of inference variables. Having ran callgrind on the sample and also half of it, I'm seeing the following trace: An unrefined conclusion is that either shouldn't call or should be constant-time.
Is this the same issue as ?
I'm not too familiar with fulfill and infer, but couldn't track the latest snapshot it processed and look at the new information there?
We have exactly for this reason. It doesn't work for some reason tho.
This is the same issue as This is a different issue from (I think I will fix that one separately).
Change:
match self.by_name.find_equiv(&lint_name.as_slice()) { Some(&lint_id) => self.set_level(lint_id, (level, CommandLine)), None => { <del> match self.lint_groups.iter().map(|(&x, &(ref y, _))| (x, y.clone())) </del> <ins> match self.lint_groups.iter().map(|(&x, pair)| (x, pair.ref0().clone())) </ins> .collect::<HashMap<&'static str, Vec<LintId>>>() .find_equiv(&lint_name.as_slice()) { Some(v) => {

Discussion:
The recent attempts to improve hashmap seem to have exposed a bug in regionck where it fails to link the lifetimes of ref bindings in some situations. A mostly minimized test case is here: This test fails to compile but (I believe) should succeed. The problem is that the lifetime of the binding inside the callback from is not "linked" (in regionck terminology) to the lifetime , and hence region inference infers a lifetime for that is too small. It was not immediately obvious what the best way is to fix this -- the code around handling ref bindings seems a bit ... off in regionck, so I need to think about it some. Perturbing the code in various ways can workaround the issue, which is bad for making minimized test cases but good for landing the hasmap patch in the meantime!
I've run into (I think) another manifestation of this issue that forces the destructuring of a reference to a tuple from the arguments to the closure body: This works, but this does not
I think this is the original problem, updated to current syntax: error: Actually, maybe this should be using something other than Box... ugh old closures.
If you use a boxed closure, remember to box it: This runs on modern rustc.
Ah duh. Thanks!
Change:
<ins> extern { fn foo(...); //~^ ERROR C-variadic function must be declared with at least one named argument } fn main() {} </ins>

Discussion:
This ICEs (see title) because of the call: That's because the definition of errored in 1.34, but doesn't since 1.35: cc (found while working on )
<details<summaryBacktrace</summary</details
Ah, the problem is that this wasn't updated ( now contains a ): Thankfully, at the same time, the ICE was , so calls wouldn't have been possible to such functions.
Good catch
Change:
<ins> error: usage of `core::arch::global_asm` --> $DIR/lint-global-asm-as-unsafe.rs:17:1 | LL | global_asm!(""); | ^^^^^^^^^^^^^^^ | = note: using this macro is unsafe even though it does not need an `unsafe` block note: the lint level is defined here --> $DIR/lint-global-asm-as-unsafe.rs:2:9 | LL | #![deny(unsafe_code)] |         ^^^^^^^^^^^ error: usage of `core::arch::global_asm` --> $DIR/lint-global-asm-as-unsafe.rs:13:9 | LL |         global_asm!(""); |         ^^^^^^^^^^^^^^^ ... LL | unsafe_in_macro!(); | ------------------ in this macro invocation | = note: using this macro is unsafe even though it does not need an `unsafe` block = note: this error originates in the macro `unsafe_in_macro` (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to 2 previous errors </ins>

Discussion:
Similar to how deny(unsafecode) prevents from being used, it should also prevent blocks from being allowed. If misused, they can do any number of strange and horrible thing simply by being within the crate. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
label +C-bug +T-compiler
I suppose it's probably too late to actually make it require ?
that isn't even currently possible from a syntax perspective because blocks only work as expressions, you can't just put them around a top level item. It would take a whole RFC thing, even separately from global_asm already being stable.
Change:
let move_local = Local { pat: P(Pat { id, <del> node: PatKind::Ident( BindingMode::ByValue(Mutability::Immutable), ident, None, ), </del> <ins> node: PatKind::Ident(binding_mode, ident, None), </ins> span, }), // We explicitly do not specify the type for this statement. When the user's

Discussion:
Code: Error: Rustc version: rustc 1.36.0-nightly ( 2019-05-02)
modify labels: A-async-await and T-compiler.
I wonder if this is related to the drop order fix desugaring?
Oops, looks like it is. Thanks for the fix.
Change:
)); let arms = hir_vec![pat_arm, break_arm]; <del> P(self.expr( head_sp, hir::ExprKind::Match( next_expr, arms, hir::MatchSource::ForLoopDesugar ), ThinVec::new(), )) </del> <ins> self.expr_match(head_sp, next_expr, arms, hir::MatchSource::ForLoopDesugar) </ins> }; <del> let match_stmt = self.stmt(head_sp, hir::StmtKind::Expr(match_expr)); </del> <ins> let match_stmt = self.stmt_expr(head_sp, match_expr); </ins> let next_expr = P(self.expr_ident(head_sp, next_ident, next_pat_hid));

Discussion:
See:
for future reference: is referencing my PR which changed the r-value temporary rules with respect to the temporaries in the of
Even beside the part the loop desugaring is so complex. It would be nice to document what every employed trick changes compared to the naive desugaring.
PR itself was motivated (or at least spawned off of) PR . I'm actually trying to find out what the actual motivation for the described change was. The change, as described, was that the temporaries within would previously live until the end of the enclosing block. So if you consider the following code (): which, when it is accepted by the compiler (as written it requires NLL), it should print this: notably, we drop all of {, , } immediately after the for-statement, but before the at the end of the block. The breakage I would be concerned about, if we made for-loops no longer a terminating scope for their , is that all of the temps would live until the end of the block, and thus the drops of {, , } would happen after the "end of enclosing block", which would be an observable change. has relayed to me in private conversation that they tried examples like this under variants of their desugaring and did not witness any change in behavior. Our best guess as to why this is, is because the desugaring is, in the end, turning into a which is itself a terminating scope for the temporaries in the -input, and so you don't need to recreate such an effect by other means.
Note: it is nonetheless possible that the distinction here is more subtle and my above example isn't quite right. in particular, I'm a little worried that there may have been a reason that the example from PR puts the for-expression in the tail expression of a block, and that examples that don't take similar care might fail to pick up on a relevant distinction here...
Change:
/// Returns `Some(t)` where `t` is the time `self + duration` if `t` can be represented as /// `Instant` (which means it's inside the bounds of the underlying data structure), `None` /// otherwise. <del> #[unstable(feature = "time_checked_add", issue = "55940")] </del> <ins> #[stable(feature = "time_checked_add", since = "1.34.0")] </ins> pub fn checked_add(&self, duration: Duration) -> Option<Instant> { <del> self.0.checked_add_duration(&duration).map(|t| Instant(t)) </del> <ins> self.0.checked_add_duration(&duration).map(Instant) </ins> } /// Returns `Some(t)` where `t` is the time `self - duration` if `t` can be represented as /// `Instant` (which means it's inside the bounds of the underlying data structure), `None` /// otherwise. <del> #[unstable(feature = "time_checked_add", issue = "55940")] </del> <ins> #[stable(feature = "time_checked_add", since = "1.34.0")] </ins> pub fn checked_sub(&self, duration: Duration) -> Option<Instant> { <del> self.0.checked_sub_duration(&duration).map(|t| Instant(t)) </del> <ins> self.0.checked_sub_duration(&duration).map(Instant) </ins> } }

Discussion:
This is a tracking issue for PR . This feature adds a function to and as a prerequisite also for all platform specific time structs. This also led to the refactoring of many functions to avoid redundancy (they now unwrap the result of ).
This should be to as well. We're seeing some need for this in to handle wait timeouts.
I pushed a PR () for adding the same functionality to under the same feature gate name. I hope this is fine. They seem extremely related (and share a lot of the implementation) and the feature name fits both.
This has now been extended so the feature covers both and on both and . Together with the fact that already have these, it's now possible to handle all time types without risking panics on nightly (whenever the next nightly comes out).
Covered by this feature: Looks good to me. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [ ] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), 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 for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
Why no ?
The final comment period, with a disposition to merge, as per the , is now complete.
Implemented :
Could we not keep that as a separate feature? As to not slow this one down. No one reported they might have any need for when we developed and .
OK, renaming the feature in the pull request.
Change:
const NANOS_PER_SEC: u32 = 1_000_000_000; const NANOS_PER_MILLI: u32 = 1_000_000; <ins> const NANOS_PER_MICRO: u32 = 1_000; </ins> const MILLIS_PER_SEC: u64 = 1_000; <ins> const MICROS_PER_SEC: u64 = 1_000_000; </ins> /// A `Duration` type to represent a span of time, typically used for system /// timeouts.

Discussion:
During the write of an embedded library I needed to make a pause of 10 microseconds. Looking over the I understood that I had to use the following construction: The sad part is that this is less clear to me than . Currently the and functions are implemented but not which could help write cleaner code IMO. The fix seems pretty easy, maybe if you judge this useful I can try to write my first pull request to the Rust project!
In general, this is how works; small additions can just be a PR, larger additions need an RFC. So, I'd suggest that you send in a PR implementing this.
Adding sounds okay to me.
Yeah, I'd be on board with a PR.
This is now a tracking issue for the function in the previously referenced PR.
Looks good to me to stabilize. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), 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 for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
Change:
<ins> error: `impl` item signature doesn't match `trait` item signature --> $DIR/issue-75361-mismatched-impl.rs:18:3 | LL |   fn adjacent_edges(&self) -> Box<dyn MyTrait<Item = &Self::EdgeType>>; |   --------------------------------------------------------------------- expected `fn(&T) -> std::boxed::Box<(dyn MyTrait<Item = &_> + 'static)>` ... LL |   fn adjacent_edges(&self) -> Box<dyn MyTrait<Item = &Self::EdgeType> + '_> { |   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ found `fn(&T) -> std::boxed::Box<dyn MyTrait<Item = &_>>` | = note: expected `fn(&T) -> std::boxed::Box<(dyn MyTrait<Item = &T> + 'static)>` found `fn(&T) -> std::boxed::Box<dyn MyTrait<Item = &T>>` help: the lifetime requirements from the `impl` do not correspond to the requirements in the `trait` --> $DIR/issue-75361-mismatched-impl.rs:12:55 | LL |   fn adjacent_edges(&self) -> Box<dyn MyTrait<Item = &Self::EdgeType>>; |                                                       ^^^^^^^^^^^^^^ consider borrowing this type parameter in the trait error: aborting due to previous error </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --(I know this is probably incorrect code, but this is what triggered the internal compiler error). <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Assigning as and removing .
44 doesn't have the ICE.
shows that this can result in no user-facing error message. I suggest increasing priority to .
Change:
} TokenTree::Token(_, token::SpecialVarNt(..)) => 2, TokenTree::Token(_, token::MatchNt(..)) => 3, <ins> TokenTree::Token(_, token::Interpolated(Nonterminal::NtTT(..))) => 1, </ins> TokenTree::Delimited(_, ref delimed) => delimed.tts.len() + 2, TokenTree::Sequence(_, ref seq) => seq.tts.len(), TokenTree::Token(..) => 0,

Discussion:
See discussion on .
The ability to convert token-trees AST is also needed to
Do we need that ability here? It's only about interpolated matches.
Fixed in .
Change:
} TokenTree::Token(_, token::SpecialVarNt(..)) => 2, TokenTree::Token(_, token::MatchNt(..)) => 3, <ins> TokenTree::Token(_, token::Interpolated(Nonterminal::NtTT(..))) => 1, </ins> TokenTree::Delimited(_, ref delimed) => delimed.tts.len() + 2, TokenTree::Sequence(_, ref seq) => seq.tts.len(), TokenTree::Token(..) => 0,

Discussion:
I haven't finished investigating this, so I'm making an issue just so I don't forget it:
Actually, I'm really not sure this should work. I'm nominating this for well-defined.
Actually... this definitely shouldn't work in our current system. The basic issue is that a lonely sigil is not a complete "thing". The "tt" macro option is only intended for macros that expand into macro invocations. There are a number of ways around this; at the most basic level, you can insist that the user provide the sigil and the thing it's attached to. This works, but it may be unsatisfying if you want the sigil to be attached to names that are introduced by the macro. In this case, you have a couple of choices. use an unhygienic macro (and tell everyone what name you want to attach to the sigil, ugh) explicitly have three different versions of the macro, one for each sigil (bleah) clean up the second option by nesting one macro definition inside another one make sigils expand into macro invocations. Anyhow, I would say that as of right now, at least, this is not a bug. I'm going to leave this as nominated mostly because this came up in Vancouver as something that Graydon and I both expected to work.
Visiting for triage: still doesn't work, nothing more to add.
accepted for well-defined milestone
You can work around this by using a dummy macro so that you can pass the directly to it, e.g. for the example in the issue:
reading this workaround makes me feel like our macro system is really broken :(.
/cc
The modernized example gives me which looks like .
notes that another hacky work-around is a nested macro invocation, which avoids needing to define/export dummy macros (although one will want to be careful about giving that internal macro a fairly unique name to avoid trampling on any other macros in scope, unfortunately :disappointed: ).
Updated example: error:
Triage: This is an ancient P-low bug but per it actually comes up in the wild a lot - macro writers have to know how to do this workaround. Can this be escalated? Is there a solution somebody could mentor?
Discussed at lang meeting, we believe this should remain p-low since we don't know a very easy fix.

It should be fixed by converting macro_rules to expand to pure tokens then parsing, rather than mixing the two steps (which we hop would be back-compat). cc
Fixed in .
Change:
if let Some(def_id) = self.typeck_results().type_dependent_def_id(id) { self.check_def_id(def_id); } else { <del> bug!("no type-dependent def for method"); </del> <ins> assert!( self.typeck_results().tainted_by_errors.is_some(), "no type-dependent def for method" ); </ins> } }

Discussion:
File: auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
Regression in nightly-2023-06-02 Regression in cc
Change:
<ins> error[E0267]: `break` inside of a closure --> $DIR/issue-66702-break-outside-loop-val.rs:5:12 | LL |         || break 'some_label (); |         -- ^^^^^^^^^^^^^^^^^^^^ cannot `break` inside of a closure |         | |         enclosing closure error: aborting due to previous error For more information about this error, try `rustc --explain E0267`. </ins>

Discussion:
The following code ICE's on stable, beta and nightly: <details<summaryBacktrace:</summary</details
reduced
This is not an bug, here's another reproducer for the same bug: EDIT: Fix coming ...
A closure is just enough: modify labels: -A-async-await +A-closures
Change:
| = help: normalized in stderr note: required by a bound in `DiagnosticBuilder::<'a, G>::set_arg` <del> --> $COMPILER_DIR/rustc_errors/src/diagnostic_builder.rs:538:19 </del> <ins> --> $COMPILER_DIR/rustc_errors/src/diagnostic_builder.rs:539:19 </ins> | LL |         arg: impl IntoDiagnosticArg, |                   ^^^^^^^^^^^^^^^^^ required by this bound in `DiagnosticBuilder::<'a, G>::set_arg`

Discussion:
Gives (rustc 1.60.0-nightly 2022-01-30): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim
Change:
* ``` */ #[lang="index_mut"] <del> pub trait IndexMut<Index, Result> { </del> <ins> pub trait IndexMut<Index, Result> for Sized? { </ins> /// The method for the indexing (`Foo[Bar]`) operation fn index_mut<'a>(&'a mut self, index: &Index) -> &'a mut Result; }

Discussion:
As titled. Although slices support the operator, it does not implement , so one cannot pass in a slice in the following example:
I'm somewhat inclined to think we could just remove the built-in indexing from entirely and thus remove/reduce the need for the special lang-items, although there's at least three considerations: the failure message for out-of-bounds indexing would be less informative (no file/line information), but debugging any other (e.g. ) already requires a debugger to get this info, so maybe it's not so bad. can't yet implement properly, so this would still need built-in support with (and thus the out-of-bounds failure lang items can't be entirely removed just yet), unless implicit coercions will work. needs to be fixed before will work properly (and I guess DST would make it work more nicely). Users would theoretically not see a change, since this would all happen inside (and ).
It's not possible due to lack of CTFE.
cc me
Should I send a PR implementing / for now, and we can evaluate later removing the built-in indexing? I already tested that PR, and the built-in indexing is preferred in the operation , but one go through the trait using .
Yes, please go ahead and do so. Thanks!