jiebi/CodeConvo huggingface dataset:
Change:
pub fn new(build: &Build) -> Builder<'_> { let (kind, paths) = match build.config.cmd { Subcommand::Build { ref paths } => (Kind::Build, &paths[..]), <del> Subcommand::Check { ref paths, all_targets: _ } => (Kind::Check, &paths[..]), </del> <ins> Subcommand::Check { ref paths } => (Kind::Check, &paths[..]), </ins> Subcommand::Clippy { ref paths, .. } => (Kind::Clippy, &paths[..]), Subcommand::Fix { ref paths } => (Kind::Fix, &paths[..]), Subcommand::Doc { ref paths, .. } => (Kind::Doc, &paths[..]),

Discussion:
It's possible to have errors in files such as: and , and have pass. I would expect to be equivalent of and check every file that CI checks. Otherwise, I run , push code to a PR, and only find later that I have a typo or such.
We don't check tests by default, but you can pass --all-targets () to check tests. I believe this is consistent with cargo check behavior? One reason we don't check tests by default is that causes duplicate error messages for the 'base' crate typically which are annoying (and most changes don't actually need them). If Cargo handled that and didn't show duplicate messages, I imagine we could change the default as well.
Oh, you're right. So my mistake was assuming that is more thorough than it is (my text editor invokes it for me, even for tests, so I didn't realize the command doesn't do everything itself).
Just FYI, 1.55 now deduplicates messages.
Oh, great news -- in that case I'm going to go ahead and reopen this as it seems likely to make sense to check tests (by default, and likely without an option to disable that). Should be a pretty simple adjustment to bootstrap.
Change:
<ins> # Check for GNU Property Note include ../tools.mk # How to run this # python3 x.py test --target x86_64-unknown-linux-gnu  tests/run-make/branch-protection-check-IBT/ # only-x86_64 all: ifeq ($(filter x86,$(LLVM_COMPONENTS)),x86_64) $(RUSTC) --target x86_64-unknown-linux-gnu -Z cf-protection=branch -L$(TMPDIR) -C link-args='-nostartfiles'  -C save-temps  ./main.rs -o $(TMPDIR)/rsmain readelf -nW $(TMPDIR)/rsmain | $(CGREP) -e ".note.gnu.property" endif </ins>

Discussion:
I noticed that the synthetic object files in will disable the IBT (on x86, enabled by ) and BTI (on AArch64, enabled by ) features because the object files are missing sections indicating that the object file is compatible with those features. Normally, if an object file is missing a section, the linker will disable all such features, on the assumption that the object file is not compatible. This issue is reproducible on the master branch (slightly awkwardly because many distros don't ship IBT-enabled files, and neither is it enabled in Rust's standard library by default): In another directory: After commenting out the line of code that adds to the link: the binary has the correct property note: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I can think of three possible solutions: the appropriate GNU property section into the synthetic object file according to the passed flags. This would work, but it could easily get out of sync with the GNU properties produced by the compiler. a change in linker behavior so that the GNU properties are not affected by object files that do not contain sections. This would make sense because an object file without sections cannot on its own affect the contents of the final binary, which means that it cannot cause the binary to become {BTI,IBT}-incompatible. a linker feature that implements equivalent behavior to the synthetic object file, e.g. a flag that is equivalent to but does not inhibit , and then use that on ELF platforms instead of the synthetic object file if the linker supports it. may have thoughts on this.
Option 3 is not enough to solve this. The crate metadata object is also produced without these properties and can't be replaced with a linker option. Option 2 will take a long time before everyone has a new linker and needs coordination with , , and As such option 1 makes most sense to me.
Option 2 needs coordination among linker maintainers and it does impose some complexity to linkers. And as mentioned, it requires very new linkers. If Rust is open to 1, I think it is a great direction.
claim
Change:
<del> Subproject commit b7c802b5e33f5a402de3780bc5a8b05e7ebad409 </del> <ins> Subproject commit 28197b622611ba3a6367648974ccf59127c287bb </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! And nominating for compiler team prioritization.
probably needs to be addressed as well.
Change:
assert_eq!(branch, 1); } <ins> fn e() { match &[1, 2, 3] { [1, 2] => (), [..] => () } } </ins> pub fn main() { a(); b(); c(); d(); <ins> e(); </ins> }

Discussion:
It looks like introduced a regression. The following used to work: but now generates the following error:
Yeah, sorry about that! There's already a fix for this in
I am also now seeing spurious 'non-exhaustive patterns' errors when attempting to match struct variants of an imported enum type. For example, here is a simplification of some code in : The error is:
Oh dear. Looks like it only fails when the enum is defined in a different crate as this works: I'll take a look!
Please add an appropriate test for this case... Niko
I a test for the cross-crate case in . There are already quite a few existing tests for local variants.
On Sun, Jun 22, 2014 at 07:43:54AM -0700, Jakub Wieczorek wrote: great
Change:
cx: &mut DocContext<'_>, item_def_id: DefId, ) -> impl Iterator<Item = Item> { <del> // FIXME: To be removed once `parallel_compiler` bugs are fixed! // More information in <https://github.com/rust-lang/rust/pull/106930>. if cfg!(parallel_compiler) { return vec![].into_iter().chain(vec![].into_iter()); } </del> let auto_impls = cx .sess() .prof

Discussion:
There is a latent bug in rustdoc that hangs in when is enabled.
From the thread on :
Interestingly, also gets stuck. I believe that runs the beta (non-parallel) rustdoc. So that'd mean that rustdoc gets stuck when documenting parallel rustc, not that parallel rustdoc gets stuck when documenting rustc.
Both of the PRs that are blocked by this issue are changes that change the ast.
It seems it's not an infinite loop, but just bad (exponential?) time complexity somewhere. suggested trying out what happens when explicitly implementing Send and Sync for the new ast node, and that indeed 'fixes' the problem in So this issue has almost nothing to do with parallel compiler. It occurs in regular non-parallel rustdoc. It's just that with , the ast is Send and Sync, and apparently that takes a huge amount of time to prove when documenting rustcmiddle. (Oli is investigating.)
Data point: Adding the following snippet to will not stop it from compiling successfully, even though documenting the crate will never stop. This makes me think the issue is very much rustdoc related, as it appears to get stuck on proving .
WG-prioritization assigning priority () (note: seems not a regression) label -I-prioritize +P-high
cc
and , https://rust-
[Edit] I'm trying to solve this problem and what I'm currently observing is that the does not store all the information when using rustdoc. This causes rustdoc to recalculate many times when collecting auto trait impl and blanket trait impl. I guess it may be that rustdoc does not calculate the trait implementation on some data structures (such as ) in advance, which resulting in too deep recursion
A revealing phenomenon: The following struct in will cause rustdoc to block while proving that is : But when the generics are instantiated, it will not cause blocking: So I guess it is that causes the values in to not be reused. Because this cache needs inserting (predictions, ).
does this happen even with disabled?
If so, this is probably related to . This is how we determine the paramenv:
I can't reproduce this issue , including my local test Have there been any recent changes?
Change:
return '"%s"' % data <ins> def StdPathBufSummaryProvider(valobj, dict): # type: (SBValue, dict) -> str # logger = Logger.Logger() # logger >> "[StdPathBufSummaryProvider] for " + str(valobj.GetName()) return StdOsStringSummaryProvider(valobj.GetChildMemberWithName("inner"), dict) def StdPathSummaryProvider(valobj, dict): # type: (SBValue, dict) -> str # logger = Logger.Logger() # logger >> "[StdPathSummaryProvider] for " + str(valobj.GetName()) length = valobj.GetChildMemberWithName("length").GetValueAsUnsigned() if length == 0: return '""' data_ptr = valobj.GetChildMemberWithName("data_ptr") start = data_ptr.GetValueAsUnsigned() error = SBError() process = data_ptr.GetProcess() data = process.ReadMemory(start, length, error) if PY3: try: data = data.decode(encoding='UTF-8') except UnicodeDecodeError: return '%r' % data return '"%s"' % data </ins> class StructSyntheticProvider: """Pretty-printer for structs and struct enum variants"""

Discussion:
I tried this code (as package ): Run the following, which will break at , step the next 4 lines () to define the variables, then print twice -- the first time will succeed, the second time will fail: I expected to see this happen: would work the same no matter how many times I called it, instead everything seems to be undefined after the first call. Below I show that seems to work (including multiple times), works (including multiple times), but after a single call to , neither of these works anymore: Oddly, if I break on filename / line number instead of function name, it seems to work as expected: I'm using from a git checkout from yesterday:
Realized was not a but an ; have changed to . Don't think it changes the rest, behavior still the same with .
Works just fine in gdb for me: Rust-lldb doesn't want to load for me at all, but plain lldb works fine too. For reference I'm using lldb version 14.0.6.
If only gdb worked on aarch64-darwin! But thanks for prompting me to try other OS -- I can confirm that I do not see the bug using rust-lldb on x86_64-linux, so this may be isolated to one of darwin / aarch64 / aarch64-darwin. (Still repros for me on aarch64-darwin with lldb 16.0.6.)

If is a PathBuf, printing it from lldb does not give a string representation as I would expect. If I explicitly refer to it shows "None" for the inner OsString: If I use I finally get a vec representation.
I've details in .
Visited during wg-debugging triage. We were not able to conclusively repro but we're confident this is probably still an issue. Triaging as P-medium for now.
Change:
#[rustc_const_unstable(feature = "const_ascii_ctype_on_intrinsics", issue = "68983")] #[inline] pub const fn is_ascii_alphabetic(&self) -> bool { <del> self.is_ascii() && (*self as u8).is_ascii_alphabetic() </del> <ins> match *self { 'A'..='Z' | 'a'..='z' => true, _ => false, } </ins> } /// Checks if the value is an ASCII uppercase character:

Discussion:
I noticed this check: and wondered why it's there. Then someone told me it's there because of the . If you pass a non-ASCII char, the would corrupt that char. That's why the check is there before it. But then I wondered: why isn't this just cast to a bigger data type that includes all Unicode code points? This method (and others) are slower than they have to be. Also see this discussion in Discord with more valuable information:
(I can’t seem to find the relevant part in the middle of this discord stream…) I’m not sure what you mean by “corrupt”. is well defined: it takes the numerical value of the code point (same as ), then truncates to keep the lower 8 bits. equals 0x41, but so does . We want to reject the latter since U+1F041 is not an ASCII upper-case letter. If is implemented in terms of , the ASCII range check is necessary. (It could be a range check to, for example with .) But maybe doesn’t need to be implemented in terms of . Maybe it could duplicate the logic instead. Once upon a time was implemented with a lookup table of 256 entries. A flat lookup table for all of Unicode would be way too big. But these days it’s based on matching a range pattern. Doing the same with a range pattern could also work. That said, would it actually be faster? Maybe the optimizer already does its job well. If you want to work on this, consider adding some benchmark to show that code duplication is worth it.
Oh it seems the Discord link is a bit buggy. Try searching for in the search bar on the Discord server. Then you should get to my message with the discussion below it. One guy also posted this comparison of the instructions generated:
I think the minimal standard here should be a benchmark before we change the implementation. Can you provide that?
I'm not that experienced with Rust yet, sorry. I just wanted to point out this possible performance regression. Shouldn't the instruction amount difference as shown on Godbolt suffice to know that it's slower? vs.
Looking at the assembly, it seems that the problem is the check. These three functions produce : So, it seems that the check is unnecessary. I could make a PR for this.

Here are some benchmarks: So it seems that removing the check has a measurable performance difference.
is incorrect. The conversion should happen not for the ASCII check but for the , and the pattern use byte literals like . (Though I expect this won’t affect results much.)
Change:
<ins> //@ ignore-lldb // Test that static debug info is collapsed with #[collapse_debuginfo(yes)] //@ compile-flags:-g // === GDB TESTS =================================================================================== // gdb-command:info line collapse_debuginfo_static::FOO // gdb-check:[...]Line 19[...] #[collapse_debuginfo(yes)] macro_rules! decl_foo { () => { static FOO: u32 = 0; }; } decl_foo!(); fn main() { // prevent FOO from getting optimized out std::hint::black_box(&FOO); } </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 this code: then shows I'd expect DWATdecl_line to be 9 (the line where the macro is called), not 5 (the line where the static is defined inside the macro). <!-- 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. --:
cc
Change:
customize(spec_map); std::fs::write(&path, serde_json::to_vec_pretty(&spec).unwrap()).unwrap(); <del> let target = TargetSelection::create_synthetic(&name, path.to_str().unwrap()); crate::utils::cc_detect::find_target(builder, target); target </del> <ins> TargetSelection::create_synthetic(&name, path.to_str().unwrap()) </ins> }

Discussion:
Trying to bless mir-opt tests used to work fine on my Linux box, but some recent-ish change broke that:
seems to be some macOS/Apple SDK tool. does build std for a bunch of foreign targets, but that used to work, so something must have changed, and now is required. I'm not even sure where that error comes from, does not occur as a string in the Rust repository... Cc
Maybe is related? appears in the there, and here looks like it may be the one printing the error. Cc But this can't be a build script, right? bootstrap must be calling directly but then printing its errors without giving any context. Cc
In general, the mir-opt test setup is designed to dodge any use of the crate, because the whole strategy of the mir-opt tests is oriented around not needing a C toolchain.
I've posted a fix in It seems to work locally.
Change:
<ins> error[E0596]: cannot borrow `b` as mutable, as it is not declared as mutable --> $DIR/issue-114896.rs:4:9 | LL |         let &b = a; |             -- help: consider changing this to be mutable: `&(mut b)` LL |         b.make_ascii_uppercase(); |         ^ cannot borrow as mutable error: aborting due to previous error For more information about this error, try `rustc --explain E0596`. </ins>

Discussion:
No response Applying the suggestion gives No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It should suggest instead. Looks odd but it's correct. label -needs-triage A-suggestion-diagnostics D-invalid-suggestion
Hi, I'm interested in this issue and want to try to fix it. claim
Change:
LL | | } | |_^ <del> error: aborting due to 10 previous errors </del> <ins> error[E0587]: type has conflicting packed and align representation hints --> $DIR/conflicting-repr-hints.rs:70:1 | LL | pub struct S(u16); | ^^^^^^^^^^^^^^^^^^ error[E0587]: type has conflicting packed and align representation hints --> $DIR/conflicting-repr-hints.rs:73:1 | LL | / pub union U { LL | |     u: u16 LL | | } | |_^ error: aborting due to 12 previous errors </ins> Some errors have detailed explanations: E0566, E0587, E0634. For more information about an error, try `rustc --explain E0566`.

Discussion:
: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Can't reproduce, can you provide the full code that's needed to reproduce this?
Sure
MCVE:
Assigning as discussed as part of the and removing . label -I-prioritize +P-medium
bisection: searched nightlies: from nightly-2020-06-01 to nightly-2021-03-17 regressed nightly: nightly-2020-10-27 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Change:
// aux-build: issue_67893.rs // edition:2018 <del> // dont-check-compiler-stderr // FIXME(#71222): Add above flag because of the difference of stderrs on some env. </del> extern crate issue_67893;

Discussion:
Follow-up of Consider this example: It emits the stderr on my local (x86_64-unknown-linux-gnu): But on some other environment on CI, e.g. or , it emits it with a tiny difference: It's ideal to have the same diagnostics on all the environment. See also:
s shouldn't be leaked in user output.
Yeah, other places look like: Perhaps we emit accidentally in somewhere.
that makes me think that we probably have some instead of somewhere.
The relevant code is: I don't find any difference between here and similar places yet. thoughts?
the place to look at is: CC The same applies to closures, but we are likely not displaying them this way anywhere (or we've just gotten lucky).
Change:
panic!() } <ins> macro_rules! baz { ($($foo:expr),+) => { ($($foo),*) } } </ins> fn main() { foo(); bar((true)); //~ ERROR unnecessary parentheses around function argument

Discussion:
The latest beta contains a new? l lint that triggers on macro by example code. This does not necessarily make sense because macros could be used to construct nearly arbitrary custom syntax for example something requiring to wrap a single element into a parenthesis. The strange thing here is that seems to only happen on beta, not on nightly, not on current stable. Found via Error message: rustc version:
My head can't come up with an example that requires parentheses. macros are hygenic, so there should be no problem in omitting the parentheses and just writing will be fine. Can you give me a counter example?
A real world example is the diesel  macro. Somewhere in the inner it does some clever things to support plain types and tuples by just saying where is some repeated type variable. Depending on the number of actual types there this will result in which is a single type or which is a tuple. It's probably possible to rewrite that code doing the same stuff but that would involve a lot of duplication (Because than you would need to have a special case for a single type everywhere).
So somehing like this: You're right. The question is: should we remove the lint for all macros? Only for macros that contain repetitive expansions? (Is that even possible to detect?)
modify labels: A-lint T-compiler
Would be great to get that fixed till it is part of the next stable release.
This seems to occur first on nightly-2019-11-02
nominating for discussing at T-compiler + T-lang meeting, namely to take peoples' temperature with respect to the idea of just not linting this case when the flagged code appears as part of a macro definition.
also, marking as P-high w.r.t. answer the question(s) posed here. (I personally don't think the severity of the actual impact is likely to be worth a P-high rating; the priority is likely just temporary until the discussion happens.)
The language team discussed this last week. The general consensus was that we can stop linting when the redundant parens are inside the macro (as opposed to e.g. where the spans are from the outside). We believe this is fine as the lint is mostly a style thing which does not protect from anything correctness or performance related.
I've played a bit around with this issue today.

Seems like conditions need to be adjusted to also check if we are in macro expanded code. I've tried something like but that does remove more warnings that we want.
I think the questions have been basically answered in terms of what path we see best going forward. Self-assigning, removing I-nominated.
Change:
_ => {} } <ins> match None { <Defaulted as consts::AssocConst>::SOME  => panic!(), //~^ must be annotated with `#[derive(PartialEq, Eq)]` //~| must be annotated with `#[derive(PartialEq, Eq)]` _ => {} } </ins> }

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --I don't have a reasonable sized reproducer 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. --: Regression occurred ~between ..~ in () <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Updated the issue description with a complete backtrace that has full line info (435 frames deep!)
Update: I bisected this to () cc
it looks like this match needs to be updated somehow: Does this bug report contain enough information to understand the problem, or do you need an MCVE?
Could you reproduce but debug print the the scrutinee in the arm?
I'm surprised since we should return before calling for all other types. It must be one of the variants. That means we're using the of the associated const definition instead of the declaration. Maybe a defaulted associated const? I dunno.
Indeed, here's the source for the item being checked (specifically, ):
Ah okay. We should already be encoding the s for associated type defaults. If so, just adding an would resolve the issue. I think I can synthesize a test case from here though, so don't worry about reducing further. Thanks for the help!
No problem! Since I'd kicked this off already, here's the debug print:
Change:
discussed above in "[Foreign Calling Conventions](ffi.html#foreign-calling-conventions)". The `no_mangle` attribute turns off Rust's name mangling, so that it is easier to link to. <ins> # FFI and panics It’s important to be mindful of `panic!`s when working with FFI. This code, when called from C, will `abort`: ```rust #[no_mangle] pub extern fn oh_no() -> ! { panic!("Oops!"); } # fn main() {} ``` If you’re writing code that may panic, you should run it in another thread, so that the panic doesn’t bubble up to C: ```rust use std::thread; #[no_mangle] pub extern fn oh_no() -> i32 { let h = thread::spawn(|| { panic!("Oops!"); }); match h.join() { Ok(_) => 1, Err(_) => 0, } } # fn main() {} ``` </ins>

Discussion:
If C calls into a Rust function that panics it's Undefined Behaviour if it's not caught before the FFI boundary. You need to spawn a thread (stable) or catch_panic (unstable) if you can panic. Similarly if e.g. C++ unwinds into Rust this is also Undefined Behaviour, though this is perhaps out of scope as a "Rust" problem.
It looks like panics are turned into aborts on the boundaries of functions with non-Rust ABI. But it should probably be documented anyway.
yeah, it's in the reference, but not in the book