jiebi/CodeConvo huggingface dataset:
Change:
ast_map::NodeImplItem(ref item) => { match **item { ast::MethodImplItem(ref method) => { <ins> if contains_nodebug_attribute(method.attrs.as_slice()) { return FunctionDebugContext { repr: FunctionWithoutDebugInfo }; } </ins> (method.pe_ident(), method.pe_fn_decl(), method.pe_generics(),

Discussion:
Right now debuginfo can only be turned on or off globally. Sometimes it would be good to be able to exclude only specific functions from debuginfo, especially when they trigger a bug in rustc's or LLVM's debuginfo handling (e.g. ). This way, one would be able to still mostly use debuginfo in the presence of (localized) debuginfo issues.
Change:
LL | struct Foo { |        ^^^ = note: the matched value is of type `Foo` <ins> = note: `usize` does not have a fixed maximum value, so a wildcard `_` is necessary to match exhaustively = help: add `#![feature(precise_pointer_size_matching)]` to the crate attributes to enable precise `usize` matching </ins> help: ensure that all possible cases are being handled by adding a match arm with a wildcard pattern or an explicit pattern as shown | LL ~         Foo { first: false, second: Some([1, 2, 3, 4]) } => (),

Discussion:
Sorry about the long title :sweat_smile: Given the following code (): The current output is: Note how the first diagnostic, emitted when matching on a , contains additional information about why this exhaustive match does not pass the exhaustiveness check. Ideally, this information should be to the second diagnostic as well: modify labels: +A-exhaustiveness-checking +A-patterns +D-terse
Hm, even though has a different size on different architectures, should always be exhaustive, right? Then that code would be accepted, but the following would still error: We could have the error for this say "missing pattern: ", which would also work if there's a around it. That said, pretty sure what you describe also happens for enums too, and there we'll want to do what you suggest.
see also
I forgot this issue existed, but yeah this is a lint we want. I explained a bit about how this might be done in , if anyone wants to tackle this feel free to ping me
Change:
.iter_enumerated() .all(|(i, v)| v.discr == ty::VariantDiscr::Relative(i.as_u32())); <ins> let mut niche_filling_layout = None; </ins> // Niche-filling enum optimization. if !def.repr.inhibit_enum_layout_opt() && no_explicit_discriminants { let mut dataful_variant = None;

Discussion:
This prints the values in comments: Note that contains strictly more opportunities for optimization, but it's optimized worse. That's because it uses a "niche-filling" layout (using in the field of for ), but the "tag" layout wouldn't be any larger, because it has enough space in bytes to fit the (byte-sized) tag, and . uses the tagged layout since it has no other choice, and ends up with free values in the byte-sized tag, but "jumps the gun" on using a pre-existing niche.
Change:
Some(v) => v, }; <ins> let sp = sp.with_ctxt(sp.ctxt().apply_mark(cx.current_expansion.mark)); </ins> let e = match env::var(&*var.as_str()) { Err(..) => { cx.expr_path(cx.path_all(sp,

Discussion:
If any linting or suggestion is done in this case, it should suggest cc this has been in rustc forever, but clippy is only lately going crazy on it. Could this have come from your PR, too?
Hmm, shouldn't have been affected, but I'll investigate.
this is messing up clippy pretty bad. Any idea where to start looking?
So I tried to figure out what's going on, but I got lost in the code. As far as I can see it should be setting the expansion info. But it appears the passed to doesn't contain the expansion info. So maybe we need to generate a new span here with the from ?
The span passed to is the call site span, so it shouldn't contain the expansion info. The issue here is that is using the call site span directly in the expansion ( is call site span). To fix this, the macro should add expansion info to the call site span like does . Adding that line in should fix this issue. Are there other built-in macros that also have this problem in practice or is it just ?
I'd assume others have it too, but I'll check. So the passed call site span should only be used directly for error reporting, but never for creating ast items?
Right, unless you want an AST item with the raw (unexpanded) call site span -- I don't think we ever want that.
Change:
use rustc_codegen_ssa::base::maybe_create_entry_wrapper; use rustc_codegen_ssa::mono_item::MonoItemExt; use rustc_codegen_ssa::traits::DebugInfoMethods; <ins> use rustc_metadata::EncodedMetadata; </ins> use rustc_session::config::DebugInfo; use rustc_span::Symbol;

Discussion:
The following code from the manual fails with rustboot .
How embarrassing. Thanks for the report, I'll look into it.
Fix mem op= mem bug in (via not terribly good fix). Closed by .
Change:
//[opt]compile-flags: -O //[opt_with_overflow_checks]compile-flags: -C overflow-checks=on -O <del> // build-fail </del> <ins> // build-pass </ins> #![crate_type="lib"] <del> #![deny(arithmetic_overflow, const_err)] </del> <ins> #![warn(arithmetic_overflow, const_err)] </ins> #![allow(unused_variables)] #![allow(dead_code)]

Discussion:
The lint should fire on the following code, but it does not: (This testcase now exists in-tree as a FIXME in .) Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I'd like to take this. claim
I have some plans to follow-up on with some cleanup. That might at least partially resolve this issue here. So it's probably best to wait until after that is done.
All right, landed, so what I planned here is done. The remaining issue is about associated consts. The issue there is that fails, or maybe we are hitting an , but I have not tried further. The issue is all yours, :)
Great! I'll start investigating.
Never mind, that one is already fixed on beta.
got reverted in , so we have to reopen this.
Change:
[[package]] name = "pulldown-cmark" <del> version = "0.8.0" </del> <ins> version = "0.9.1" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "ffade02495f22453cd593159ea2f59827aae7f53fa8323f756799b670881dcf8" </del> <ins> checksum = "34f197a544b0c9ab3ae46c359a7ec9cbbb5c7bf97054266fecb7ead794a181d6" </ins> dependencies = [ "bitflags", "getopts",

Discussion:
Nested markdown lists as below are not rendered as nested lists, but as single-level lists. Works as expected: stable (, ) beta (, ) Produces unintended output: nightly (, ) Initially reported at foo bar baz With (with stable toolchain): ! foo + bar + baz With with nightly toolchain: !
I need to confirm if it comes from rustdoc or pulldown-cmark. I'll try to fix it in the next days.
This is a regression in pulldown-cmark, I have opened
This also affects
Thanks !
A patch release of pulldown-cmark is about to be released. Could someone open a PR to update to it?
Ok, release is out.
Just opened for it.
Marking as P-high: regression that breaks relatively simple Markdown syntax
Change:
}, } } <ins> pub mod cfgs { #[doc(cfg(all( any(not(feature = "appservice-api-c"), not(feature = "appservice-api-s")), any(not(feature = "client"), not(feature = "server")), )))] /// Some docs. pub mod cfgs {} } </ins>

Discussion:
see <img width="1728" alt="image" src=""- Arc 0.108.1 () MacOS 13.2.1 (22D68)
this seems like a rustdoc issue, cc ?
( I couldn't quickly reproduce locally yet, need to figure out the arguments first )
Yep, rustdoc issue, I'll transfer it across. This should be improved by just reducing the number of features shown here with , since a lot of them are already active for the module, but that won't help with the compression/decompression modules in the top-level list. !
Actually, rather than this made me realise there's another issue around how we deal with inlined re-exports, opened for that.
It's also kinda related to

I think long cfg expressions should be broken across multiple lines. I saw this cause issues : !
Do you have an idea on how to improve this maybe
What if we inserted zero width spaces after the keywords? So after each we insert a zero width space (see the ). Maybe we would have to wrap each name in a too but I would have to experiment a bit. Then each expression would try to stay as an inline-block and then break the line on the keywords (like , , , ...)
If we start having "groups", not sure if it'll work well. But definitely worth a try!
I started a test case with a long and complicated expression that results in this image: ! Currently combining a lot of short features is very unreadable and not's are hard to spot. With just it gets a lot more readable, but since the braces get lost in translation it is not clear which flags are binding with , or respectively. ! What if we display a little tree diagram? For most cases that would probably result in a short list with an or an in the beginning. Another idea could be to not draw the tree but to have visible boxes encasing the respective flags. What do you think?
I need to see things to be able to make my own opinion on which approach is better. :smile: But maybe has an idea?
Maybe it could show "any of"/"all of" on longer chains (say 3+)? I don't think there's a ton that can realistically be done here — a long cfg is going to result in a long doc cfg.
There are a lot of things that can be done. For example, for more than 3 items, we could show only the 3 first and show the rest on click. It's mostly about how to display things.
The original case has gotten a lot better, the actual doc string now gets ~60% of the horizontal space rather than ~30%: !
Rendering has degraded again (even though the documented cfg expressions themselves have become shorter): !
Change:
worker_id: usize, }, Done { <del> result: Result<CompiledModule, ()>, </del> <ins> result: Result<CompiledModule, Option<WorkerFatalError>>, </ins> worker_id: usize, }, CodegenDone {

Discussion:
Ok, so rustc outputting to /dev/null is a bit pathelogical but it used to not ICE the compiler. If you checkout and from dir tests/suite/futurescore run: rustc --crate-type lib -o /dev/null Then rustc is vexed: (ICEs on stable and nightly) The irony is that this is in the test suite of a rust code minimisation project.... Let me minimise the reproduction of the problem...
Thanks to rust-reduce I managed to get the repro down to: Interestingly it doesn't ICE on playground - I'm guessing playground is on linux?
Indeed
triage: P-medium, removing nomination tag, assigning self.
hmm. I nonetheless see an ICE on my own Linux machine. (There is probably some other reason the ICE does not replicate on the playpen.)
Change:
--> $DIR/intermixed-lifetime.rs:6:28 | LL | struct Foo<const N: usize, 'a, T = u32>(&'a (), T); <del> |           -----------------^^---------- help: reorder the parameters: lifetimes, then consts and types: `<'a, const N: usize, T>` </del> <ins> |           -----------------^^---------- help: reorder the parameters: lifetimes, then consts and types: `<'a, const N: usize, T = u32>` </ins> error: lifetime parameters must be declared prior to type parameters --> $DIR/intermixed-lifetime.rs:10:37 | LL | struct Bar<const N: usize, T = u32, 'a>(&'a (), T); <del> |           --------------------------^^- help: reorder the parameters: lifetimes, then consts and types: `<'a, const N: usize, T>` </del> <ins> |           --------------------------^^- help: reorder the parameters: lifetimes, then consts and types: `<'a, const N: usize, T = u32>` </ins> error: aborting due to 2 previous errors

Discussion:
results in: when it should be: This should be easy to fix: just replace in the following line with an appropriate format string. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
For the record, it's not quite this simple, as doing so results in incorrect output when the parameter also has bounds. For example, it would render as because bounds are printed after the
Change:
} pub(crate) fn universe_info(&self, universe: ty::UniverseIndex) -> UniverseInfo<'tcx> { <del> self.universe_causes[&universe].clone() </del> <ins> // Query canonicalization can create local superuniverses (for example in // `InferCtx::query_response_substitution_guess`), but they don't have an associated // `UniverseInfo` explaining why they were created. // This can cause ICEs if these causes are accessed in diagnostics, for example in issue // #114907 where this happens via liveness and dropck outlives results. // Therefore, we return a default value in case that happens, which should at worst emit a // suboptimal error, instead of the ICE. self.universe_causes.get(&universe).cloned().unwrap_or_else(|| UniverseInfo::other()) </ins> } /// Tries to find the terminator of the loop in which the region 'r' resides.

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. --Does not happen with this callback: <!-- 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. --: </p</details
The code snippet is incomplete: is there a repository available that we could try, to reproduce the error? If not, could you at least add the full function? Thanks!
Rust use tungstenite::handshake::server::{Response, ErrorResponse}; fn acceptconnection(stream: TcpStream, config: rustls::server::ServerConfig) -Result<Socket{ let mut conn = rustls::server::ServerConnection::new(std::sync::Arc::new(()))?; let tlsstream = rustls::StreamOwned::new(conn, stream.tryclone()?); if let Ok(ws) = match tungstenite::accepthdrwithconfig(tlsstream, -std::result::Result<Response, ErrorResponse{ let callback = -std::result::Result<tungstenite::handshake::server::Response, tungstenite::handshake::server::ErrorResponse{ dbg!(&req); dbg!(&res); Ok(res) }; if let Ok(ws) = match tungstenite::accepthdrwithconfig(tlsstream, callback, None) { Err(HandshakeError::Interrupted(midhandshake)) ={ info!( "Handshake interrupted with peer {} - waiting to try again.", peer_addr ); Ok(Socket::Interrupted(midhandshake)) } Err(e) ={ error!("Error accepting secure websocket connection: {e}"); Err(e)? } Ok(ws) =Ok(Socket::SecureWebSocket(ws)), } } }
This is still incomplete and doesn't parse. Do you have a repository where the issue can be reproduced?
No repo. You can make it parse pretty easily. I am not a rustc expert but I believe the issue was with the callback.
Here's a small (but not minimal yet) working repro: and with that we can finally bisect, to : probably that (no need to ping anyone here) I'll minimize next to remove this dependency and create an MCVE.
removed:
Probably not yet an MCVE and could be further simplified, but getting close.

62 error -1.63 error + ice
WG-prioritization assigning priority (). label -I-prioritize +P-medium -E-needs-mcve
Change:
return; } <ins> // FIXME(#2687)---we should be checking that the bounds of the // trait imply the bounds of the subtype, but it appears // we are...not checking this. </ins> for trait_m.tps.eachi() |i, trait_param_bounds| { // For each of the corresponding impl ty param's bounds... let impl_param_bounds = impl_m.tps[i];

Discussion:
Right now, a fn implementing an iface method must match the purity of the iface method exactly. This is too strict. We should allow a pure fn to implement an impure fn, and both pure/impure to implement an unsafe fn. UPDATE: Updated title to reflect the real problem here. There is a FIXME in the code in the relevant area. If one declares a trait like: then in the impl, the method should take one type parameter with an bound. We don't really check this correctly though. As far as I can tell, we just check that has one type parameter with one bound, but not precisely what kind of bound it is.
Similarly, in , we require that the bounds on the method parameters be precisely equivalent, which is stronger than necessary. It is sufficient (I believe) that the bounds on the trait be stronger than the bounds on the implementation.
Is this still an issue? It seems to be fixed now.
Still an issue with respect to type parameter bounds.
I don't believe this is backwards incompatible, renominating.
accepted for feature-complete milestone
The following appears to work, but I assume that this is what was talking about:
triage bump. nothing to add.
Accepted for P-backcompat-lang
Added UPDATE to main bug description above.
I had a look at this issue and tried to create a test case. does test case covers the issue you mentioned? This test case fails because it seems like the parameter types are checked in
what error does it fail with? In the you need to use a different type bound for in order to test this issue. To be more precise, the bounds of the implementation should be implied by the bounds of the trait. For example, this should fail:
thanks for the hint, I guess your updated example should indeed test this issue. I'll start working on a patch.
Change:
<ins> // check-fail struct DataWrapper<'a> { data: &'a [u8; Self::SIZE], //~ ERROR generic `Self` types are currently not permitted in anonymous constants } impl DataWrapper<'_> { const SIZE: usize = 14; } pub fn main() {} </ins>

Discussion:
Attempting to build this code generates an ICE (): The error message, on my machine: Looks like it's related to , but the construction that triggers it is different enough that it seems worth posting.
Source: <details<summaryStack trace</summary<p</p</detailsWith regression in nightly-2019-07-31 <details<summaryBisect output</summary<p</p</detailsdddb7fca09d Auto merge of - Xanewok:update-rls, r=Xanewok Auto merge of - alexcrichton:stabilize-pipelined-compilation, r=oli-obk Auto merge of - Centril:rollup-onohtqt, r=Centril
Triage: This is no longer ICE even with the feature flag:
Change:
fn resolve_regions_and_report_errors(&self, mode: RegionckMode) { self.infcx.process_registered_region_obligations( self.outlives_environment.region_bound_pairs_map(), <del> self.implicit_region_bound, </del> <ins> Some(self.tcx.lifetimes.re_root_empty), </ins> self.param_env, );

Discussion:
I tried this code: I expected to see this happen: On Rust 1.44.0, this compiles. Instead, this happened: :
For reproduction, the following is used.
This is a regression from stable to nightly.
Let’s bisect this and try to find an MCVE. ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
The code succeeds to compile on 1.44.1 and fails on 1.45, so this is actually a stable-to-stable regression.
Assigning as and removing .
So far I've reduced it to this, which depends only on (without the feature):
: searched nightlies: from nightly-2020-04-20 to nightly-2020-06-02 regressed nightly: nightly-2020-05-25 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsregressed in
The reproduction does not produce error in . However, I find this throws error on this nightly, as well as on 1.45.0. Here is an even shorter one: The line seems critical. Without this, there will be no reproduction with both snippets. This is also reproducible on the nightly .
cc
The PR that made my reduced code (without ) start successfully compiling again is , in case it helps show what's going on. <details<summaryFull bisect-rustc</summarysearched nightlies: from nightly-2020-05-25 to nightly-2020-07-17 regressed nightly: nightly-2020-06-24 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: </summary
Single-crate repro:
I can volunteer myself for looking into the issue. I have a question about the region inference.

Is there a way to visualize, or trace the region inference? Guidance and mentoring instructions are very welcome. :smile:
Change:
match *operand { Operand::Constant(..) => {} // not-a-move Operand::Consume(ref lval) => { // a move <del> self.gather_move(lval); </del> <ins> self.gather_move(lval, false); </ins> } } } <del> fn gather_move(&mut self, lval: &Lvalue<'tcx>) { </del> <ins> fn gather_move(&mut self, lval: &Lvalue<'tcx>, force: bool) { </ins> debug!("gather_move({:?}, {:?})", self.loc, lval); let tcx = self.builder.tcx; let gcx = tcx.global_tcx(); let lv_ty = lval.ty(self.builder.mir, tcx).to_ty(tcx); let erased_ty = gcx.lift(&tcx.erase_regions(&lv_ty)).unwrap(); <del> if !erased_ty.moves_by_default(gcx, self.builder.param_env, DUMMY_SP) { </del> <ins> if !force && !erased_ty.moves_by_default(gcx, self.builder.param_env, DUMMY_SP) { </ins> debug!("gather_move({:?}, {:?}) - {:?} is Copy. skipping", self.loc, lval, lv_ty); return }

Discussion:
MIR borrowck considers variables still initialized after their storage ends, so if an immutable variable is defined and used in a loop, this causes an error. e.g.: Which causes:
working on it
Change:
None => ( tcx.associated_items(did) .in_definition_order() <ins> .filter(|item| !item.is_impl_trait_in_trait()) </ins> .filter(|item| { // If this is a trait impl, filter out associated items whose corresponding item // in the associated trait is marked `doc(hidden)`.

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. --The command causes an ICE error. This happens when we use the features of () in different workspaces. workspace- : workspace- : <!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
label T-rustdoc
label -needs-triage A-cross-crate-reexports Ah lol, just noticed that we're also leaking the desugared form of RPITITs (the assoc ty) for a slightly altered non-icing version of this code (still cross-crate tho). Also needs to be addressed at some point, taking a mental note. claim
Change:
<ins> #![feature(doc_alias)] #[doc(alias = "true")] pub struct Foo; #[doc(alias = "false")] pub struct Bar; </ins>

Discussion:
I loaded the std doc at Firefox 77.0.1, then I typed fast for the word "true" (or click this link: ). I expected to see this happen: The search result appears and includes the "true" keyword link. Instead, this happened: No search result was shown. Also in the Firefox console, this was printed after typing the word "true": Version of std docs: 1.46.0-nightly ( 2020-06-21) cc in case you interest.
The type error happened along this line:
It looks like it fails when you have a crate filter selected. Almost certainly caused by (cc
yeah, that's right. I forgot about that detail.
should fix this.