jiebi/CodeConvo huggingface dataset:
Code change:
ty::ty_struct(id, _) => { for field in fields { self.check_field(pattern.span, id, <del> NamedField(field.node.ident)); </del> <ins> NamedField(field.node.ident.name)); </ins> } } ty::ty_enum(_, _) => {

Related discussion:
text: Here is why: It is relatively easy for a developer who wants to provide that sort of extensible abstraction can still do it, by factoring the type into a all-public front-end with a single public field that holds the all-private back-end, like so: So, given that there exists a reasonable pattern to bring back usable FRU even under the option "(3.) change FRU into a non-hygienic expansion into the record construction form with all fields listed, in the sense that is synonymous with and subject to privacy checks.", I would not object to us adopting (3.) aka solution.
I think that "has any private field" is a decent way to handle abstractness (you can always add a private unit field). On the other hand, Rust supports trait bounds of types – these should handle roles just fine – you shouldn't be able to coerce past a trait bound. By the way, this is somewhat subtle, because coercing to is wrong (as it leaks memory – it coerces past the implicit bound), but coercing to is fine (as the bound isn't used by ). However, this isn't a property of – you still can't coerce to – so we probably want a relatively-sophisticated way to occasionally ignore roles.
I mean, Rust already has a mechanism for ensuring representation-abstraction – private fields – which are semantic (they are handled after type-checking, we probably want to handle them during it, but they definitely aren't handled syntactically or during resolution). It is just that FRU currently accesses them improperly. Also, it doesn't have much to do with e.g. roles – is an abstract type, but it doesn't use any bound on . only uses the implicit bound. A for data-only types would be nice, through.
Another alternative came to me while I was drafting an RFC about this. (But its an alternative that I do not particularly like.) 8a Instead of making "has any private fields" the thing that makes FRU unavailable, instead make the rule be "has all private fields." Thus types like and will not be subject to the vulnerability outlined here. Adding a single field to an otherwise private struct is what changes the nature of a struct with respect to abstraction and FRU, rather than adding a single non- field to an otherwise public struct.
Code change:
ty::ty_struct(id, _) => { for field in fields { self.check_field(pattern.span, id, <del> NamedField(field.node.ident)); </del> <ins> NamedField(field.node.ident.name)); </ins> } } ty::ty_enum(_, _) => {

Related discussion:
text: 8b, which is so similar to 8a that I gave them both the same numeral: Outlaw the trivial FRU form . That is, to use FRU, you have to use at least one field in the constructing expression. Again, this implies that types like and will not be subject to the vulnerability outlined here. (This may be a decent change to make to the language regardless of whatever else happens on this ticket; the only argument in favor of keeping support for such a trivial form is maybe for supporting certain macro-expansions. But fully-general macro-authors already have to tread very carefully around corner cases on structs, due to issues like the empty braces problem (see )
That would leave the vulnerability intact in the case where the type has both public fields and private fields, the fact that no such type currently exists in the standard library notwithstanding (just as a very artificial demonstration, consider a with ).
yep. Library authors would have to factor their structures very carefully. (I described the drawback you mention in the RFC I posted shortly after you wrote your comment, though I did not include the detail of having the private fields be , which does seem like it could make the situation all the more subtle. Not insurmountable, but a definite drawback.) Just to be clear, I'm not saying I prefer (8a) or (8b); I'm just trying to be complete in my exploration of the solution space.
Repurposed as the tracking issue for rust-lang/rfcs
I'll just go snag
Code change:
margin: 0 auto; padding: 0 15px; font-size: 18px; <del> color: #333; </del> <ins> color: #000; </ins> line-height: 1.428571429; -webkit-box-sizing: unset; -moz-box-sizing: unset; box-sizing: unset; <ins> background: #fff; </ins> } @media (min-width: 768px) { body {

Related discussion:
text: When running , this file is opened for me . I thought I'd use that file in my note taking application, which I have set to a dark theme. However for in that documentation is set to have the and the background uses the default color. This leads to the text becoming hard to read. ! I would prefer the text color not to be explicitly set, or if you insist on the dark gray text, making sure that the background color is also set to something light.
Transferred to rust-lang/rust. The CSS for this lives at
It's not rustdoc so to speak. I'll fix the issue.
Code change:
<ins> // Copyright 2012-2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // Make sure this compiles without getting a linker error because of missing // drop-glue because the collector missed adding drop-glue for the closure: fn create_fn() -> Box<Fn()> { let text = String::new(); Box::new(move || { let _ = &text; }) } fn main() { let _ = create_fn(); } </ins>

Related discussion:
text: I found that current rustc 1.13.0-nightly can't compile'Rust by Example - 8.2.5 As output parameters' code, both on my linux pc and . I tried this code: see Executing code above on Rust Playground produces the message below when selecting nightly. ( but stable and beta do not produce this error). error: linking with failed: exit code: 1 | = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/usr/local/lib/rustlib/x8664-unknown-linux-gnu/lib" "./out.0.o" "-o" "./out" "-Wl,--gc-sections" "-pie" "-nodefaultlibs" "-L" "/usr/local/lib/rustlib/x8664-unknown-linux-gnu/lib" "-Wl,-Bstatic" "-Wl,-Bdynamic" "/usr/local/lib/rustlib/x8664-unknown-linux-gnu/lib/libstd-" "/usr/local/lib/rustlib/x8664-unknown-linux-gnu/lib/libpanicunwind-" "/usr/local/lib/rustlib/x8664-unknown-linux-gnu/lib/libunwind-" "/usr/local/lib/rustlib/x8664-unknown-linux-gnu/lib/librand-" "/usr/local/lib/rustlib/x8664-unknown-linux-gnu/lib/libcollections-" "/usr/local/lib/rustlib/x8664-unknown-linux-gnu/lib/librustcunicode-" "/usr/local/lib/rustlib/x8664-unknown-linux-gnu/lib/liballoc-" "/usr/local/lib/rustlib/x8664-unknown-linux-gnu/lib/liballocjemalloc-" "/usr/local/lib/rustlib/x8664-unknown-linux-gnu/lib/liblibc-" "/usr/local/lib/rustlib/x8664-unknown-linux-gnu/lib/libcore-" "-l" "dl" "-l" "pthread" "-l" "gccs" "-l" "pthread" "-l" "c" "-l" "m" "-l" "rt" "-l" "util" "-l" "compiler-rt" = note: ./out.0.o: In function drop::hf3564cae7b79f1cb': (.text.
Code change:
<ins> // Copyright 2012-2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // Make sure this compiles without getting a linker error because of missing // drop-glue because the collector missed adding drop-glue for the closure: fn create_fn() -> Box<Fn()> { let text = String::new(); Box::new(move || { let _ = &text; }) } fn main() { let _ = create_fn(); } </ins>

Related discussion:
text: ZN4drop17hf3564cae7b79f1cbE+0xd): undefined reference toLTGTasGT$::drop::h4c07c16183524d21' ./out.0.o: In function drop::hc5f0e028c3876d25': (.text.ZN4drop17hc5f0e028c3876d25E+0xd): undefined reference toLTGTasGT$::drop::h7a8bb753832b1af2' collect2: error: ld returned 1 exit status error: aborting due to previous error Compilation failed. This happens on my Linux Laptop pc as well. This is my laptop's rustc version(installing current latest) . : rustc 1.13.0-nightly ( 2016-08-25) binary: rustc commit-hash: commit-date: 2016-08-25 host: x86_64-unknown-linux-gnu release: 1.13.0-nightly
Nominating since this appears to be a regression.
is still good, does not exist and fails. . Reduced:
This may be a related to . Edit: not a duplicate I think, since was introduced in a different nightly.
Running with the above sample and leads to an ICE in printing a log message
This is from the removal of old trans. We should've been covered by on-demand drop glue generation still, though. cc
Looking at the IR - the missing methods are d, and called from drop methods taking e.g.
Oh, this is bad. The collector needs to know user definitions being instantiated ahead of time (including impls), and these can be used from drop glue which is not guaranteedly known ahead of time. We might need to temporarily detect the shim'd cases in the collector and trigger drop glue generation. cc
I'm looking into a short-term fix right now.
yay! Thanks
Code change:
true } }) <ins> // ensure that we don't suggest unstable methods .filter(|candidate| { // note that `DUMMY_SP` is ok here because it is only used for // suggestions and macro stuff which isn't applicable here. !matches!( self.tcx.eval_stability(candidate.item.def_id, None, DUMMY_SP, None), stability::EvalResult::Deny { .. } ) }) </ins> .map(|candidate| candidate.item.ident(self.tcx)) .filter(|&name| set.insert(name)) .collect();

Related discussion:
text: It would be more helpful to suggest the method for the typo rather than a nightly-only symbol which isn't actually available. the suggestion doesn't work. method is actually available on a . method has been stable since 1.0.0. had trouble noticing the difference between and and could have used the compiler's help. No response Reproduced with 1.68.0 stable and 1.70 nightly. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim
Code change:
} as usize; if k == n && c::GetLastError() == c::ERROR_INSUFFICIENT_BUFFER { n *= 2; <del> } else if k >= n { </del> <ins> } else if k > n { </ins> n = k; <ins> } else if k == n { // It is impossible to reach this point. // On success, k is the returned string length excluding the null. // On failure, k is the required buffer length including the null. // Therefore k never equals n. unreachable!(); </ins> } else { return Ok(f2(&buf[..k])); }

Related discussion:
text: Looking at without prior knowledge of Windows system call semantics, I see an infinite loop if the syscall were to fill up the buffer exactly: when k == n on line 195, the loop will be rerun with no changes, which should result in the exact same outcome if the syscall is idempotent. Even if Windows guarantees in some way that this cannot happen, would it not be clearer to handle this case in an obvious fashion?
Here's one of the docs on how usually works in Win32: Note the difference in lengths between success and failure. So there's two potential cases where : Success: If the buffer size (with NULL) were to be equal to the successfully copied size (without NULL) then the buffer would be too small to hold the full string (NULL included). So this can't happen. Failure: If the buffer size (with NULL) were to be equal to the buffer size needed (with NULL) then the string would have been successfully copied into the buffer. So this can't happen. So Windows does indeed guarantee this can't happen.
OTOH on some versions returns the size written including the NUL terminator, so for that function the infinite loop could happen, right? The doubling logic that checks for the insufficient buffer error code must be there for some other function that I have not yet found, it would be great to have a comment as to where this behavior is needed.
As far as I know Rust only ever uses the Unicode version of functions (they end in ) and never the "ANSI" ones (they end in ). The functions are more consistent across Windows versions. I'm not at all against adding a comment (and returning an error?) in this case but it's not something that should ever happen with the kinds of APIs Rust uses.
Come to think of it pretty much implies using the functions. It uses a buffer, where as the functions use a buffer. Using this function with the functions would be very broken.
Still, it would be more robust to change the into , so treat this presumed impossible case as success (absent other evidence) rather than looping.
My issue with assuming success is that we can't know what a hypothetical Win32 function is doing in this case. For example, it may have truncated the output or it may even be returning an error code, not a size. We can only guess. Best case is we guess right and it works.
Code change:
} as usize; if k == n && c::GetLastError() == c::ERROR_INSUFFICIENT_BUFFER { n *= 2; <del> } else if k >= n { </del> <ins> } else if k > n { </ins> n = k; <ins> } else if k == n { // It is impossible to reach this point. // On success, k is the returned string length excluding the null. // On failure, k is the required buffer length including the null. // Therefore k never equals n. unreachable!(); </ins> } else { return Ok(f2(&buf[..k])); }

Related discussion:
text: Worse case is we guess wrong and it causes a bug that only becomes apparent later on, making the source of the bug hard to track down. Having given more thought to this, I'm leaning towards using . That would clearly document that the case is thought impossible, while also causing a panic if the function is misused. It might also be good to clearly document the expected return for the function being passed in. E.g.: On success returns the size of the copied string excluding the terminating null. On error returns zero unless the last-error code is set to . If the last-error code is returns the buffer size required, including space for a terminating null.
Yes, that sounds like a good improvement! Since this Win32 behavior is not generically documented, it might also be good to note the exact syscalls that this function has been tested with. I should probably mention that I don’t have a Windows system to develop or test this on, I was merely perusing the code out of curiosity — otherwise I’d volunteer a PR.
Code change:
/// The root of the normal must_use lint with an optional message. Def(Span, DefId, Option<Symbol>), Boxed(Box<Self>), <ins> Pinned(Box<Self>), </ins> Opaque(Box<Self>), TraitObject(Box<Self>), TupleElement(Vec<(usize, Self)>),

Related discussion:
text: <!-- 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. --Defining traits that contain methods that return such a type: The compiler should probably have warned me about not using the of the , consistent with the behaviour of async functions in Rust 1.67.0. This will also work without the need for traits but async traits is one of the most common use cases for such a type. <!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
We looked at this as the wg-async triage meeting today. We agree this is a bug and that the behavior should be consistent with on and/or . This is also likely a good first issue for someone wanting to contribute to async.
Would you say this is also a good issue for a first-time contributor to Rust? I'm not super familiar with the language, but I want to contribute to open source compilers, so I'm hoping to potentially take on this task.
Can I take this ?
Either one of you ( or are welcome to work on this! If it's your first time contributing to Rust, it might take a while to ramp up on it, but I find the best way to do that is to just do it. If you decided to have a go at it, feel free to ask any questions you have either here or in . I tend to watch #wg-async closer than GitHub issues, so you'll probably get a more prompt reply there.
this issue wasn't claimed so you are free to claim and work on it if you still are interested. Kindly comment with to claim the issue.
claim
This is also a very special case of
Code change:
<ins> // Test for <https://github.com/rust-lang/rust/issues/66756> // check-pass #![feature(const_if_match)] enum E { A, B, C } const fn f(e: E) { match e { E::A => {} E::B => {} E::C => {} } } fn main() {} </ins>

Related discussion:
text: Example: CC: ,
The error is emitted from . Adding does enable the example above. Interestingly, no terminator appears in the MIR for that function. This suggests that we are running const checks before a cleanup pass that removes terminators for exhaustive expressions. We have a few choices here. I am leaning towards just removing from the checks. What do you think? cc
Let's gate the removal on for now to make sure we don't accidentally allow anything on stable.
Oh yea, I just left it in there so we don't accidentally allow something. I couldn't figure out how to trigger it, so I preferred to deny it.
Code change:
pub trait Index<Idx: ?Sized> { /// The returned type after indexing. #[stable(feature = "rust1", since = "1.0.0")] <ins> #[rustc_diagnostic_item = "IndexOutput"] </ins> type Output: ?Sized; /// Performs the indexing (`container[index]`) operation.

Related discussion:
text: I tried this code (): I expected to see this happen: rustc outputs an error saying that I need to add the and traits on . Instead, this happened: which is jarring to see, and unhelpful, because HashMap does support Index, but only with particular trait bounds on . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
The reduced case: works as expected, perhaps it is caused when the implementer is not from the local crate?
claim
Code change:
sidebarElems.appendChild(ul); } <ins> function expandAllDocs() { const innerToggle = document.getElementById(toggleAllDocsId); removeClass(innerToggle, "will-expand"); onEachLazy(document.getElementsByClassName("rustdoc-toggle"), e => { if (!hasClass(e, "type-contents-toggle")) { e.open = true; } }); innerToggle.title = "collapse all docs"; innerToggle.children[0].innerText = "u2212"; // "u2212" is "−" minus sign } </ins> <del> function labelForToggleButton(sectionIsCollapsed) { if (sectionIsCollapsed) { // button will expand the section return "+"; } // button will collapse the section // note that this text is also set in the HTML template in ../render/mod.rs return "u2212"; // "u2212" is "−" minus sign </del> <ins> function collapseAllDocs() { const innerToggle = document.getElementById(toggleAllDocsId); addClass(innerToggle, "will-expand"); onEachLazy(document.getElementsByClassName("rustdoc-toggle"), e => { if (e.parentNode.id !== "implementations-list" || (!hasClass(e, "implementors-toggle") && !hasClass(e, "type-contents-toggle")) ) { e.open = false; } }); innerToggle.title = "expand all docs"; innerToggle.children[0].innerText = "+"; </ins> } function toggleAllDocs() {

Related discussion:
text: Take any page in the Rust docs, for example . When you press the or keyboard shortcuts on your keyboard, they are supposed to either collapse or expand all items on the page, but not both (according to the instructions that you can find by clicking on your keyboard (or on the screen). Please make the + and - keyboard shortcuts idempotent, otherwise it would be redundant to have two buttons that do the same thing.
What do you think about this ?
Yeah we should do this.
I'll send a patch in the next days then.
Code change:
string.push(CodePoint::from_u32(0xD800).unwrap()); check_utf8_boundary(&string, 3); } <ins> #[test] fn wobbled_wtf8_plus_bytes_isnt_utf8() { let mut string: Wtf8Buf = unsafe { Wtf8::from_bytes_unchecked(b"xEDxA0x80").to_owned() }; assert!(!string.is_known_utf8); string.extend_from_slice(b"some utf-8"); assert!(!string.is_known_utf8); } #[test] fn wobbled_wtf8_plus_str_isnt_utf8() { let mut string: Wtf8Buf = unsafe { Wtf8::from_bytes_unchecked(b"xEDxA0x80").to_owned() }; assert!(!string.is_known_utf8); string.push_str("some utf-8"); assert!(!string.is_known_utf8); } #[test] fn unwobbly_wtf8_plus_utf8_is_utf8() { let mut string: Wtf8Buf = Wtf8Buf::from_str("hello world"); assert!(string.is_known_utf8); string.push_str("some utf-8"); assert!(string.is_known_utf8); } </ins>

Related discussion:
text: Reviewing PR had some oversight regarding valid utf8 checks. This was graciously brought to our (meaning myself and attention by in . Fix should really just be changing to setting to , unless we decide there may be some merit to iterating again through the buffer.
label T-libs C-cleanup O-windows
label -needs-triage
Code change:
// check that a comma comes after every field if !ate_comma { <del> let mut err = self.dcx().create_err(ExpectedCommaAfterPatternField { span: self.token.span }); </del> <ins> let err = if self.token == token::At { let prev_field = fields .last() .expect("Unreachable on first iteration, not empty otherwise") .ident; self.report_misplaced_at_in_struct_pat(prev_field) } else { let mut err = self .dcx() .create_err(ExpectedCommaAfterPatternField { span: self.token.span }); self.recover_misplaced_pattern_modifiers(&fields, &mut err); err }; </ins> if let Some(delayed) = delayed_err { delayed.emit(); } <del> self.recover_misplaced_pattern_modifiers(&fields, &mut err); </del> return Err(err); } ate_comma = false;

Related discussion:
text: This erroneous code: Produces this error message It would be better if instead it produced an error message like this: Tried the code in these Rust versions and they all produced the same error message: 1.37.0 stable1.45.0 stable1.46.0-beta.1 (2020-07-15 )1.47.0-nightly (2020-07-22 ) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This shouldn't be too hard. This comes from the parser, specifically the code that parses a pattern, which is one of functions. Somewhere there is the code to parse a struct pattern. I assume the error above happens when it successfully parses a struct field and then expects a comma or closing brace. To fix it you'd have to check for and report a better error message.
claim
Code change:
<ins> // compile-flags: --edition 2018 #![feature(label_break_value, try_blocks)] // run-pass fn main() { let _: Result<(), ()> = try { 'foo: { Err(())?; break 'foo; } }; } </ins>

Related discussion:
text: I've been playing around with today, and it comes in super handy in blocks. However, it seems to run into issues when combined with the feature. I tried this code: I expected to see this happen: the code should compile just fine. Instead, this happened: This is a continuation of the discussion . As , this code (following the from the label-break-value RFC) compiles: : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
So the error is generated here if I had to guess, I would assume that this function ought to be modified to check whether the and, if so, not to emit the error. (See  rust docs for a bit more info.)
Tagged as E-mentor since there are some instructions above.
claim