jiebi/CodeConvo huggingface dataset:
Change:
}; // `tcx.normalize_projection_ty` may normalize to a type that still has // unevaluated consts, so keep normalizing here if that's the case. <del> if res != ty && res.has_type_flags(ty::TypeFlags::HAS_CT_PROJECTION) { res.try_super_fold_with(self)? </del> <ins> // Similarly, `tcx.normalize_weak_ty` will only unwrap one layer of type // and we need to continue folding it to reveal the TAIT behind it. if res != ty && (res.has_type_flags(ty::TypeFlags::HAS_CT_PROJECTION) || kind == ty::Weak) { res.try_fold_with(self)? </ins> } else { res }

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. --<!-- 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
cc
Change:
## Markdown <del> `rustdoc` uses the [CommonMark markdown specification]. You might be interested into taking a look at their website to see what's possible to do. - [commonmark quick reference] </del> <ins> `rustdoc` uses the [CommonMark Markdown specification]. You might be interested in taking a look at their website to see what's possible: - [CommonMark quick reference] </ins> - [current spec] In addition to the standard CommonMark syntax, `rustdoc` supports several

Discussion:
Split off from . modify labels: T-rustdoc C-enhancement <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Uh, it looks like rustbot is editing my message and adding weird comments:
Cc
It looks like smart punctuation doesn't work in headers: ! wasn't able to reproduce this in pulldown itself; I'm guessing rustdoc is doing something special with headers. Cc
Triagebot does that as a way of easily storing data per-issue (we could do it in the database now, we didn't have one back then). But it's expected and shouldn't really be a problem.
Is this a good thing? Wouldn't keeping things as it is is better?
I think if you want to argue against doing this, giving reasons would be helpful. I personally think given that we already use emoji and otherwise non-ASCII characters readily, it should be reasonable for us to generate smart quotes as well.
I do think emoji and other non-ASCII characters if specified would be good except for smart quote. It's like saying to use greek question mark which is the same as semi-colon when a semi-colon was seen in documentation to make it look a bit cooler. One thing is copying, when others are copying the text, it will copy the utf-8 version of smart quotes which when displayed in terminals which in turn will make it look ugly and hard for text processing. Auto changing text to emoji I am okay with that. But not automatically changing single quotes, double quotes and semi-colons. Personally I don't see much benefit to that, usually if users want it they would specifically type it out but otherwise it would be similar. In my humble opinion, looks wise the smart quotes are more ugly, but easier to distinguish opening and closing quotes, but still when copied and pasted it may not look so good.
Change:
} fn span_to_string(&self, sp: Span, prefer_local: bool) -> String { <del> if self.files.borrow().source_files.is_empty() && sp.is_dummy() { </del> <ins> if self.files.borrow().source_files.is_empty() || sp.is_dummy() { </ins> return "no-location".to_string(); }

Discussion:
Sysroot has been compiled using to get set. Otherwise it is hard to guess a defid with encoded mir, now it is just taking the first exported symbol from:
I used to read the mir.
I think these are and printed as . If so it would be less confusing if the debug impl of would say or something like that instead.
I'm unsure how to reproduce the environment to reproduce this bug. It's easy to adjust the debug printing for , but without a test for that I'm not sure how to test it
Change:
args: Vec<OsString>, env: Option<HashMap<OsString, OsString>>, cwd: Option<OsString>, <ins> flags: u32, </ins> detach: bool, // not currently exposed in std::process stdin: Option<Stdio>, stdout: Option<Stdio>,

Discussion:
Now a tracking issue for on Windows. Open questions: Should we provide a method of adding* flags as opposed to setting them entirely? Would be a bit more composition-friendly. Also, don't forget to add to the prelude when stabilizing! There's a currently-unused codepath in the Windows implementation of that can set : It looks like historically there was a method to set this but it got removed. Unfortunately there's currently no way to set this, and no other way to set the flags, so for a project I'm working on I basically had to reimplement for Windows: I think we need some way to set this, even if it's Windows-specific. There are a bunch of other flags that can be specified, so maybe a way to set arbitrary flags would be useful? (v=vs.85).aspx I think this would fit nicely onto a Windows equivalent of the  trait, maybe something like:
Seems reasonable to me!
I'm always in favor of adding more Windows specific extension traits to expose useful functionality that other platforms don't seem to have.
I have a patch, it just took me a while to write a test for it. I'm trying to sort out the stability annotations for the new APIs--can I just use this issue as the tracking issue for the new feature?
Sure!
To the open question: I had first written the API as originally proposed: with a method to set the flags directly. Then I thought that might make it difficult if callers wanted to set different flags in different places, so I split it into and methods, but Alex asked me to change it back. I'm not sure it's that important, I don't think there are that many process creation flags that it would be useful to set from a library context, and callers can always aggregate flags into a u32 and just call with that value.
fcp merge With the one remaining open question I think it's safe to stabilize as this is still consistent with our approach to custom flags in other areas of platform-specific extensions as well.
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 these reviewers reach consensus, 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: psst I wasn't able to add the label, please do so.
Change:
}; let mut explicit_reg = false; <del> let op = if p.eat(&token::Ident(kw::In, false)) { </del> <ins> let op = if p.eat_keyword(kw::In) { </ins> let reg = parse_reg(&mut p, &mut explicit_reg)?; let expr = p.parse_expr()?; ast::InlineAsmOperand::In { reg, expr } <del> } else if p.eat(&token::Ident(sym::out, false)) { </del> <ins> } else if p.eat_keyword(sym::out) { </ins> let reg = parse_reg(&mut p, &mut explicit_reg)?; let expr = if p.eat_keyword(kw::Underscore) { None } else { Some(p.parse_expr()?) }; ast::InlineAsmOperand::Out { reg, expr, late: false } <del> } else if p.eat(&token::Ident(sym::lateout, false)) { </del> <ins> } else if p.eat_keyword(sym::lateout) { </ins> let reg = parse_reg(&mut p, &mut explicit_reg)?; let expr = if p.eat_keyword(kw::Underscore) { None } else { Some(p.parse_expr()?) }; ast::InlineAsmOperand::Out { reg, expr, late: true } <del> } else if p.eat(&token::Ident(sym::inout, false)) { </del> <ins> } else if p.eat_keyword(sym::inout) { </ins> let reg = parse_reg(&mut p, &mut explicit_reg)?; let expr = p.parse_expr()?; if p.eat(&token::FatArrow) {

Discussion:
The : pointed me to -- cc I see that there were regressions with during that review, but not exactly like what I'm seeing here. searched nightlies: from nightly-2020-09-28 to nightly-2020-10-04 regressed nightly: nightly-2020-09-30 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details
It's probably relevant that the actual token is passed as an arch-conditional parameter here:
Yes, I've missed this case, sorry. Will fix soon.
Fixed in
Works for me, thanks!
Change:
let next_expr = match snapshot.parse_expr() { Ok(next_expr) => next_expr, Err(inner_err) => { <del> err.cancel(); </del> inner_err.cancel(); <del> return self.dcx().span_delayed_bug(expr.span, "not a tail expression"); </del> <ins> return err.emit(); </ins> } }; // We have for sure

Discussion:
<!-- [31mICE[0m: Rustc '--crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: not a tail expression', 'error: internal compiler error: not a tail expression' 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<!-- query stack: --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It seems the pops up since cc The code starts ICEing in general since cc
claim
Change:
<ins> error[E0276]: impl has stricter requirements than trait --> $DIR/bad-item-bound-within-rpitit.rs:16:13 | LL |     type Item<'a> |     ------------- definition of `Item` from trait ... LL |         'b: 'a; |             ^^ impl has extra requirement `'b: 'a` | help: copy the `where` clause predicates from the trait | LL |     where Self: 'b; |     ~~~~~~~~~~~~~~ error[E0477]: the type `&'a I` does not fulfill the required lifetime --> $DIR/bad-item-bound-within-rpitit.rs:19:23 | LL |     fn iter(&self) -> impl 'a + Iterator<Item = I::Item<'a>> { |                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | note: type must outlive the anonymous lifetime as defined here --> $DIR/bad-item-bound-within-rpitit.rs:10:28 | LL |     fn iter(&self) -> impl '_ + Iterator<Item = Self::Item<'_>>; |                            ^^ error: aborting due to 2 previous errors Some errors have detailed explanations: E0276, E0477. For more information about an error, try `rustc --explain E0276`. </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. --<!-- 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
This needs detailed investigation, and I'd prefer we fully understand why this is resulting in a region error over just adding an check to (or feeding the query).... This probably has to do with the fact that we have a due to the missing region .
Change:
// Only allow statics (not consts) to refer to other statics. if self.mode == Mode::Static || self.mode == Mode::StaticMut { <del> if context.is_mutating_use() { </del> <ins> if self.mode == Mode::Static && context.is_mutating_use() { </ins> // this is not strictly necessary as miri will also bail out // For interior mutability we can't really catch this statically as that // goes through raw pointers and intermediate temporaries, so miri has

Discussion:
https://crater-
cc Repro I'm going to fix the regression, but I just want to note that is very dangerous to use. This looks like another argument for
FWIW the code in question is some mechanically translated C with the translation performed by . I have pretty much abandoned that project.
triage: P-high.
Change:
<ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn illegal_cast<U:?Sized,V:?Sized>(u: *const U) -> *const V { u as *const V } fn illegal_cast_2<U:?Sized>(u: *const U) -> *const str { u as *const str } trait Foo { fn foo(&self) {} } impl<T> Foo for T {} trait Bar { fn foo(&self) {} } impl<T> Bar for T {} enum E { A, B } fn main() { let f: f32 = 1.2; let v = 0 as *const u8; let fat_v : *const [u8] = unsafe { &*(0 as *const [u8; 1])}; let fat_sv : *const [i8] = unsafe { &*(0 as *const [i8; 1])}; let foo: &Foo = &f; let _ = v as &u8; let _ = v as E; let _ = v as fn(); let _ = v as (u32,); let _ = Some(&v) as *const u8; let _ = v as f32; let _ = main as f64; let _ = &v as usize; let _ = f as *const u8; let _ = 3_i32 as bool; let _ = E::A as bool; let _ = 0x61u32 as char; let _ = false as f32; let _ = E::A as f32; let _ = 'a' as f32; let _ = false as *const u8; let _ = E::A as *const u8; let _ = 'a' as *const u8; let _ = 42usize as *const [u8]; let _ = v as *const [u8]; let _ = fat_v as *const Foo; let _ = foo as *const str; let _ = foo as *mut str; let _ = main as *mut str; let _ = &f as *mut f32; let _ = &f as *const f64; let _ = fat_sv as usize; let a : *const str = "hello"; let _ = a as *const Foo; // check no error cascade let _ = main.f as *const u32; let cf: *const Foo = &0; let _ = cf as *const [u16]; let _ = cf as *const Bar; vec![0.0].iter().map(|s| s as f32).collect::<Vec<f32>>(); } </ins>

Discussion:
When working on PR , I ended up with the following output: The second span label points at the first character of the span, but because there's already a larger span there, the actual extent of that span is lost. I believe that either the shortest span should be shown within the existing span: there should be a new character introduced for when multiple labels overlap: or at the very least, colorize the smaller span with the secondary label's color:
Will be fixed when PR gets merged.
Change:
/// fat pointers if their unsize-infos have the same kind. #[derive(Copy, Clone, PartialEq, Eq)] enum UnsizeKind<'tcx> { <del> Vtable, </del> <ins> Vtable(ast::DefId), </ins> Length, /// The unsize info of this projection OfProjection(&'tcx ty::ProjectionTy<'tcx>),

Discussion:
Much of the implementation work for rust-lang/rfcs has been done, but there remain some corner cases to fix: [ ] Casts between raw pointers to different traits are accepted but should not be (e.g. ) [ ] Double-check other cases, ensure adequate tests exist
triage: P-high -- I'm giving this high priority since accepting casts that we ought not to is a backwards compatibility risk, though it is mitigated by the fact that afaik the illegal casts yield an ICE (but I haven't done exhaustive testing)
The newly-illegal casts shouldn't be ICE-s (I mean, on nightly). Casts on stable are just randomly ICE-ey.
Change:
} } <ins> /// Updates the given submodule only if it's initialized already; nothing happens otherwise. pub fn update_existing_submodule(&self, submodule: &Path) { // Avoid running git when there isn't a git checkout. if !self.config.submodules(self.rust_info()) { return; } if GitInfo::new(false, submodule).is_managed_git_subrepository() { self.update_submodule(submodule); } } </ins> /// Executes the entire build, as configured by the flags and configuration. pub fn build(&mut self) { unsafe {

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: in is not specified explicitly, the default value is used. I expected to see this happen: LLVM is downloaded from CI, when LLVM version is bumped the new LLVM is downloaded from CI as well. Instead, this happened: LLVM starts building from source code after an LLVM update, instead of being downloaded, unless I remove the build directory and do a fresh build, then it starts downloading from CI again. <!-- 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. --:
Or maybe it's a stage0 toolchain update that triggers this issue, not LLVM update (I observed this today). But I've seen this issue several times in the past as well. cc
The section in is completely empty, nothing is overridden.
Update: LLVM is built from source only on the first build attempt, after that it is correctly downloaded from CI.
This is still an issue that I observe regularly.
There were some issues with the change detection logic for LLVM and I think should fix it. Let's see if it still happens with the next LLVM update.
Change:
} else { for &quote in quotes.iter() { if id == self.sess.ident_of(quote) { <del> self.gate_feature(quote, path.span, quote + msg); </del> <ins> self.gate_feature("quote", path.span, quote + msg); </ins> } } }

Discussion:
These all are only useful in the compiler, aren't hygienic, etc. Nominating.
What hygiene issues do they still have? The hygiene issue I'm aware of was fixed by . They'll be very useful for externally defined syntax extensions. I'm okay with feature gating it though.
The only thing I recall is that they require an to be in scope. Perhaps that's not technically a hygiene problem.
Accepted for 1.0, P-backcompat-lang.
I would like to look at this, but I am not familiar to quasi-quoting. Can you list some quasi-quoting macros, or point out the directory of the source tree to look up? What I have found related to quasi-quoting lies on .
All of the quasi-quoting macros live there.
Their .
Change:
None } <del> #[instrument(level = "trace", skip(self, cost))] </del> <ins> #[instrument(level = "trace", skip(self, state, cost))] </ins> fn recurse_through_terminator( &mut self, bb: BasicBlock, <del> state: &State<ConditionSet<'a>>, </del> <ins> // Pass a closure that may clone the state, as we don't want to do it each time. state: impl FnOnce() -> State<ConditionSet<'a>>, </ins> cost: &CostChecker<'_, 'tcx>, depth: usize, ) {

Discussion:
File: season two 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
cc
I cannot reproduce the original anymore, but does reproduce. The body is impossible because of the where clauses, so no MIR opts should ever run on it... I'll take a look.
I can still reproduce this with the original mvce when I use the flags that I listed.
bisected with searched nightlies: from nightly-2023-09-01 to nightly-2023-10-01 regressed nightly: nightly-2023-09-09 searched commit range: regressed commit: bisected with <a href=''cargo-bisect-rustc</av0.6.8 cc oli was right:
The bisection here isn't useful sadly, but thank you anyways. I took a look and yeah, the issue is what I suspected. () checks whether there are any impossible predicates (like here). It sadly has to filter out "non-global" predicates, which belongs to. It has to do this because of overflows as mentioned above. told me that the new trait solvers non-fatal handling of overflow will allow this to be fixed. But until then, there's nothing we can do. As for getting the code working, the solution here so to avoid these impossible bounds wherever possible. In the example here, that's easy to do, just delete it. In that's a bit more annoying, I don't really see a solution. We could try playing whack-a-mole by trying to make the MIR opts sorta-handle these cases that slip through, but I don't think that's very sustainable. Might work at least for the trivial cases like though, but I don't open PRs for that.
another one
I'm afraid that this has reached stable with 1.78. I couldn't reproduce it with the minimal example in the previous comment, but a crate of mine now fails on stable, but compiled fine on 1.77.2: <details<summaryfull output</summary</detailsThe code responsible for this is fairly simple: Removing that impl makes the crate compile again.

Will we still just wait for the new solver, now that it's a stable-stable regression?
I managed to minimize the example from : (, ICE in release mode)
Change:
<del> error[E0277]: the trait bound `(): std::convert::From<std::option::NoneError>` is not satisfied --> $DIR/try-on-option.rs:7:5 </del> <ins> error[E0277]: `?` couldn't convert the error to `()` --> $DIR/try-on-option.rs:7:6 </ins> | LL |     x?; <del> |     ^^ the trait `std::convert::From<std::option::NoneError>` is not implemented for `()` </del> <ins> |      ^ the trait `std::convert::From<std::option::NoneError>` is not implemented for `()` </ins> | = note: required by `std::convert::From::from`

Discussion:
Currently E277's message is confusing and seemingly ambiguous when it occurs on a try () expression (this may not be limited to E277, it's just the one I noticed). For example, in : The problem is that 's error type is while 's error type is . In this case the error isn't too confusing, but if the try is in a chained expression () and you're a noob it isn't clear why it wants implemented on . It doesn't necessarily even require a whole fix suggestion, all it would take is making the error only highlight the , as the issue is actually occuring when unwrapping the result. Thanks!
Change:
<ins> // edition:2018 // check-pass #![allow(unused)] #![deny(future_prelude_collision)] struct S; impl S { fn try_into(self) -> S { S } } // See https://github.com/rust-lang/rust/issues/86633 fn main() { let s = S; let s2 = s.try_into(); } </ins>

Discussion:
I tried this code: I expected to see this happen: No warning Instead, this happened: Got the warning: AFAIK, this should not be ambiguous, since it is an inherent method, which should take priority over the TryInto trait. Also, the suggestion doesn't make much sense, since it just surrounds the variable with parenthesis, which have no effect (and indeed, can be removed even on 2021). cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
I'll look into it, in some cases inherent methods do collide but this is definitely a false positive, might just be checking the number of derefs.
claim
label +A-diagnostics +A-edition-2021 +D-incorrect +T-compiler