jiebi/CodeConvo huggingface dataset:
Change:
} fn visit_item(&mut self, i: &'tcx hir::Item<'tcx>) { <del> if self.visit_item_inner(i, None, None) { walk_item(self, i); } </del> <ins> self.visit_item_inner(i, None, None); let new_value = if self.is_importable_from_parent { matches!( i.kind, hir::ItemKind::Mod(..) | hir::ItemKind::ForeignMod { .. } | hir::ItemKind::Impl(..) | hir::ItemKind::Trait(..) ) } else { // Whatever the context, if it's an impl block, the items inside it can be used so they // should be visible. matches!(i.kind, hir::ItemKind::Impl(..)) }; let prev = mem::replace(&mut self.is_importable_from_parent, new_value); walk_item(self, i); self.is_importable_from_parent = prev; </ins> } fn visit_mod(&mut self, _: &hir::Mod<'tcx>, _: Span, _: hir::HirId) {

Discussion:
If we run with the option on this code: Both and are documented, but not being accessible outside of , it shouldn't be documented.
probably knows this, but for others seeing this issue, I think it's probably due to (which was reverted in , and later re-applied in ). It has to do with the fact that we're using a HIR visitor now, so we're visiting nested items unconditionally.
Yes I know where it's coming from. :smile: I was just thinking today that since we were going through the whole HIR without checking whether or not we were in a block, all elements inside the block could be visible. Tested and... :fearful: Should be pretty easy to fix.
For reference, I put up because this was causing documentation to become really verbose with serde + . If you fix this such that we no longer document those items, we could probably revert that PR.
Indeed. Don't hesitate to come to me if you have such issues with rustdoc. Such problems should definitely not go unnoticed.
The thing is, it was not particularly clear from the PRs whether this was intentional or not.
Unfortunately it wasn't. The goal was to retrieve the missing impl blocks. But if anything isn't clear, don't hesitate to ask too. :wink:
Change:
} } } <del> if let RegionResolutionError::ConcreteFailure(origin, _, _) = error.clone() { </del> <ins> if let RegionResolutionError::ConcreteFailure(origin, _, _) | RegionResolutionError::GenericBoundFailure(origin, _, _) = error.clone() { </ins> if let SubregionOrigin::CompareImplTypeObligation { span, item_name,

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 I expected to see this happen: A slightly better error message Instead, this happened: A slightly confusing error message <!-- 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<summaryBacktrace</summary<p</p</details
Change:
Some((lineno, line)) => { let line = line.trim(); if let Some(text) = line.strip_prefix("/// ") { <del> doc_lines.push(text.trim().to_string()); } else if line.starts_with("///") { </del> <ins> doc_lines.push(text.to_string()); } else if line == "///" { </ins> doc_lines.push("".to_string()); } else if line.starts_with("// ") { // Ignore comments.

Discussion:
It used to (on stable and beta) look like this: ! But on nightly it looks like: ! The source code for the snippet is: rust /// if let _ = 123 { /// println!("always runs!"); /// } /// `` This is true for other code snippets in the lint listing, though the rest of the book (and other books) don't have the issue.
cc since you're the only one who's since September
Assigning and removing as in the prioritization working group.
Change:
} else { err.span_suggestion(sp, &msg, suggestion, applicability); } <ins> } else if self.suggest_else_fn_with_closure(err, expr, found, expected) { </ins> } else if self.suggest_fn_call(err, expr, found, |output| self.can_coerce(output, expected)) && let ty::FnDef(def_id, ..) = &found.kind() && let Some(sp) = self.tcx.hir().span_if_local(*def_id)

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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --should suggest if the argument is a closure instead of suggesting to call the closure Given the following code: <!-- Please provide a link to -- The current output is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This probably can be generalized if the code is written carefully enough.
Do you mean, we should handle other types like which may use with a closure?
I know nothing about the internals of rustc diagnostics but a general way would be to check if a similar method in name accepts a closure and suggest that first, if nothing similar can be found then suggest calling the closure
I mean something more like what is suggesting, where you check if exists whose signature is compatible with a closure. But that requires doing a method probe, then doing some delicate logic to check argument compatibility.
Change:
!is_zst }); if let Some(field) = field { <del> let ty0 = tcx.type_of(field.did); </del> <ins> let ty0 = tcx.bound_type_of(field.did).subst(tcx, substs); </ins> // Generalize any repr(transparent) user-defined type that is either a pointer // or reference, and either references itself or any other type that contains or // references itself, to avoid a reference cycle.

Discussion:
I've got a fix for this that I'll be uploading in a minute or two, I'm filing the issue to claim an issue number for the test. : </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This seems to be a duplicate of .
Change:
#![feature(allocator_internals)] #![feature(allow_internal_unsafe)] #![feature(allow_internal_unstable)] <del> #![feature(atomic_mut_ptr)] </del> #![feature(arbitrary_self_types)] #![feature(array_error_internals)] #![feature(asm)] #![feature(assoc_int_consts)] #![feature(associated_type_bounds)] <ins> #![feature(atomic_mut_ptr)] </ins> #![feature(box_syntax)] #![feature(c_variadic)] #![feature(cfg_target_has_atomic)]

Discussion:
I got a bug report on Diesel from someone who has a database column called . This lead to us attempting to generate the following code: which causes a type mismatch because their struct is shadowing the primitive. I'd like to change the generated code to be , which is the path that the rustdoc for libstd indicates it should be, but the type doesn't exist there, or anywhere else I can find. I would assume the same issue exists for , , and all the numeric types.
Since the module already exists, the type cannot be called . But it can be aliased as I guess.
would make sense as well
Related: The reason these primitives are not put into prelude was because but I think this is no longer a problem? (cc
Tagging this as a library issue. The solution (if it happens on our side) is to add a module or (and reexport it from as well) as described in In the meantime Diesel can privately define such a module itself and use it when unintended shadowing can happen. It doesn't make much sense to put primitive types into the std prelude because they are already in a prelude actually, it's just not the std prelude, but an additional language prelude one level below (as it was decided in and ).
I agree that primitives should be exposed at some absolute path. sounds reasonable.
I'd be happy to work on this. What's needed besides the implementation? I'm not entirely sure what a test for this should look like. Just a run-pass test that shadows and references ? Do we need one for every type?
I would start with a PR that has: Implementation, Module-level documentation for std::primitive with a helpful example that communicates why you may want to use this, One run-pass test for a shadowed bool as you suggested.
Sounds good. I'll try to get that PR done this week.
Does this need a feature gate?
Yes I believe so.
Triage: not aware of anything happening here.
Change:
let llvm_selfprofiler = llvm_profiler.as_mut().map(|s| s as *mut _ as *mut c_void).unwrap_or(std::ptr::null_mut()); <del> let extra_passes = config.passes.join(","); </del> <ins> let extra_passes = if !is_lto { config.passes.join(",") } else { "".to_string() }; </ins> let llvm_plugins = config.llvm_plugins.join(",");

Discussion:
Building a simple fuzz target using --cfg fuzzing -Cpasses=sancov-module -Cllvm-args=-sanitizer-coverage-level=4 -Cllvm-args=-sanitizer-coverage-inline-8bit-counters results in a linker error: {symbol} referenced in section {section} at {rcgu}: defined in discarded section {other section} of {other rcgu}. One possible workaround is to set -Ccodegen-units=1 (any higher value triggers the error). Alternatively, -Znew-llvm-pass-manager=no and -Cpasses=sancov (instead of -Cpasses=sancov-module) will also result in a successful build. Repro steps: : Note: The same error also occurs with rustc 1.61.0 (stable channel). : Note: GNU ld is the default linker on this system. On another system where the linker is LLD, a similar error occurs, the message is just worded a bit differently.
We somehow end up running sancov-module on an input that already has defined. For the example IR below, the following happens: We generate a new which has a numeric suffix (".19" in the error message above). This is part of the $sancov.modulector8bitcounters (no suffix) comdat. The suffixed is to which already mentions and the original (no suffix). The .initarray.2 that is generated from is mentioned in two comdat groups: f and sancov.modulector8bitcounters. If we subsequently link this object with another object which also has a sancov.modulector8bitcounters comdat group, the linker will preserve only one of the sancov.modulector8bitcounters comdat groups. The error message shown earlier happens when the linker discards the comdat group that contains but keeps the .initarray.2 that references that symbol. It can do this because that .initarray.2 is also mentioned in comdat group f. LLVM IR before sancov-module: Some relevant sections of the IR after : After machine code generation, : There is an assert in CreateInitCallsForSections: This assert will trigger when is created. Of course, that only happens in LLVM builds with asserts enabled.

What I don't yet know is why the sancov-module pass is being run on a module it has already been run for. I can see the multiple runs in the output if I pass in -Cllvm-args=-print-before-all, one of which creates the suffixed function, but I do not know what causes the pass to be run multiple times on the same module.
Passes configured with should probably be included only in pre-link optimization stage in: Similarly to sanitizer passes configured a few lines earlier: Otherwise they will be executed multiple times with LTO (a thin local LTO is enabled by default when using multiple codegen units).
Thank you. I was thinking along the same lines. I have a patch that does this, which I will send for review once I've tested it. I am wondering if there is value in also being able to specify passes specifically for the LTO stage; perhaps with a new -Zlink-passes flag. What do you think?
Change:
pub fn ioctlsocket(s: SOCKET, cmd: c_long, argp: *mut c_ulong) -> c_int; pub fn InitializeCriticalSection(CriticalSection: *mut CRITICAL_SECTION); pub fn EnterCriticalSection(CriticalSection: *mut CRITICAL_SECTION); <del> pub fn TryEnterCriticalSection(CriticalSection: *mut CRITICAL_SECTION) -> BOOLEAN; </del> <ins> pub fn TryEnterCriticalSection(CriticalSection: *mut CRITICAL_SECTION) -> BOOL; </ins> pub fn LeaveCriticalSection(CriticalSection: *mut CRITICAL_SECTION); pub fn DeleteCriticalSection(CriticalSection: *mut CRITICAL_SECTION);

Discussion:
According to , the return type of is (an alias for ), but in Rust we use (an alias for ): Which one is right?
winapi BOOL (c_int/i32) -- I suspect that this has been wrong since forever. Presumably we haven't noticed because in practice the values are always just and usually not 0 modulo 256, either, so we aren't spuriously wrong, and the value is passed in a register -- which on ~all platforms is 32-64bits anyway. Presumably though we should just fix this; cc who originally these in and cc more broadly. (Also, can I just say that having both BOOLEAN and BOOL as aliases and they mean different things is pretty confusing?)
This is practically guaranteed to just be a typo on my end, so BOOL is most likely right.
Yeah, that one is on Microsoft... .
Change:
"clippy_utils", "if_chain", "itertools 0.10.1", <del> "pulldown-cmark 0.9.0", </del> <ins> "pulldown-cmark", </ins> "quine-mc_cluskey", "regex-syntax", "rustc-semver",

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:
_ => {} } <del> tokens.unwrap_or_else(|| { nt.1.force(|| { // FIXME(jseyfried): Avoid this pretty-print + reparse hack let source = pprust::token_to_string(self); parse_stream_from_source_str(FileName::MacroExpansion, source, sess, Some(span)) }) }) </del> <ins> let tokens_for_real = nt.1.force(|| { // FIXME(#43081): Avoid this pretty-print + reparse hack let source = pprust::token_to_string(self); parse_stream_from_source_str(FileName::MacroExpansion, source, sess, Some(span)) }); if let Some(tokens) = tokens { if tokens.eq_unspanned(&tokens_for_real) { return tokens } } return tokens_for_real </ins> } }

Discussion:
I ran across a very curious case today... Given this procedural macro: and this expansion: when compiled I get: which is quite curious! -- er, just wrong thinking here cc cc cc
Seems similar to how also causes an inconsistency.
Ok I think I see what's going on here. This has to do with introduced in Basically I think this boils down to , we fundamentally cannot losslessly tokenize an AST item into a list of tokens to hand to a procedural macro. What's happening here is that all the tokens of the are saved off in the parser. This is the original source token stream which produced the struct. Later on when we tokenize the struct to hand off to a procedural macro we will use this cached token stream, if available, and tokenize it out and return it. When stringifying, however, we use the actual AST node itself (the source of truth). The bug is that cfg processing does indeed happen before the procedural macro runs. The cfg processing is modifying the AST item's internal fields but it's not invalidating the cached token stream or modifying it. Hence when the procedural macro runs the cached token stream is invalid wrt the internal state of the AST node, causing two different results to come out depending on how you look at it. Possible solutions here are: the cached list of tokens if the AST node is modified. This seems tricky to get right, are there other locations where a modification can happen? implemented , but holy cow that's a lot of work. the two results of tokenization (stringify + parse and the tokens themselves) and return the string one if they differ. None of them seem like great solutions :(
Change:
<ins> error[E0597]: `s` does not live long enough --> $DIR/do-not-ignore-lifetime-bounds-in-copy-proj.rs:9:18 | LL |     let a = (Foo(&s),); |                  ^^ borrowed value does not live long enough LL |     drop(a.0); |          --- copying this value requires that `s` is borrowed for `'static` LL |     drop(a.0); LL | } | - `s` dropped here while still borrowed error: aborting due to previous error For more information about this error, try `rustc --explain E0597`. </ins>

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 : I expected to see this: Instead, happens undefined behavior. Program successfully compiles in the Rust but fails to compile in (thats what I want).
Regressed in , likely cc
Visited in the compiler team triage meeting. It would be good to look into closing this ASAP. do you think you'll have time to investigate? If not, I'd want to find someone else.
We've assigned this speculatively to -- if you think you won't be able to investigate promptly, though, feel free to unassign and ping t-compiler for reassignment,
I expected the behavior to match that of this example (which still errors): I wonder if the gets erased somehow. Maybe an "user type annotation" is required on the from a , to give it a lifetime'd type?
Change:
// While we don't allow *arbitrary* coercions here, we *do* allow // coercions from ! to `expected`. if ty.is_never() { <del> assert!( !self.typeck_results.borrow().adjustments().contains_key(expr.hir_id), "expression with never type wound up being adjusted" ); </del> <ins> if let Some(adjustments) = self.typeck_results.borrow().adjustments().get(expr.hir_id) { self.tcx().sess.delay_span_bug( expr.span, "expression with never type wound up being adjusted", ); return if let [Adjustment { kind: Adjust::NeverToAny, target }] = &adjustments[..] { target.to_owned() } else { self.tcx().ty_error() }; } </ins> let adj_ty = self.next_ty_var(TypeVariableOrigin { kind: TypeVariableOriginKind::AdjustmentType, span: expr.span,

Discussion:
I'm seeing an internal compiler error on the following input, found by : The ICE happens after reporting some other errors, so I guess low priority. Affected versions: nightly 2022-04-22 does show the ICE, but beta 1.61.0-beta.3 does not show the ICE. <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2022-04-01 to nightly-2022-04-22 regressed nightly: nightly-2022-04-17 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
A invocation should be replaced by and producing an error type as the adjustment result
I think this is still open and it looks like a fun problem to dig into. Please let me know if I should let someone else work on it though please! claim
I also found this issue in that version's nightly rustc. I consider that is a nontrival problem worth digging into.
I have opened a PR () that I believe addresses the ICE. I think I pretty much implemented what Oli described, but I'm a little unclear as to whether this is the actual solution or is the fact that there's an adjustment on a never type at all the real bug? I also wasn't able to reduce the minimal error case much beyond what Badel2 posted. Do you happen to have a simpler error case, Peter?
I'm assigned to your PR, and looked into this issue really quickly. So this is due to the new argument type compatibility algorithm implemented in (cc: The after  has been called once before during the "good" path of . This is somewhat problematic, since this means that typeck code deeper in the stack attemps to apply adjustments twice and sometimes panicks because of this. A similar bug was fixed in when other diagnostic code called several times on a bad path.

Since this will only reasonably happen during diagnostic code, I think it's fine for now to delay a bug.
Thank you for the background! That helps a lot to clarify things. I clearly need to do a lot more reading.
Yeah, I also just have a simple ICE from rustc. But there has been some expositions from , so I think maybe this issue would be solved in the future.
Change:
<ins> warning: this operation will panic at runtime --> $DIR/ice-assert-fail-div-by-zero.rs:11:5 | LL |     f.0 / 0; |     ^^^^^^^ attempt to divide _ by zero | note: the lint level is defined here --> $DIR/ice-assert-fail-div-by-zero.rs:5:9 | LL | #![warn(unconditional_panic)] |         ^^^^^^^^^^^^^^^^^^^ warning: 1 warning emitted </ins>

Discussion:
UPDATE: MCVE can be found . Nightly compilation error due to rustc bug I tried this code: I expected to see this happen: explanation Successful compilation. Instead, this happened: tells to report a bug, see backtrace. : Reproduce with (1st update) <details<summaryBacktrace</summary<p</p</details
cc
Also occured with
I'm getting this when I try to repro: On a side note, are there any cargo feature flags I can pass to cut down on how much stuff is being compiled? Compiling 900 crates to get a repo is quite a lot
Also occured with just now.
mmh try with commit hash ? (for )
updated script:
Yeah, sorry for that. One of the difficulties of working with a big framework like Substrate. I'll see if I can narrow it down more.
That did it! Thank you
Some with the same issue (a different chain also using Substrate) found out that apparently works.
Seems is the cause, marking as .
Here's a smaller repro (at least in terms of how much code is built: 33 crates instead of a few hundred):
just confirmed that it does not occur with
I have a minimal repro:
Wild guess: erases the local before we are able to emit the diagnostic message.
I seem to be getting a similar error again on a more current nightly (). Should I open a new issue or do we just reopen this one?
This is still broken. I'm pretty confused because running the test you in on the shows that it ICEs. Is the test not actually working for some reason? Edit: Does that test need in order to actually check the body of those functions since they are uncalled from ?
Assigning as and removing I-prioritize.
Hi and have either of you had a chance to upgrade to a recently nightly? I just wanted to confirm this is fixed for you.
I've updated to rust version 1.47.0-nightly ( 2020-07-22), and tried compiling the crate which was triggering this ICE (). I no longer encounter an ICE, the crate compiles successfully.
I can confirm is not throwing ICE :+1:
Great, thank you!