jiebi/CodeConvo huggingface dataset:
Change:
<ins> // check-pass // force-host // no-prefer-dynamic #![deny(deprecated)] #![crate_type = "proc-macro"] extern crate proc_macro; use proc_macro::*; #[proc_macro] #[deprecated(since = "1.0.0", note = "test")] pub fn test_compile_without_warning_with_deprecated(_: TokenStream) -> TokenStream { TokenStream::new() } </ins>

Discussion:
Use attribute on a procedural macro function doesn't work like expected: it triggers a warning message also when library is building and not just in call place. I know that the attribute support is not landed in stable but this warning is present in all channels (stable, beta and nightly). Compiling lib simple by raise follow warning: Sadly this issue make attribute not usable at all for procedural macro. Follow the code to reproduce this issue: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The most likely reason is that and friends are used from the proc macro harness automatically generated for proc macro crates. So either the harness should generate (there are precedents for this, e.g. test harness generates ), or should not be reported from "externally generated code", which usually includes macros from other crates, but also code generated by the compiler.
Adding should be a very simple fix - the item referring to the proc macro definition functions is generated in in .
claim
Change:
unsafe { let llcx = llvm::LLVMRustContextCreate(tcx.sess.fewer_names()); let llmod_raw = context::create_module(tcx, llcx, mod_name) as *const _; <del> ModuleLlvm { llmod_raw, llcx, tm: create_informational_target_machine(tcx.sess) } </del> <ins> ModuleLlvm { llmod_raw, llcx, tm: ManuallyDrop::new(create_informational_target_machine(tcx.sess)), } </ins> } }

Discussion:
After using command random dependencies throw error. I'm 100% sure that dependencies I'm trying to build are valid because at every compile attempt different dependency fails e.g. tomledit, crossbeam-channel, actix-router_. Sometimes none of imported dependencies fail and out of 5 attempts I was able to build project succesfully twice (I deleted folder after each attempt). Example output: some dependencies (in my case 23) command Improve build scripts on Windows ARM?
Thanks for the report! Transferred to rust-lang/rust since this is a compiler issue. I'm able to reproduce, though I am also using Parallels on an aarch64 mac. I do not have native Windows ARM hardware to test, so I'm not sure if this is unique to the M2 or Parallels. If someone has native hardware, it might be good to help with testing to see if it is a general problem with the target. This appears to be a regression, and I have bisected to cc
I'm seeing the same issue intermittently on a project that uses . It looks like we might have a UAF on an LLVM object. <details<summaryCrashing stack</summary</details<details<summaryEarlier "untrack" operation</summary</detailsI'm guessing this might be triggered because causes us to drop the LLVM TargetMachine dropping the LLVM context.
Swapping the drop order back to the way we had it originally makes my reproducer compile successfully.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Re-opening to track backports
I encountered this issue in Github CI yesterday. It only occurs with rust-1.74 but not with 1.73 and lower.
this should be fixed by and included in the upcoming 1.74.1 stable release. You can probably try a nightly rustc build if you're curious to test the fix.
74.1 has been released.
Yes fixed it.
Hi, sorry for reply to the closed issue, but since I updated my M2 macbook to Sonoma 14.2 last week, I randomly got similar issue
This is happening again with Full log here
Please open a new issue, but it might also have something to do with
Change:
<ins> error: invalid character `'$'` in crate name: `need_crate_arg_ignore_tidy$x` | = help: you can either pass `--crate-name` on the command line or add `#![crate_name="…"]` to set the crate name error: aborting due to 1 previous error </ins>

Discussion:
Running on my checkout with the current master commit fails with tons of errors. here's the last few screens of messages:
Is the check looking for in the full path? My rustc checkout is in a directory called (it's my 2nd of 3 checkouts), and I suspect tidy gets confused by that.
It does CC
That code should probably use .
Oops, I will try to fix this ASAP
Submitted a fix for this at .
Change:
$$(if $$(findstring $(3), $$(PREPARE_HOST)),  $$(call PREPARE_DIR,$$(PREPARE_WORKING_DEST_LIB_DIR))  $$(foreach crate,$$(TARGET_CRATES),  <del> $$(if $$(findstring 1, $$(ONLY_RLIB_$$(crate))),,  </del> <ins> $$(if $$(or $$(findstring 1, $$(ONLY_RLIB_$$(crate))),$$(findstring 1,$$(CFG_INSTALL_ONLY_RLIB_$(2)))),,  </ins> $$(call PREPARE_LIB,$$(call CFG_LIB_GLOB_$(2),$$(crate))))  $$(call PREPARE_LIB,$$(call CFG_RLIB_GLOB,$$(crate))))  $$(if $$(findstring $(2),$$(CFG_HOST)), 

Discussion:
Full gist:
cc
cc since you've been contributing iOS patches. This same error still repros after with: Are you able to successfully build a cross-compiler?
there are 2 different things: building and installing. What fails is phase and I believe I have kind of dirty hack for it in my fork, but will try to find a correct solution and issue PR soon.
this one ?
yep
cool, would you mind submitting that PR?
since PR is going to be open for a while considering current bors queue, I have to mention that in general when you need up-to-date Rust for iOS you can either built it by yourself from or use a prebuilt version from It may lag a bit (usually <= 1 day) but it is guaranteed to build (as iOS is not on Rust official buildbots and master is broken sometimes).
Change:
--> $DIR/numeric-cast-2.rs:7:18 | LL |     let y: i64 = x + x; <del> |            ---   ^^^^^ expected `i64`, found `u16` |            | </del> <ins> |            ---   ^^^^^ |            |     | |            |     expected `i64`, found `u16` |            |     help: you can convert an `u16` to `i64`: `(x + x).into()` </ins> |            expected due to this <del> | help: you can convert an `u16` to `i64` and panic if the converted value wouldn't fit | LL |     let y: i64 = (x + x).try_into().unwrap(); |                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^ </del> error[E0308]: mismatched types --> $DIR/numeric-cast-2.rs:9:18 | LL |     let z: i32 = x + x; <del> |            ---   ^^^^^ expected `i32`, found `u16` |            | </del> <ins> |            ---   ^^^^^ |            |     | |            |     expected `i32`, found `u16` |            |     help: you can convert an `u16` to `i32`: `(x + x).into()` </ins> |            expected due to this <del> | help: you can convert an `u16` to `i32` and panic if the converted value wouldn't fit | LL |     let z: i32 = (x + x).try_into().unwrap(); |                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^ </del> error: aborting due to 3 previous errors

Discussion:
() Errors: I would’ve expected something like: Edit: What actually should happen is the same as currently already with , i.e. it would look like modify labels: A-diagnostics, T-compiler, D-papercut, C-enhancement, E-easy <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Okay, lots of cases that already work got me confused into thinking this was fixed in nightly for a moment. What currently already works is the hint about converting where < where < What currently suggest even though works where < where ≤16 where ≤16
I reported a similar issue not long ago. Maybe it would be more robust and also more general to rewrite this suggestion code to actually look for the impl in question instead of having just a hard-coded list?
claim
I've created a PR augmenting the existing code to change the suggestions for the cases listed. However, I would like to explore the approach suggested(perhaps as part of a separate PR?). Any advice on how I could get the code to look for the impl so it can make the appropriate suggestion? Is the crate the right place to be looking at for this?
Yeah. I believe you'll need to create an and and then call , but there might be other/better ways to do this. You might want to ask for advice on Zulip.
Change:
<ins> // compile-pass // aux-build:const_fn_lib.rs extern crate const_fn_lib; fn main() { const_fn_lib::bar()(); const_fn_lib::bar_inlined()(); const_fn_lib::bar_inlined_always()(); } </ins>

Discussion:
Adding to 's definition works around the ICE. Also, the bug doesn't trigger if is an non- , so it's not just that is inlined cross-crate, but -specific behavior is also involved. cc
Still happens on the latest nightly. cc It doesn't block , but the workaround in that PR is a bit ugly.
I have a fix in
Change:
#[unstable(feature = "core", reason = "likely to be replaced by range notation and adapters")] <del> impl<A> DoubleEndedIterator for RangeInclusive<A> where A: Step + One + Clone, for<'a> &'a A: Sub<Output=A> </del> <ins> impl<A> DoubleEndedIterator for RangeInclusive<A> where A: PartialEq + Step + One + Clone, for<'a> &'a A: Add<&'a A, Output = A>, for<'a> &'a A: Sub<Output=A> </ins> { #[inline] fn next_back(&mut self) -> Option<A> {

Discussion:
I tried printing all valid s by doing and was surprised to find it only printed up to 254. I'm unsure if this is supposed to be this way ( can be used). If so, I'd propose adding this to the Iterators/Ranges section of the book.
The problem is the next method of RangeFrom: It returns the previous value, then updates itself to store the next one. The value 255 ends up being the value that represents a "done" state, so it can't return it. I can't think of any solution that doesn't involve adding a flag to RangeFrom.
Or impl IntoIter instead of Iterator (and use a helper struct to keep track of the range).
Seems similar to .
Question: What is the origin of this Rust behavior, or what is its justification? e.g.: Why an exclusive upper bound on ranges? This caught me by total surprise, coming from Haskell, and I don't know if any Rust I've written for my own cases is wrong now. It behaves differently from similar syntax in Haskell, Swift, and Go, so I'm wondering if it's fruitful to have behavior different from peer languages (in trying to attract people away from languages where syntax like this does not exist.)
Ruby has both exclusive and inclusive ranges
The origin is related to the for-loop idiom in C. corresponds to the range. It has some nice properties such as how it iterates over exactly elements, whereas an inclusive range does and would require you to say, for example, for the indices of a vector if were inclusive. Essentially, it seems like the exclusive behaviour is useful more often than inclusive in a systems language.
Exclusive behaviour is also a leaner implementation. For inclusive behaviour you need some kind of flag for "now yield the inclusive element". This issue is an exact example of why: How do you statefully write an iterator from to , inclusive?
cc , which adjusts this behavior by triggering an overflow on non-wrapped-arithmetic types; it makes the semantics equivalent to repeatedly updating .
so just to be clear, with the above PR merged, now panics. Is this the intended behavior?
Change:
/// let s = RandomState::new(); /// let new_s = s.build_hasher(); /// ``` <ins> /// /// [`Hasher`]: trait.Hasher.html </ins> #[stable(since = "1.7.0", feature = "build_hasher")] fn build_hasher(&self) -> Self::Hasher; } <del> /// The `BuildHasherDefault` structure is used in scenarios where one has a /// type that implements [`Hasher`] and [`Default`], but needs that type to /// implement [`BuildHasher`]. </del> <ins> /// Used to create a default [`BuildHasher`] instance for types that implement /// [`Hasher`] and [`Default`]. </ins> /// <del> /// This structure is zero-sized and does not need construction. </del> <ins> /// `BuildHasherDefault<H>` can be used when a type `H` implements [`Hasher`] and /// [`Default`], and you need a corresponding [`BuildHasher`] instance, but none is /// defined. /// /// Any `BuildHasherDefault` is [zero-sized]. It can be created with /// [`default`][method.Default]. When using `BuildHasherDefault` with [`HashMap`] or /// [`HashSet`], this doesn't need to be done, since they implement appropriate /// [`Default`] instances themselves. </ins> /// /// # Examples ///

Discussion:
Part of Here's what needs to be done to close out this issue: needs a stronger summary/explanation distinction. "This structure is zero-sized and does not need construction." is weird. also needs a stronger summary/explanation distinction. It also needs a better explanation of why it exists with an example. needs general improvement, it is the main bit of this module, but its docs feel tossed together and have few examples or coherence. needs more than just a summary line; it needs explanation and examples.
What kind of further documentation are you looking for here?
Better explanations for examples of implementing and and and more docs generally for all three.
There seem to be a lengthy example of BuildHasherDefault in this commit () Also for BuildHasher and there is a healthy amount of documentation as of now. Hasher seems to be really outdated (still lists several Implementors without mentioning they have been deprecated), which I'm looking into right now.
Thanks ! Looks like all that's left is documenting .
I am happy to mentor anyone who wants to tackle this issue.
I volunteer as a tribute :-)
wonderful! If you need any help, please just let me know, as I said above, happy to help you help me (We can do it here or ping me on IRC)
I have more specifics in the main issue above
I'm gonna tackle this one this weekend! (if that's okay with you,
Change:
<ins> // check-pass #[cfg(FALSE)] auto trait Foo {} //~^ WARN `auto` traits are unstable //~| WARN unstable syntax can change at any point in the future, causing a hard error! fn main() {} </ins>

Discussion:
The following code builds on stable without even a warning: That is surprising since there was some effort recently to start ensuring that unstable syntax does not "leak" into stable Rust, so I expected at least a future-compatibility warning. (See e.g. ) Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
from the code I'd expect a warning:
ah no, auto traits don't use that gating: When parsing an auto trait in the parser, we need to gate it's span and then in the feature gating pass gate it too. This will look similar to, for example, traitalias.
was just for syntax which was previously attempted to reverse stabilization and had the gating code there but disabled. Now that the plumbing exists, using that as a template to add this syntax to the warning should be fairly straightforward. It might make sense to go ahead and crater immediately making this a hard feature gate, though.
I can already tell you of one large regression, the . We should do the feature gating normally as a warning and worry about making it an error later. Once it's a warning, people adding uses get warnings and we should be fine.
A bit unrelated, but I think it would be useful to have docs somewhere that show how to resolve this issue if you have the feature behind a cfg, the easiest solution being a macro_rules macro. But that doesn't have to be fixed here.
Change:
<ins> warning: `#[macro_export]` can only take 1 or 0 arguments --> $DIR/invalid_macro_export_argument.rs:2:1 | LL | #[macro_export(hello, world)] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: `#[warn(invalid_macro_export_arguments)]` on by default warning: `not_local_inner_macros` isn't a valid `#[macro_export]` argument --> $DIR/invalid_macro_export_argument.rs:7:16 | LL | #[macro_export(not_local_inner_macros)] |                ^^^^^^^^^^^^^^^^^^^^^^ warning: 2 warnings emitted </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: I expected to see this happen: it shouldn't compile Instead, this happened: it compiles <!-- 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 --
For anyone who would like to work on this, the following code needs to be adjusted to check if the meta-item list is empty or if it only contains the identifier (i.e. only allowing the attribute to be or : Due to backward compatibility concerns, probably only a future-incompat warning should be issued if the verification fails. label T-compiler A-attributes
claim
First rust-lang/rust contribution I hope this goes well
Change:
if self.is_contiguous() { let tail = self.tail; let head = self.head; <del> return unsafe { &mut self.buffer_as_mut_slice()[tail..head] }; </del> <ins> return unsafe { RingSlices::ring_slices(self.buffer_as_mut_slice(), head, tail).0 }; </ins> } let buf = self.buf.ptr();

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. --This is my first bug report, so please correct me s if I miss anything :-) I use VecDeque<u8in a toy application () which is handling external reads in a loop, and does possible partial handling of the input. My pattern is I call reserve(N) before pushback() N times, then makecontiguous(), then doing some popfront(). I noticed the app was behaving badly, and was able to generate a stand-alone test case which shows the bug. The code is pretty boring and repetitive, so I put it at to avoid spamming here. Just issue "cargo run" after cloning out that code, and look for the word "BUG" within the terminal output: According to the docs, popfront() on an empty VecDeque should return None. Instead, this happens: If I set the boolean "doreserve" to be false, thus getting rid of all the reserve() calls, I get the expected behavior: The same happens if I set "domake_contiguous" to false as well - so calling both functions is a prerequisite to trigger the bug. The same thing happens in debug and release builds. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --The below is the version I found it in, but thanks a lot to Steve Klabnik for also testing it on nightly and getting the same buggy behavior. :
I created a minimal sample:
Hmm, if it double-frees then why does Miri not catch it?
Assigning and removing as in the prioritization working group.
Some time ago I've read somewhere that Rust stdlib VecDeque is cursed. I didn't believe them. I'm changing opinion... -.-
This specific case doesn't double free (i32::drop is a noop), using a might have been a better example...
Still, this is memory-unsafe, right?
Yes, It's still a use-after-free regardless
claim
Based on my conversation with lcnr, jonas-schievink, and others , it seems that using with copy types is not UB (it still exhibits a bug though!) because copy types aren't freed. It is UB with non-copy types though (e.g. ).
Change:
use rustc_hir::intravisit::{self, NestedVisitorMap, Visitor}; use rustc_hir::{HirId, Pat}; use rustc_middle::ty::{self, Ty, TyCtxt}; <ins> use rustc_session::config::nightly_options; </ins> use rustc_session::lint::builtin::BINDINGS_WITH_VARIANT_NAME; use rustc_session::lint::builtin::{IRREFUTABLE_LET_PATTERNS, UNREACHABLE_PATTERNS}; use rustc_session::parse::feature_err;

Discussion:
Gives:
Fairly sure this is intentional for
From the pull I've seen a part that I didn't see/remember: An unstable feature precisepointersizematching will be to permit matching exactly on pointer-size integer types. So you're right, this isn't a new bug, it's a known unfinished part. I hope to see that precisepointersizematching implemented.
It already exists.
I see, then what do I have to hope to see? :-)
I'm not sure the feature is ever going to be stabilised, because there are concerns that this isn't a desirable feature. But hopefully the diagnostics will at least be improved in
Do you have a link to such concerns? (Or are you willing to summarize them?) (I value your work on the compiler a lot varkor :-) )
I think the relevant concerns arose in the (from this comment up). The overview is that we ought not to make assumptions about pointer sizes on the target platform, because they're not guaranteed to be fixed, so this could cause compatibility issues.
Change:
<ins> pub enum En { A(Vec<u8>) } fn get_usize() -> usize { 0 } macro_rules! force_expr { ($e:expr) => { $e } } macro_rules! force_pat { ($a:expr, $b:expr) => { $a..=$b } } macro_rules! make_vec { () => { force_expr!(Vec::new()) } //~ ERROR arbitrary expressions aren't allowed } macro_rules! make_pat { () => { force_pat!(get_usize(), get_usize()) } //~^ ERROR arbitrary expressions aren't allowed //~| ERROR arbitrary expressions aren't allowed } #[allow(unreachable_code)] fn f() -> Result<(), impl core::fmt::Debug> { let x: En = loop {}; assert!(matches!(x, En::A(make_vec!()))); assert!(matches!(5, make_pat!())); Ok::<(), &'static str>(()) } fn main() {} </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. --Note: this only occurs when the type of the code block is a result. Removing the line and swapping for does not yield the ICE. //! use rustice::sub; //! //! let x = sub::makestruct()?; //! //! assert!(matches!(x, sub::En::A(sub::B { inner: vec![], .. }))); //! Ok::<(), &'static str(()) //! <!-- 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. --: and after a rustup, (still getting the same ICE): <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Here's a reproduction without rustdoc involved:
Minimized:
Change:
<ins> error: proc macro panicked --> $DIR/issue-76270-panic-in-libproc-macro.rs:15:1 | LL | proc_macro_panic::panic_in_libproc_macro!(); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: message: `""` is not a valid identifier error: aborting due to previous error </ins>

Discussion:
Between nightly-2020-08-29 and nightly-2020-09-02, the following began printing an ICE message (despite compiling successfully). The relevant compiler commit range is appears extremely relevant so mentioning From the PR description it sounds like the PR was intended to have no effect unless the new -Z flag is passed. Is it possible it could be causing this? Before: After:
It looks like I misunderstood how works. I'll PR a fix tomorrow.
Assigning as and removing .
PR is up at