jiebi/CodeConvo huggingface dataset:
Change:
/// # Examples /// /// ``` <del> /// #![feature(arc_mutate_strong_count)] /// </del> /// use std::sync::Arc; /// /// let five = Arc::new(5); /// /// unsafe { ///     let ptr = Arc::into_raw(five); <del> ///     Arc::incr_strong_count(ptr); </del> <ins> ///     Arc::increment_strong_count(ptr); </ins> /// ///     // This assertion is deterministic because we haven't shared ///     // the `Arc` between threads.

Discussion:
<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilisation. Make sure to include the relevant RFC for the feature if it has one. Otherwise provide a short summary of the feature and link any relevant PRs or issues, and remove any sections that are not relevant to the feature. Remember to add team labels to the tracking issue. For a language team feature, this would e.g., be . Such a feature should also be labeled with e.g., . This label is used to associate issues (e.g., bugs and design questions) to the feature. --The feature gate for the issue is . <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [x] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide]) [x] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide]) [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev- <!-- Include any open questions that need to be answered before the feature can be stabilised. --- [ ] Can we improve the docs phrasing on ? <!-- Include a list of all the PRs that were involved in implementing the feature. --- Initial PR in Stabilization PR in
Hello Would it make sense to also include similar methods for Rc? And possibly similar ones to both Weaks? It would be in part for the sake of completeness, but I do some manipulation like this in the arc-swap crate and if this would become the „official“ way, it would be nice to be supported on all the related types.
I think that's a great idea, and we should file follow-up issues to implement those.
Change:
<del> // min-lldb-version: 310 // We have to ignore android because of this issue: // https://github.com/rust-lang/rust/issues/74847 // ignore-android // // We need to use inline assembly, so just use one platform // only-x86_64 // compile-flags:-g // === GDB TESTS =================================================================================== // gdb-command:run // gdb-command:info args // gdb-check:No arguments. // gdb-command:continue // === LLDB TESTS ================================================================================== // lldb-command:run // lldb-command:frame variable // lldbg-check:(unsigned long) = 111 (unsigned long) = 222 // lldbr-check:(unsigned long) = 111 (unsigned long) = 222 // lldb-command:continue #![feature(asm)] #![feature(naked_functions)] #![feature(omit_gdb_pretty_printer_section)] #![omit_gdb_pretty_printer_section] fn main() { naked(111, 222); } #[naked] extern "C" fn naked(x: usize, y: usize) { unsafe { asm!("ret"); } // #break } </del>

Discussion:
When compiling () The generated assembly includes a prologue with unexpected 's (as well as a trailing , already reported in ) Expected behaviour would be to have no prologue (and prevent compilation of a function that is not as this would require implementing an undefined ABI, contrarily to what seems to happen ). This is treacherous, as it dereferences some memory locations that may not be accessible, as happened to me and led to hours of debugging to finally figure out the compiled function was not the one defined. cc
IIRC this is invalid and rustc should reject such a function, naked functions can't take arguments and the compiler should probably enforce that.
Hmm, my understanding of the RFC (“The following variant is not an error because the C calling convention is well-defined and it is thus possible for the programmer to write a conforming function”, even if the example is not with an argument) would mean that if the function is declared , then the function can actually respect the said ABI, thus should be well-formed?
Is there an update on this? I was hit by this issue as well. I hit the problem when compiling a tock app (baremetal-ish and jumped to by the tock OS) A naked function with arguments would produce this prolog (RV32): Which would result in an invalid access as s0 would be 0. Removing the arguments would remove the prologue and fix the problem. Removing the naked cfg would also work as teh stack pointer was already setup by the OS and result in this. If arguments with naked functions aren't supported rustc should generate an error as this is a difficult problem to debug.
This is an LLVM bug. Has it been reported upstream?
Change:
} _ => { // FIXME <del> bug!(); </del> <ins> bug!("invalid expression: {:?}", expr); </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</detailsThis is a recent regression, since we run this command every day in automation.
Almost certainly a regression from /cc
looks like a duplicate of

<!-- 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. --reduced from <!-- 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. --repo @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Its a regression from but fortunately the fix is relatively easy. I'll provide a PR soon,

<!-- 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. --code from <!-- 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. --repo is @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
another one: another one:
I am on it
Same issue happened after upgraded to the latest version today.
Yes the has not landed yet.
Change:
} } <ins> pub fn cvt_nz(error: libc::c_int) -> crate::io::Result<()> { if error == 0 { Ok(()) } else { Err(crate::io::Error::from_raw_os_error(error)) } } </ins> // On Unix-like platforms, libc::abort will unregister signal handlers // including the SIGABRT handler, preventing the abort from being blocked, and // fclose streams, with the side effect of flushing them so libc buffered

Discussion:
In libstd/sys/unix there are numerous cases where return code is checked for error using following pattern: That means, that error checking is performed only when compiled in non-optimized mode or after explicitly enabling debug assertions. This is a little bit worrying, especially when used on platforms where those functions can indeed fail and break safety.
(For anyone who was confused by the given example, pthreadmutexattrinit can fail with ENOMEM.)
On some platforms types like pthreadmutext, pthreadcondt, etc., are "fat" structures that have sufficient size to hold everything necessary and their initialization will never fail (unless initialized incorrectly). But on others they are opaque pointers to and require an additional memory allocation. Search for those typedefs in libc crate, gives a rough approximation of affected platforms. Sadly this also affects static mutexes, so even lock / unlock could potentially fail. Either way you could end up with a mutex which is not mutually exclusive at all.
When mutex initialization fails this leads to non-functioning mutex and unsoundness. The pthreadmutexlock might also fail for recursive mutexes used in std::io and cause a mismatch in the number of locks / unlocks, but one needs to go out of the way to cause that. modify labels: C-bug I-unsound
Change:
/// /// `relative_path` should be relative to the root of the git repository, not an absolute path. pub(crate) fn update_submodule(&self, relative_path: &Path) { <del> fn dir_is_empty(dir: &Path) -> bool { t!(std::fs::read_dir(dir)).next().is_none() } </del> if !self.config.submodules(&self.rust_info()) { return; }

Discussion:
This might not be a valid request (I have to tell it what to test), but surely it shouldn't just result in such an obscure panic. Cc
you don't have dir ?
it doesn't exists until fetching the submodule
Seems like I don't have that submodule checked out; I don't work on the book so it's not needed (and I keep the checked-out submodules to a minimum to avoid having to update them all the time).
I reproduced it in local, without in and don't update submodule manually, will fail like this.
I can fix it tomorrow, feel free to work on it if you want to fix it earlier.
by the way, do you know why we use those for here?
Not particularly, I am not so familiar with the compiletest code. Probably we panic there so the compiletest runner process can handle(being able to understand compiletest was failed) that.
The fix shouldn't make any changes on the compiletest side. We just need to avoid using submodules(if doesn't exists) instead of assuming that they exist.
Yes, that's another issue, I just met it today.
Change:
# Strings Strings are an important concept for any programmer to master. Rust's string <del> handling system is a bit different than in other languages, due to its systems </del> <ins> handling system is a bit different from other languages, due to its systems </ins> focus. Any time you have a data structure of variable size, things can get tricky, and strings are a re-sizable data structure. That said, Rust's strings also work differently than in some other systems languages, such as C.

Discussion:
There are a number of small typos in the guide, and some of the prose could be tightened up or clarified. In general the tone of the guide comes across as trying too hard to be chatty. Keeping things casual is probably a good idea for Rust's introductory document, but we can probably remove most (all?) of the chatty prose without becoming stodgy or boring.
The guide is inconsistent with its use of certain conventions. These don't really have a correct form, but a single style should be enforced. Single-quotes () versus double-quotes () in prose. Example: Periods and commas within quotes versus without. Example: "different from" versus "different than". Example: "filename" versus "file name"
If you find any obvious errors, or think you can write a section in a better way, please don't hesitate to submit a PR with a fix. You don't need to compile a compiler or download the source to edit the guide. You can do it all in github's ui, for the most part.
thanks for being specific. And for your earlier pull request. As for these... They should be double quotes. Ideally, they'd even be actual curlies rather than . Periods and commas go within in almost all cases. In both of the cases you show, they should go inside. "Different from" vs. "Different than" isn't something that's generally settled. Some styles choose it in different situations, others say "from" is the only correct way to say this. "file name" is my preferred way, though there's no specific actual guidance.
Change:
*[false] a } `for` parameter list <ins> parse_fn_trait_missing_paren = `Fn` bounds require arguments in parentheses .add_paren = add the missing parentheses </ins> parse_forgot_paren = perhaps you forgot parentheses? parse_found_expr_would_be_stmt = expected expression, found `{$token}`

Discussion:
It feels like rustc should be able to determine that a trait followed by a is a -family trait bound and be able to suggest this behavior. If that is too general it could just check for , , . Very similar is if parenthesis are missing from regular declarations: Also happens on nightly according to Rust Playground. I'd like to try my hand at implementing this diagnostic, but I'll likely need a little bit of locational guidance. A naive code search show that the message is emitted by this code is the parser diagnostics, but I'm not sure if the adjustment would need to be made within that or from where it is invoked in this case. Edit: Updated to use the wording "-family trait bounds" rather than "HRTBs"._
Where this function is invoked. Try looking for the code that parses .
If you end up writing a fix, note that those trait bounds are usually called -family trait bounds, not “HRTBs”. The latter would require at least one higher-rank parameter to be involved (e.g. ).
It seems this diagnostic contextually comes from which does this token search by . As corroboration it also seems that declaring a regular without parenthesis causes a similar if more contextually understandable error: I naively think that the adjustment point should probably be rather than ... However I don't understand how the output gets multiple possibilities e.g. and in this output: or the whole list of Since it's only calling with from ... I guess this requires catching the result in and handling this result type somehow?
Any time you call , it stashes the token type you tried probing for and it'll present that in a list whenever you get to . (Or something like that).
Anyways, it shouldn't matter -- in the caller to (when parsing ), you could add a check for before calling and handle the token specifically.
Just chiming in to mention: in any parser change you make here make sure you don't start accepting new code and add tests for all combinations you can think of.
Change:
if Q::in_adt_inherently(cx, def, substs) { return true; } <ins> if def.is_union() && Q::in_any_value_of_ty(cx, rvalue.ty(cx.body, cx.tcx)) { return true; } </ins> } // Otherwise, proceed structurally...

Discussion:
For example, after laundering interior mutability through a union, a resulting constant undergoes promotion: label +A-const-eval +F-untagged_unions
Yea, unions should not be "more powerful" than a plain transmute imo. cc
I assume with transmute one can also produce a similar example as the OP? So in which sense are unions more powerful than transmute, Why does this example behave any different than the following?
The union local initially starts without interior mutability qualif. This persist after the first assignment, since u32 does not have interior mutability The move from the cell variant is qualified based on the qualification of the local, so the overall constant is consider not to have interior mutability. The use of the constant in the main function is promoted and fails dynamic checks.
I totally forgot promotion of looks into the definition of ... that'll continue to haunt us for a while I think. :/ Yeah, the analysis clearly is wrong for reading from union fields. But even for values like , I have no idea what the wider consequences are (given that the type is considered interior mutable).
The example can be also modified by moving union access to the runtime code, in which case it will compile successfully, with promoted being placed in .rodata section: In the context of static analysis, I think it would make sense to use strictly type based analysis for unions, in which case the first assignment to a union local would already qualify the local as having interior mutability.
But also, there's supposed to be a 2nd line of defense in our interning code that is somehow failing.
Turns out interning relies in validity checking for this: The example in the OP was caught by validity, so that is good. But the 2nd example was not caught, because we never actually hit an UnsafeCell -- we stop at the union boundary. So maybe the union part of the visitor should also have the kind of ?
do we have an established approach to testing that this second line of defense works? Carefully crafted constant with undefined behaviour might do its job in this case (not sure yet), but maybe we have better alternatives?
We have -Zunleash-the-miri-inside-of-you but that only helps for checks, not for promoted restrictions... I don't think we have anything for promoteds (and it seems non-trivial, we would need a way to force something to be promoted despite it violating the usual conditions).
Change:
<ins> error[E0308]: mismatched types --> $DIR/return-dyn-type-mismatch.rs:15:21 | LL |     fn other_func() -> dyn TestTrait<MyType = T> { |                        ------------------------- expected `(dyn TestTrait<MyType = T> + 'static)` because of return type LL |         match Self::func() { LL |             None => None, |                     ^^^^ expected `dyn TestTrait`, found `Option<_>` | = note: expected trait object `(dyn TestTrait<MyType = T> + 'static)` found enum `Option<_>` error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </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
bisected to cc
This can be made to ICE on stable as well:
duplicate of

<!-- 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
almost exactly 3 years old :cake: :partying_face: :pinata: searched toolchains nightly-2020-04-17 through nightly-2023-04-22 Regression in nightly-2020-04-23 found 7 bors merge commits in the specified range commit[0] 2020-04-21: Auto merge of - spastorino:dyn-fnonce-alignment, r=nikomatsakis commit[1] 2020-04-22: Auto merge of - ehuss:update-cargo, r=ehuss commit[2] 2020-04-22: Auto merge of - JohnTitor:rollup-vh6dut5, r=JohnTitor commit[3] 2020-04-22: Auto merge of - nnethercote:bitcode-in-rlib, r=alexcrichton commit[4] 2020-04-22: Auto merge of - Dylan-DPC:rollup-iunh61a, r=Dylan-DPC commit[5] 2020-04-22: Auto merge of - nnethercote:alphabetize-C-and-Z-options, r=petrochenkov commit[6] 2020-04-22: Auto merge of - Dylan-DPC:rollup-rvm6tfy, r=Dylan-DPC probably ? cc
I feel like i've seen this before -- probably a dupe? Or at least I think I've chatted with about this.
Could be :D probably 90% of the ICEs I am seeing are already reported in some way or another and sometimes one might slip through
different stacktrace with debug assertions: `
Change:
gid: None, saw_nul, closures: Vec::new(), <ins> groups: None, </ins> stdin: None, stdout: None, stderr: None,

Discussion:
already offers and methods to control the user identity of the child process (calling respectively). For complete control of Unix credentials, there should also be a way to call and the concept of the supplementary group list are; I would expect this not to be a portability concern.) This feature would eliminate a use of and an unsafe block (to call ) from the program I'm currently writing, which is a port to Rust of a setuid C program. For illustration, this function exists in the C version: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I would be prepared to consider a PR to add .
claim
Change:
// The collapse-docs pass won't combine sugared/raw doc attributes, or included files with // anything else, this will combine them for us. if let Some(doc) = attrs.collapsed_doc_value() { <del> self.collector.set_position(attrs.span.unwrap_or(DUMMY_SP)); </del> <ins> // Use the outermost invocation, so that doctest names come from where the docs were written. let span = attrs .span .map(|span| span.ctxt().outer_expn().expansion_cause().unwrap_or(span)) .unwrap_or(DUMMY_SP); self.collector.set_position(span); </ins> markdown::find_testable_code( &doc, self.collector,

Discussion:
Doctest test names have changed due to . Doc comments that pass through a macro defined in another crate now seem to report a different span. /// assert!(true); /// running with previously looked like this: Now the test names look like this: Frankly, neither are particularly great. It would be nice if the test name used the span from where the macro was invoked, not where it was defined.
I think this also affects normal backtraces :( Just got this rather unuseful backtrace while bootstrapping: full:
cc
What you're describing is entirely in the opposite direction, is the old (and arguably bad) kind of that's impossible to get anymore. I've hidden your comment to focus on the reported issue.
That makes sense, we have a way to get the outermost invocation, that is used by / and : We'd just need to use this in .
cc
cc
Removed label, left nomination for to decide about this issue.
Well, using what suggested seems like the best thing to do.
Change:
<ins> error: expected expression, found `=` --> $DIR/js-style-comparison-op-separate-eq-token.rs:2:13 | LL |     if 1 == = 1 { |             ^ expected expression error: aborting due to previous error </ins>

Discussion:
Been working in JavaScript a lot lately and find myself accidentally typing this a lot. It would be nice to automatically detect this and offer a proper fix. Lots of languages use this syntax in addition to JavaScript so it seems like a reasonable error to make. Playground example below. () Errors:
I think the current error message is clear enough. Also I don't think providing auto-fix suggestion is easy, because the error happened when parsing AST.
Nice. But I still think the current error message is fine as is.
don't disagree, but handling it was relatively easy because there's no case where would be valid.
Change:
struct SourceFileIndex(u32); #[derive(Copy, Clone, Debug, Hash, Eq, PartialEq, Encodable, Decodable)] <del> pub struct AbsoluteBytePos(u32); </del> <ins> pub struct AbsoluteBytePos(u64); </ins> impl AbsoluteBytePos { fn new(pos: usize) -> AbsoluteBytePos { <del> debug_assert!(pos <= u32::MAX as usize); AbsoluteBytePos(pos as u32) </del> <ins> AbsoluteBytePos(pos.try_into().expect("Incremental cache file size overflowed u64.")) </ins> } fn to_usize(self) -> usize {

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. --You can find it at : <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
cc
Hi, is there any updates on this? We met this problem in with on too:
This is a bug in incremental compilation. Do you have both the last compiling version and the failing version?
Sorry I didn't understand the sentence. The simplest way to reproduce this ICE:
We're sincerely longing for the merge of your bug fix.