jiebi/CodeConvo huggingface dataset:
Change:
/// Hash::hash_slice(&numbers, &mut hasher); /// println!("Hash is {:x}!", hasher.finish()); /// ``` <ins> /// /// [`VecDeque`]: ../../std/collections/struct.VecDeque.html /// [`as_slices`]: ../../std/collections/struct.VecDeque.html#method.as_slices /// [`make_contiguous`]: ../../std/collections/struct.VecDeque.html#method.make_contiguous /// [`hash`]: Hash::hash /// [`hash_slice`]: Hash::hash_slice </ins> #[stable(feature = "hash_slice", since = "1.3.0")] fn hash_slice<H: Hasher>(data: &[Self], state: &mut H) where

Discussion:
Currently is implemented as . The question is: is it a requirement for all implementations? In other words, is is true, that for each hasher implementation, call must be equivalent to ? (assuming host is little-endian). Why is it important. Suppose, you want to implement very simple hasher with state updated like . If does not have requirement as above, hasher can be implemented by simply casting any operand to and avoiding dealing with unaligned/smaller than u64 integers:
I’m fairly sure there was a discussion about it before and we decided against doing any changes to the libstd impl. Don’t exactly remember the reason, though.
If any decision is made, I wish it would be stated in the documentation of trait.
employs a different implementation to achieve platform-independence.
I don't think there's any such requirement. The in the compiler does exactly what your example does.
I think I would be opposed to this requirement; it imposes a performance penalty for systems of the "wrong" endianness, since they would need to correct their endianness. The only requirement on should be that the same sequence of calls produces the same result, I think.
My spec request: given two byte slices and , is equivalent to ? This way, we could define all the non-slice methods as explicitly being transmutes, always.
removing until lets us know what to document here.
My personal take on this is that we should only guarantee that produces the same value for the exact same sequence of calls. This even applies to plain calls on byte slices: a is only guaranteed to produce the same result if the same sequence of calls are used with the same slice lengths*. For an example of where this could make a difference, consider from Abseil which hashes short slices by reading 0-16 bytes and padding anything not included in the length with zeroes or duplicates of the existing bytes.
Based on the libs team decision in , I'm going to close this issue. The answer to the question in the issue title is no: is not required to be equivalent to 4 calls of .
Was there any updates to the documentation of Hasher? I didn't see any in a quick scan of threads.
Yeah, it seems like the thread was closed because the original idea was decided to not be done, but I agree that it shouldn't be closed until documentation is .

cc who closed this since it shouldn't be closed. Opened to add docs for this, but think this issue should be kept open until we've finally decided on how to document this.
Change:
let gcc_lld_dir = dst_dir.join("gcc-ld"); t!(fs::create_dir(&gcc_lld_dir)); builder.copy(&src_dir.join(&rust_lld), &gcc_lld_dir.join(exe("ld", compiler.host))); <ins> builder .copy(&src_dir.join(&rust_lld), &gcc_lld_dir.join(exe("ld64", compiler.host))); </ins> } // Copy over llvm-dwp if it's there

Discussion:
has progressed to the point where there is now a flag for linux builds. On a lark, I tested what happens on macos. Surprisingly, it wasn't immediately rejected. Unsurprisingly, it exploded. I'm not 100% sure if macos and linux are similar enough environments that the same mechanism should just work, but I think it should? <details<summarybuild log </summary</details
Oh interesting, ok so with it's blowing up in build scripts, but it seems to build (something with no dependencies or build scripts) fine!
(I do not have a readily available linux env to test if this failure mode is uniquely macos or just the usual "build-scripts and plugins have weird interactions with compiler flags" problem)
Using gets farther on rust-minidump's , but still blows up at the final link: <details<summarybuild log </summary</details<details<summaryfailing cc invocation broken up into lines</summary</details
Maybe your lld is too old? I can build my workspace with:
There is one binary lld and various symbolic links with different names. You have to pass for OSX and for linux. You are probably passing the wrong flavour, i.e. gnu.
Change:
* Sending signals * Accessing/modifying the file system * Unsigned integer overflow (well-defined as wrapping) <del> * Signed integer overflow (well-defined as two's complement representation </del> <ins> * Signed integer overflow (well-defined as two’s complement representation </ins> wrapping) #### Diverging functions

Discussion:
The references states that is a logical right shift, however it seems that it behaves like an arithmetic right shift for signed integers. For instance the following snippet prints : A logical right shift should produce (assuming 2's complement representation which I think rust guarantees?). In the same spirit the reference does not say if shifting outside the range of an integer is defined. From my quick test it doesn't appear to be: This prints garbage on my computer and on the playpen, so I assume it's UB or at least UV (it doesn't trigger the overflow check in debug builds though, maybe it should?) On a similar topic the reference also states that the following behaviours are safe: Unsigned integer overflow (well-defined as wrapping) Signed integer overflow (well-defined as two's complement representation wrapping) I believe that's not true anymore.
I see that checking for bitshift overflows is going to be implemented in so it seems to confirm that it's UB (UV?) for now.
see PR for the checks. We can go either way on the issue of whether overflow is UB or UV or neither. (That is, it is easy to adapt the PR accordingly; just a matter of deciding, and perhaps measuring the impact on code size, maybe.)
what's the process by which we decide that? I'd like to knock this issue out.
heh, I already made an "executive decision" (though admittedly it was one that was already in favor of), of making overflow panic when checks are on, and when the checks are off, we forcibly mask the RHS to ensure that we do not encounter weirdness such as that documented in and . (Though I still need to put in tests for that fallback behavior.)
That sounds very reasonable, thanks. Right shifts of signed values will remain arithmetic though, right? It's probably what most people will expect since that's how it's done in C/C++ and we'd have to simple way of doing arithmetic shifting otherwise.
right-shift of signed values are still arithmetic shifts, but that is independent of the overflow checking (which is based solely on the value of the right-hand-side compared to the bitwidth of the type of the left-hand-side)
Okay, that makes sense. I wanted to make sure that was the intended behaviour since the reference seems to say otherwise. Thank you!
oh I see; yes that part of the reference has probably been incorrect for a long time.
Change:
color: #c5c5c5; } body.source .example-wrap pre.rust a { <del> background: #c5c5c5; </del> <ins> background: #333; </ins> } .docblock:not(.type-decl) a:not(.srclink):not(.test-arrow),

Discussion:
Interestingly, the dark theme works fine. Screenshot of Ayu: ! cc
Sending a fix in the next few hours.
Change:
<ins> // check-pass #![feature(dyn_star)] //~^ WARN the feature `dyn_star` is incomplete and may not be safe to use and/or cause compiler crashes fn _foo() -> dyn* Unpin { 4usize } fn main() {} </ins>

Discussion:
() This happens whether or not the returned type implements the trait in question. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details modify labels +F-dyn_star
Change:
r: ty::Region<'tcx>, ) -> ty::Region<'tcx> { match *r { <del> ty::ReEarlyBound(_) | ty::ReFree(_) | ty::ReErased | ty::ReStatic => r, </del> <ins> ty::ReEarlyBound(_) | ty::ReFree(_) | ty::ReErased | ty::ReStatic | ty::ReError(_) => r, </ins> ty::ReVar(_) => canonicalizer.canonical_var_for_region_in_root_universe(r), <del> _ => { </del> <ins> ty::RePlaceholder(..) | ty::ReLateBound(..) => { </ins> // We only expect region names that the user can type. bug!("unexpected region in query response: `{:?}`", r) }

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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2023-01-01 to nightly-2023-03-11 regressed nightly: nightly-2023-03-09 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailscc
This is "due" to , but probably needs to be passed through silently in the canonicalization code.
reduced via treereduce `
I'd argue that repro is worse than the one provided at the top of the issue, even if it's a few bytes shorter. It introduces a bit of superfluous syntax/unnecessary syntax errors. Here's a denser minimization that avoids the syntax errors (except for the one that actually is the root-cause of the issue):
haha, the original snipped looked like this but I though it looked a little too weird :)
claim
Sorry for the off-topic comment: In response to this feedback I made a wrapper for treereduce that avoids introducing unrelated issues. It also runs for you (when it doesn't remove the ICE), and can output a nice Markdown comment with the reduced program.
Change:
// so we can't use it by default in general, but we can use it for tools // and our own internal libraries. if !mode.must_support_dlopen() && !target.triple.starts_with("powerpc-") { <del> rustflags.arg("-Ztls-model=initial-exec"); </del> <ins> cargo.env("RUSTC_TLS_MODEL_INITIAL_EXEC", "1"); </ins> } if self.config.incremental {

Discussion:
On , with a provided component: errors with: I'll try and see if I can reproduce it with to test suggestion:
Couldn't reproduce it with an , tried with also Does it have to be cross compiled from a different host?
Not sure what is necessary to reproduce it. In any case if you open a PR with the likely fix, I can run a try build on CI which you can then locally install to see if it fixes the issue.
Change:
(function() { if (window.playgroundUrl) { $('pre.rust').hover(function() { <del> if (!$(this).attr('id')) { return; } var id = '#' + $(this).attr('id').replace('rendered', 'raw'); </del> var a = $('<a>').text('⇱').attr('class', 'test-arrow'); <del> var code = $(id).text(); </del> <ins> var code = $(this).siblings(".rusttest").text(); </ins> a.attr('href', window.playgroundUrl + '?code=' + encodeURIComponent(code)); a.attr('target', '_blank');

Discussion:
For example, the code snippet for with suspicious muffin-related content. This seems to be the snippet for the  function (which is also the first function on the page with example code). All other code snippets on the page lead to the same muffin code. This is on Chrome 39.0.2171.95 (64-bit) on Mac OS X 10.10.1. !
It looks like this is caused by rustdoc rendering all of the examples with the same id. If you look at the playpen js code in rustdoc: you see that it depends on all the same ids being different. However, if you look at the source of the StrExt example you linked, you see they all have "rust-example-rendered-0" as the id. I think the error comes from somewhere in here, but it's not obvious to me how to fix it. I'll look into the issue, but this is my first little bit of work on rust so it may take a second/I'd appreciate insight as to what the problem might be.
nominating for I-muffins
Change:
&self.forest.krate.attrs } <del> pub fn get_module(&self, module: DefId) -> (&'hir Mod, Span, HirId) { </del> <ins> pub fn get_module(&self, module: DefId) -> (&'hir Mod, Span, HirId) { </ins> let hir_id = self.as_local_hir_id(module).unwrap(); self.read(hir_id); match self.find_entry(hir_id).unwrap().node {

Discussion:
Seems to be something to do with Rocket. Having a on the internal function is causing the compiler to blow up. Version: Stack trace:
I think this issue might be better-suited for the Rocket repository.
Ah OK. The output told me to file an issue here so I thought it might be a compiler problem rather than something specific to Rocket. Can we leave it open for a bit just until it's confirmed as Rocket-specific?
Hm, this bug probably originates with interesting codegen in Rocket, but is likely a bug in rustc in the end. I would keep it here, though letting Rocket know about it might not be a bad idea.
I'm going to label this as P-high for now since it affects Rocket. cc re. macros & privacy.
Without looking too deeply I would wager that we're getting a here, although it could be any other which would be worrisome:
Would be great to have a reproducer that did not depend on Rocket and codegen, if it is possible.
Trying to get a simple reproducible example and am unable to :( It got a little time-consuming and I really need to get work done so have worked around it for now. I could possibly publish everything in a repo, but it would still be rocket + codegen and not a very simple example!
Latest nightly (2019-08-11) still panics, but with different error message:
Also as a sidenote: Rocket master does not ICE anymore. The ICE "was fixed" by so it may be a problem with decl_macro ?
I would still wan't not to ICE on the face of malformed input.
For future reference, when panicking or using for not finding what you expect it is a good idea to include in the message what the found value was. :)
I think you got me wrong. I haven't said, that this should be closed because upstream code has changed, but I said, that upstream does not ICE anymore, so I looked into it, what caused it to not ICE anymore.

I try to go that ;) Confirmed, that it is related to decl maros modify labels: +A-macros-2.0
I need your help with the tags here please ^^
<details<summaryBacktraces</summary<details<summary60960a260</summary</details<details<summarydddb7fca0</summary</details</details modify labels: -E-needs-mcve
What is the appropriate visibility scope for ? is failing because we get the following instead: In my mind the expected semantics of this could would be to scope to inside , but currently with a macro by example it would be scoped to the current module. I can implement either semantic. Edit: I'm talking out of my ass, matches my intuition. Don't know why I thought otherwise.
Change:
<ins> fn main() { println!("hello world"); } </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:
} } ast::ItemKind::MacroDef(ref macro_def) => { <del> let (kw, has_bang) = if macro_def.legacy { ("macro_rules", true) } else { ("macro", false) }; </del> <ins> let (kw, has_bang) = if macro_def.legacy { ("macro_rules", true) } else { self.print_visibility(&item.vis); ("macro", false) }; </ins> self.print_mac_common( Some(MacHeader::Keyword(kw)), has_bang,

Discussion:
E.g. becomes Specifically, the syntax contexts of and are linked (the s refer to the same identifier, even with hygiene) but this is not represented in the output at all, so one might interpret them as being distinct identifiers.
There is no more pretty=hygene, was it replaced with something?
Closing. is apparently no longer a thing, and the output looks sufficiently different with that I don't think it's the same.
There is a FIXME related to this issue, Now that the issue is closed can the FIXME be fix, or made more specific?
Looks like is a thing though so reopening... output today is below. I'm not completely sure whether this is fixed or not --- the output looks the same for the two s, I guess? Not sure which are being referred to either...
Change:
} .block ul, .block li { padding: 0; <ins> margin: 0; </ins> list-style: none; }

Discussion:
In rustdoc sidebars, most headings are clickable links. For instance, "Required Methods" and "Implementors" in the sidebar of However, the headings under "Other items in..." are not clickable. We should link those to the appropriate subheading on the module page. That allows the user to see a more verbose listing of items in the module, since each one has a description alongside it. <img width=150 src="https://user-"<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
So, for instance, sidebar heading should lead ?
claim
Yes, that's correct.
By the way be aware this will conflict with Resolving the conflict should be pretty easy though.
Thanks
any progress on this? I'd like to get it landed before the beta cut, so we have a consistent UI where headings in the sidebar are clickable.
sorry, i couldn't make time last ,i will unassign me, thanks.
Change:
} self.basic_blocks[bb].terminator = Some(terminator); <del> changed |= inner_changed; </del> } if !changed {

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. --repo @ Rustc simply hangs when running Edit: while rustc is crunching on the hang:
cc ? edit: I assume this is due to
O_o yea, I'll have a look
Wild speculation: might have the same cause (EDIT: Backtrace says yes)
Change:
// parameter internally, but we don't allow users to specify the // parameter's value explicitly, so we have to do some error- // checking here. <del> if let GenericArgCountResult { correct: Err(GenericArgCountMismatch { reported: Some(_), .. }), .. } = <dyn AstConv<'_>>::check_generic_arg_count_for_call( </del> <ins> let arg_count = <dyn AstConv<'_>>::check_generic_arg_count_for_call( </ins> tcx, span, def_id, &generics, seg, IsMethodCall::No, <del> ) { </del> <ins> ); if let ExplicitLateBound::Yes = arg_count.explicit_late_bound { explicit_late_bound = ExplicitLateBound::Yes; } if let Err(GenericArgCountMismatch { reported: Some(_), .. }) = arg_count.correct { </ins> infer_args_for_err.insert(index); self.set_tainted_by_errors(); // See issue #53251. }

Discussion:
This is ICE since 1.50.0, error -ICE. Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Bisected: searched nightlies: from nightly-2020-01-01 to nightly-2021-03-17 regressed nightly: nightly-2020-11-18 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
Thanks for bisecting, I believe is the cause.
Assigning and removing as in the prioritization working group. label: +P-medium -I-prioritize
claim
Change:
/// Returns an iterator which will recursively walk the directory structure /// rooted at `path`. The path given will not be iterated over, and this will <del> /// perform iteration in a top-down order. </del> <ins> /// perform iteration in some top-down order.  The contents of unreadable /// subdirectories are ignored. </ins> pub fn walk_dir(path: &Path) -> IoResult<Directories> { Ok(Directories { stack: try!(readdir(path)) }) }

Discussion:
It calls on a vector repeatedly. Example: and are directories with that many files in them. Theoretically this wants a deque.
Would keeping an index be sufficient? Just return and bump each time. It seems to me we don't need any fancy data structure. I can work on this.
That might work, but it does mean that the size of the internal vector grows to be the total number of elements ever touched, rather than just the number of children of recently-walked directories. It would also require cloning each of them. (Maybe not, if it stored internally and returned ...)
What about this. When we run out of space at the end, check if we are using more than half of the vector. If we are, allocate a new one at least twice as large. If we are not, swap all the values to the beginning of the vector. This way we have amortized linear time without needing to use a full blown deque. On Apr 10, 2014 2:14 AM, "Huon Wilson" wrote:
If you can get that to work, I guess so. But really, it would be better/more correct to just use a proper ... if std had access to one.
I am going to guess that taking out of std is undesirable. I can't really think of another way to do this rather than creating a simple . I'll work on it if you think this is acceptable.
"It calls .shift on a vector repeatedly." but it's very slow. Vec/Str need an efficient way to shift() multi-items
This isn't multiple items, it needs to shift the s off one at a time.
( I would be OK with moving deque into a "secret" module inside std and reexporting it from libcollections, however rustdoc doesn't support this nicely just yet.)
How about something along these lines: I didn't test the above, removing syntax errors is left as an exercise to the reader. Edit: Never mind, I see this changes the order that walk_dir guarantees. I'll try and rewrite my proposal tonight to make it emulate the current behaviour.
I'm not sure the current order is important, I don't know though (if it's not important we can probably just use as a stack, which is efficient).

However, if we wish to retain the current order, I really do think the correct solution is to just use a deque, rather than write a complicated specialised data structure for this relatively simple task. (Unless that data structure has other significant benefits, of course. Maybe avoiding the copies from each vec to main deque will be noticably more efficient?)