jiebi/CodeConvo huggingface dataset:
Change:
<ins> include ../tools.mk # ignore-cross-compile # ignore-wasm all: $(RUSTC) --crate-type rlib -lbar_cli bar.rs $(RUSTC) foo.rs -lfoo_cli --crate-type staticlib --print native-static-libs 2>&1  | grep 'note: native-static-libs: '  | sed 's/note: native-static-libs: (.*)/1/' > $(TMPDIR)/libs.txt cat $(TMPDIR)/libs.txt | grep -F "glib-2.0" # in bar.rs cat $(TMPDIR)/libs.txt | grep -F "systemd" # in foo.rs cat $(TMPDIR)/libs.txt | grep -F "bar_cli" cat $(TMPDIR)/libs.txt | grep -F "foo_cli" </ins>

Discussion:
This is with Rust 1.69 but was probably always the case. Example: Compiling with prints Similarly when providing nothing changes. I didn't really follow how collects the libraries but I think it's via the query in which claims so this should be included AFAIU. Also the rationale of was to provide all libraries needed to link to the resulting , which is not the case in the above example. CC who originally implemented this feature.
It works as expected if the attribute is used in a dependencies. It seems to me that the function, is forgetting to add the current native libs. Doing something like this correctly adds to the output (even when passed via the command line) but I don't know if it's the right thing to do (cc
Yeah, I think adding is the correct fix. That adds the same information as does for dependencies.
Beware that is rather quirky. Originally Rust printed lines during build with information which link flags need to be to use the static library it builds, and is a blunt way of redirecting these "warnings". I don't know whether omission of is a bug or the old warnings just weren't meant to print them.
I can't imagine it to be a deliberate omission as is the only way to know how to correctly link any arbitrary staticlib afaik.
Change:
(false | true, false | true) => {} } match (true, true) { <del> (true, false) => {} (false, true) => {} </del> <ins> (true, true) => {} (false, false) => {} </ins> (false | true, false | true) => {} } <ins> // https://github.com/rust-lang/rust/issues/76836 match None { Some(false) => {} None | Some(true | false) => {} //~ ERROR unreachable } </ins> // A subpattern that is unreachable in all branches is overall unreachable. match (true, true) { (false, true) => {}

Discussion:
The match remains exhaustive with highlighted pattern removed, but it does not produce any warnings: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I know where the problem comes from: this bit of code tries to handle unreachable sub-or-patterns diagnostics, but it's a bit of a hack. What remains is to come up with a better solution. claim
Change:
// FIXME: The following limits should be reduced eventually. const ROOT_ENTRY_LIMIT: usize = 1102; const ISSUES_ENTRY_LIMIT: usize = 2310; <del> const PARSER_LIMIT: usize = 1004; </del> <ins> const PARSER_LIMIT: usize = 1005; </ins> fn check_entries(path: &Path, bad: &mut bool) { let dirs = walkdir::WalkDir::new(&path.join("test/ui"))

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. --Given the following code: <!-- Please provide a link to -- (which has a zero width space between the and its ending ) The current output is: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --If there are any non-printing characters, show where they are (debug unicode representation on the whole string, maybe?), and if there's only one printing character, make a suggestion to remove everything but the printing character. <!-- 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
Change:
item: &Item, hir_id: HirId, doc: &'md str, <ins> resolutions: &DocLinkResMap, </ins> ) -> Option<()> { let mut broken_line_callback = |link: BrokenLink<'md>| Some((link.reference, "".into())); let mut offset_iter = Parser::new_with_broken_link_callback(

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. --Basically this is the module where it fails, right now I can't create a minimized example, I'll try to later: on: branch: Bug also exists on nightly, and also on Linux: : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I can confirm this bug on
minimized repro: label T-rustdoc A-intra-doc-links A-resolve S-has-mcve -needs-triage
Change:
use rustc_middle::ty::{self, AdtDef, AdtKind, List, ScalarInt, Ty, TyCtxt, TypeVisitableExt}; use rustc_span::ErrorGuaranteed; use rustc_target::abi::{ <del> FieldIdx, FieldsShape, Layout, Size, TyAndLayout, VariantIdx, Variants, </del> <ins> FieldIdx, FieldsShape, Layout, Size, TagEncoding, TyAndLayout, VariantIdx, Variants, </ins> }; use super::Tree;

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'Size::sub: 0 - 1 would result in negative size'', 'thread 'rustc' panicked at 'Size::sub: 0 - 1 would result in negative size'' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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: [evaluateobligation] evaluating trait selection obligation [typeck] type-checking [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
On it! Thanks for the report.
Further minimized:
The cause here is neat. here is niche optimizable, with its second variant being subject to niche optimization. Typically, a niche-optimized enum has one tagless variant, and zero or more tagged variants laid out in the usual manner: the tag is placed, and then the rest of the fields follow. But reveals that's not what happens here. Because is a ZST, is placed at offset , rather than (following the tag). In other words: the tag is co-located with the field. This produces an ICE, because our assumption that fields follow tag is violated (a checked sub panics).
claim
Change:
<ins> // edition:2021 // run-rustfix #![allow(unused)] use std::future::Future; async fn foo() -> Result<(), i32> { func(async { Ok::<_, i32>(()) }).await?; //~^ ERROR the `?` operator can only be applied to values that implement `Try` Ok(()) } async fn func<T>(fut: impl Future<Output = T>) -> T { fut.await } fn main() {} </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. 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. --Given the following code: 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. --
Huh, looks like this is a case where doesn't kick in for some reason.
Ah, it's that the return type of an async function like this has . I don't know enough about rustc's typechecking to know whether this can be resolved haha.
It doesn't seem like the problem that caused is a thing anymore? I can remove the condition and it doesn't ICE on the example given in that issue.
do you know if stuff has changed such that is no longer necessary?
I actually have a PR almost up that does just exactly that, though if you want to put one up instead then feel free.
I'm pretty sure fixes this underlying issue. This method could use some additional cleanup as well.
Change:
} } } <ins> #[test] // miri shouldn't detect any data race in this fn #[cfg_attr(any(not(miri), target_os = "emscripten"), ignore)] fn test_env_get_set_multithreaded() { let getter = thread::spawn(|| { for _ in 0..100 { let _ = var_os("foo"); } }); let setter = thread::spawn(|| { for _ in 0..100 { set_var("foo", "bar"); } }); let _ = getter.join(); let _ = setter.join(); } </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. --Investigating library sources for , I have found that the copying of the env variable value is performed not under the lock: So there is a potential data race with setenv. I tried this code with miri And got Have tried to move under the lock, but still got error with miri. I was not able to trigger the real crash with it yet. <!-- 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. --: Bug was introduced by this commit: (PR: ) Before that changes, read was under the lock. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
I think this happened because implicit scoping of the lock guard, which makes it easy to shorten its lifetime the rwlock isn't coupled to the resource via a lifetime, so it's easy for the extracted pointer to be used longer than the lock is valid The first one could be made more visible by linting to add an explicit to make its lifetime more explicit in the code when a critical section ends. Especially when guard is otherwise unused which indicates that the lock doesn't directly own the resource it protects. The second one could be solved by using a lifetime-tagged raw pointer and coupling that lifetime to the guard.
Side note: even when fixed this assumes all other read/writes acquire Rust's lock and is potentially unsound if they do not. This has often been discussed with a view to making unsafe. Arguably if that happens then the lock would be redundant, although it could also be argued it's still useful to help avoid some footguns even if you can't make it totally safe.
That's
That PR did not add a test, did it? Would be good to add one in (those are run in Miri regularly). We probably don't want iterations though, that will take forever. 100 should easily be enough.
Something like ?
Yeah something like that.

For Miri it's not really necessary to do this "sum of the lengths" computation, not sure why that would be particularly susceptible to a data race. The one existing concurrency test uses , so probably it would make sense to use the same attribute here.
Change:
return Err(this); } <del> atomic::fence(Acquire); </del> <ins> acquire!(this.inner().strong); </ins> unsafe { let elem = ptr::read(&this.ptr.as_ref().data);

Discussion:
iff the crate contains two or more unit tests. TODO Sanitizers are not yet in tree. (cf. ) cc
Like with I'd be tempted to say these are false positives, but these stack traces don't look so familiar so I'm not certain of that
This will be a false positive because drop_slow uses a fence, and tsan doesn't work with fences.
So I take it this isn't actually a problem since we're just using a fence and tsan doesn't support that? Should we close?
Can the false-positive be worked-around by manually annotating the happens-before relationship? See
Well, maybe if we could conditionally build without the fence (rework to use a load/store instead) when tsan is enabled then the error wouldn't be seen.
Change:
None => fail!("RefCell<T> already borrowed") } } <ins> /// Get a reference to the underlying `UnsafeCell`. /// /// This can be used to circumvent `RefCell`'s safety checks. /// /// This function is `unsafe` because `UnsafeCell`'s field is public. #[inline] #[experimental] pub unsafe fn as_unsafe_cell<'a>(&'a self) -> &'a UnsafeCell<T> { &self.value } </ins> } #[unstable = "waiting for `Clone` to become stable"]

Discussion:
This would be useful in cases where we mostly want to enforce guarantees but need to break the rules in one place. (e.g. the Servo interface to html5ever which needs to GC-trace a mutably-borrowed parser)
Similarly, this would be useful for RAII classes that need to be fail-proof in the face of task failure while there are outstanding RefCell borrows.
I don't think that case should be an issue; the / destructors have to run before their 's. They don't right now in some cases due to some unsoundness problems but that will be fixed: .
Same for , please, for
Does the accessor itself need to be ? I don't think so, because the relevant ops are and we're only handing out shared references to it.
Change:
<ins> error: expected `,`, or `}`, found keyword `fn` --> $DIR/fn-field-parse-error-ice.rs:4:16 | LL |     inner : dyn fn () |                ^ help: try adding a comma: `,` error: functions are not allowed in struct definitions --> $DIR/fn-field-parse-error-ice.rs:4:17 | LL |     inner : dyn fn () |                 ^^ | = help: unlike in C++, Java, and C#, functions are declared in `impl` blocks = help: see https://doc.rust-lang.org/book/ch05-03-method-syntax.html for more information error[E0412]: cannot find type `dyn` in this scope --> $DIR/fn-field-parse-error-ice.rs:4:13 | LL |     inner : dyn fn () |             ^^^ not found in this scope error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0412`. </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 regressed in , which is a rollup. Luckily is the only real candidate though. The panic that gets called is this one: From a quick scan of a result gets dropped here : cc searched nightlies: from nightly-2021-05-07 to nightly-2021-05-29 regressed nightly: nightly-2021-05-09 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details
Mhh, I don't even remember why I this call to in the first place, maybe to consume the fn body and get fewer/cleaner errors? Should have a comment... Anyway fixing this should be easy, we can (or ) the error, or remove the call to .
Change:
// fields of ADT. let tcx = self.tcx(); for field_ty in adt_def.all_fields().map(|field| field.ty(tcx, substs)) { <del> if field_ty.visit_with(self) { </del> <ins> let ty = self.tcx().normalize_erasing_regions(ty::ParamEnv::empty(), field_ty); debug!("structural-match ADT: field_ty={:?}, ty={:?}", field_ty, ty); if ty.visit_with(self) { </ins> // found an ADT without structural-match; halt visiting! assert!(self.found.is_some()); return true;

Discussion:
One of the tests in my enumset crate has started throwing an ICE on the latest nightly. The problem seems to be that I use an associated type as a field in a struct I'm structurally matching, and this has been broken on the latest nightly. <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
cc looks like it's likely EDIT: oh 's type is fully concrete, so the field type () could be normalized and then it would be structurally matcheable. This is a reason why using a trait might be better, it wouldn't have edge cases like this (although it has other complications). At the very least we should normalize.
I also believe we are forgetting to normalize here, will look into it. claim
points a regression in which may confirm that is the culprit.
Assigning .
Change:
<ins> mod demo { fn hello() { something_later!(); //~ ERROR cannot find macro `something_later` in this scope } macro_rules! something_later { () => { println!("successfully expanded!"); }; } } fn main() {} </ins>

Discussion:
Often times, the actual error of the attempted call and the warning of the unused macro can be apart and/or soaked in other errors. Due to this, it might be desirable to couple a help message addressing this specific situation of a later definition. This might also be useful advice for beginners who are just starting out with Rust and might not be aware of the horrors of declarative macros using , and as such could appreciate a helping hand by the compiler here. No response_ I tried to keep the suggested output close to the one for similarly named macros/variables, but that might not be applicable here and instead deserve its own section under the code excerpt. Open for bikeshedding. Like all of this, actually. Hmm. (The message is the same on nightly 2024-02-12.)
label +D-terse +D-newcomer-roadblock
Thank you!!
Change:
LL |     let _: ConstString<"ℇ㇈↦"> = ConstString::<"ℇ㇈↥">; |                                  ^^^^^^^^^^^^^^^^^^^^^ expected `"ℇ㇈↦"`, found `"ℇ㇈↥"` | <del> = note: expected type `ConstString<>` found type `ConstString<>` </del> <ins> = note: expected type `ConstString<"ℇ㇈↦">` found type `ConstString<"ℇ㇈↥">` </ins> error[E0308]: mismatched types --> $DIR/slice-const-param-mismatch.rs:13:33

Discussion:
This code (): results in with missing const arguments in the at the bottom.
Hey guys could I take this on?
Just FYI, same problem with messages involving const generics and matches, e.g. () Also for functions: ()
Interestingly, when I use concrete types for the function example, things display properly: gives ()
you're welcome to look into fixing this! However, I'm not sure what might be causing this problem, so I don't have any suggestions for where to start looking yet.
I spent a few hours doing some digging and I can't find anything yet as well, though I'm as of yet still quite unfamiliar with the code-base. I might have more time tomorrow to look things over again, or maybe the day after.
Change:
lhs_needs_parens || (followed_by_block && match inner.kind { <del> ExprKind::Ret(_) | ExprKind::Break(..) => true, </del> <ins> ExprKind::Ret(_) | ExprKind::Break(..) | ExprKind::Yield(..) => true, </ins> _ => parser::contains_exterior_struct_lit(&inner), }) }

Discussion:
I tried this code: I expected to see this happen: no warning Instead, this happened: if I follow the suggestion, then compilation fails: ( takes an optional expression, not wrapping it in parentheses means the block becomes that expression, and the is then missing a block). - `rustc 1.47.0-nightly (2020-07-27 )
The lint is a rustc lint, not a Clippy lint. This issue should probably be moved to the rust-lang/rust repo. can you move this issue, please?
Done, thanks
Change:
#![feature(slice_get_slice)] #![feature(slice_patterns)] #![feature(slice_rsplit)] <ins> #![feature(slice_sort_by_cached_key)] </ins> #![feature(specialization)] #![feature(staged_api)] #![feature(str_internals)]

Discussion:
Where we would normally put "^^^ did you mean Up" under mistyped names, I noticed that we don't do that for enum variants. Here's an example I just saw: !
Taking a look.
Change:
<ins> error[E0121]: the placeholder `_` is not allowed within types on item signatures for return types --> $DIR/leaking-unnameables.rs:8:18 | LL | pub fn f<T>() -> _ { |                  ^ |                  | |                  not allowed in type signatures |                  help: replace with the correct return type: `fn()` error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0121`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: Unexpected coroutine/closure type in variance computation', 'error: internal compiler error: Unexpected coroutine/closure type in variance computation' 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: [cratevariances] computing the variances for items in this crate [variancesof] computing the variances of [mirborrowck] borrow-checking [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
smaller
ice since it seems
i can look into this claim
Change:
} } <ins> /// For generic types with parameters with defaults, remove the parameters corresponding to /// the defaults. This repeats a lot of the logic found in `PrintContext::parameterized`. fn strip_generic_default_params( &self, def_id: DefId, substs: &ty::subst::Substs<'tcx> ) -> &'tcx ty::subst::Substs<'tcx> { let generics = self.tcx.generics_of(def_id); let mut num_supplied_defaults = 0; let mut type_params = generics.params.iter().rev().filter_map(|param| match param.kind { ty::GenericParamDefKind::Lifetime => None, ty::GenericParamDefKind::Type { has_default, .. } => { Some((param.def_id, has_default)) } }).peekable(); let has_default = { let has_default = type_params.peek().map(|(_, has_default)| has_default); *has_default.unwrap_or(&false) }; if has_default { let types = substs.types().rev(); for ((def_id, has_default), actual) in type_params.zip(types) { if !has_default { break; } if self.tcx.type_of(def_id).subst(self.tcx, substs) != actual { break; } num_supplied_defaults += 1; } } let len = generics.params.len(); let mut generics = generics.clone(); generics.params.truncate(len - num_supplied_defaults); substs.truncate_to(self.tcx, &generics) } </ins> /// Compare two given types, eliding parts that are the same between them and highlighting /// relevant differences, and return two representation of those types for highlighted printing. fn cmp(&self, t1: Ty<'tcx>, t2: Ty<'tcx>) -> (DiagnosticStyledString, DiagnosticStyledString) {

Discussion:
In , adding an parameter to the type, that defaults to induces changes to UI tests that are indicative of something that seemed to need improvement in the compiler, namely that when you have a type , errors should present instead of when they can. It turns out, the compiler does. But not consistently. The following is derived from : () This yields the following errors: See how it prints instead of the (imho) desired , but , not .
This all stems from the fact that in some cases, types are just printed out by formatting the instances, while in other cases, there is manual machinery to highlight parts of the type that handle things, and that doesn't have the default-param elimination that has.