jiebi/CodeConvo huggingface dataset:
Change:
/// Matches `'-' lit | lit` (cf. `ast_validation::AstValidator::check_expr_within_pat`). /// Keep this in sync with `Token::can_begin_literal_maybe_minus`. <del> pub(super) fn parse_literal_maybe_minus(&mut self) -> PResult<'a, P<Expr>> { </del> <ins> pub fn parse_literal_maybe_minus(&mut self) -> PResult<'a, P<Expr>> { </ins> maybe_whole_expr!(self); let lo = self.token.span;

Discussion:
says: ... which isn't exactly where the was expected. () Another variation is this code: which gives this result: ()
Hello, I am a quite new contributor, and I'd like to tackle this issue. Do you think that is possible? I have looked a bit at the code, and I think this mostly comes from the [] function, more precisely, [this condition][cond] can be tweaked. Is that correct? []: [cond]:
Turns out I was terribly wrong. The problem is that the following snippet: Can be rewritten as: And that the [] function looks for an expression as the first argument ([corresponding code][expression], [code example][snippet]). Consequently, is the said expression, which explain why the error is raised on the first . Now that I know where the error comes from. I think the best way to fix this issue is to check if this expression can be a format string, perhaps with the [] function. I am still unsure about the quality of the emitted error, but at least it would have the correct span. []: [expression]: [snippet]: []:
Change:
impl<'a, 'tcx> SyntaxChecker<'a, 'tcx> { fn check_rust_syntax(&self, item: &clean::Item, dox: &str, code_block: RustCodeBlock) { <del> let buffered_messages = Lrc::new(Lock::new(vec![])); let emitter = BufferEmitter { messages: Lrc::clone(&buffered_messages) }; </del> <ins> let buffer = Lrc::new(Lock::new(Buffer::default())); let emitter = BufferEmitter { buffer: Lrc::clone(&buffer) }; </ins> let sm = Lrc::new(SourceMap::new(FilePathMapping::empty())); let handler = Handler::with_emitter(false, None, Box::new(emitter)); <ins> let source = dox[code_block.code].to_owned(); </ins> let sess = ParseSess::with_span_handler(handler, sm); <del> let source_file = sess.source_map().new_source_file( FileName::Custom(String::from("doctest")), dox[code_block.code].to_owned(), ); let validation_status = rustc_driver::catch_fatal_errors(|| { let mut has_syntax_errors = false; let mut only_whitespace = true; // even if there is a syntax error, we need to run the lexer over the whole file let mut lexer = Lexer::new(&sess, source_file, None); loop { match lexer.next_token().kind { token::Eof => break, token::Whitespace => (), token::Unknown(..) => has_syntax_errors = true, _ => only_whitespace = false, } } if has_syntax_errors { Some(CodeBlockInvalid::SyntaxError) } else if only_whitespace { Some(CodeBlockInvalid::Empty) } else { None } </del> <ins> let is_empty = rustc_driver::catch_fatal_errors(|| { parse_stream_from_source_str( FileName::Custom(String::from("doctest")), source, &sess, None, ) .is_empty() </ins> }) <del> .unwrap_or(Some(CodeBlockInvalid::SyntaxError)); </del> <ins> .unwrap_or(false); let buffer = buffer.borrow(); </ins> <del> if let Some(code_block_invalid) = validation_status { </del> <ins> if buffer.has_errors || is_empty { </ins> let mut diag = if let Some(sp) = super::source_span_for_markdown_range(self.cx, &dox, &code_block.range, &item.attrs) { <del> let warning_message = match code_block_invalid { CodeBlockInvalid::SyntaxError => "could not parse code block as Rust code", CodeBlockInvalid::Empty => "Rust code block is empty", </del> <ins> let warning_message = if buffer.has_errors { "could not parse code block as Rust code" } else { "Rust code block is empty" </ins> }; let mut diag = self.cx.sess().struct_span_warn(sp, warning_message);

Discussion:
In , we would like to tweak the structure of the tokens rustc uses. One of the components which heavily depends on the current structure is ( and module use ). I think, for this issue and in general, it makes sense to switch over to , which produces lower-level guaranteed lossless tokens, which look like a better fit for the task of syntax highlighting. I plan to do this refactor myself, but I want to check with if this is a good idea. EDIT: cc
sgtm
I'm fine with it as well. :)
BTW, is there some chat room for rustdoc team on zulip on discord? I'd like to ask some questions :)
There is one on discord (simply called "rustdoc").
It's linked at (which is I agree pretty hard to find). Also the text there is wrong and mentions , we should probably fix that.
Change:
} )*) => {$( mod $case_name { <ins> #[allow(unused_imports)] use core::ops::Bound; </ins> #[test] fn pass() { let mut v = $data;

Discussion:
These feel like an omission to me, given how is implemented for this type: And if we really want to go for feature parity, then also has impls for , but I think that's mostly for the sake of methods like , and it really doesn't make sense here. Edit: Then again, considering that RangeArgument is going to have methods that return , maybe is worth it. (secretly, I just want the standard library to implement my bounds-checking and length-computation for me in my n-dimensional array, so that I can just write and trust that it's correct. But shhhhhh, don't tell anyone)
On second thought, after seeing how meager libcore's test suite is for the existing indexing operations, I have decided that I should stop trusting the standard library and start contributing to it myself. Working on a PR. Edit: awww, looks like there's actually a good reason why there's no tests with or . (the first takes forever on debug, the second sets forth The End of All Times) Edit 2: How on earth does not appear a single time in the tests for slice or str!?!
do you still have plans to make a PR for this feature?
Nope, totally forgot about this! Feel free to take the reins. (looking back, it seems I went ahead with the test suite PR (), but that took long enough to merge that by the time it was done I must have moved on to other things.)
Change:
<del> //! A MIR pass which duplicates a coroutine's body and removes any derefs which //! would be present for upvars that are taken by-ref. The result of which will //! be a coroutine body that takes all of its upvars by-move, and which we stash //! into the `CoroutineInfo` for all coroutines returned by coroutine-closures. </del> <ins> //! This pass constructs a second coroutine body sufficient for return from //! `FnOnce`/`AsyncFnOnce` implementations for coroutine-closures (e.g. async closures). //! //! Consider an async closure like: //! ```rust //! #![feature(async_closure)] //! //! let x = vec![1, 2, 3]; //! //! let closure = async move || { //!     println!("{x:#?}"); //! }; //! ``` //! //! This desugars to something like: //! ```rust,ignore (invalid-borrowck) //! let x = vec![1, 2, 3]; //! //! let closure = move || { //!     async { //!         println!("{x:#?}"); //!     } //! }; //! ``` //! //! Important to note here is that while the outer closure *moves* `x: Vec<i32>` //! into its upvars, the inner `async` coroutine simply captures a ref of `x`. //! This is the "magic" of async closures -- the futures that they return are //! allowed to borrow from their parent closure's upvars. //! //! However, what happens when we call `closure` with `AsyncFnOnce` (or `FnOnce`, //! since all async closures implement that too)? Well, recall the signature: //! ``` //! use std::future::Future; //! pub trait AsyncFnOnce<Args> //! { //!     type CallOnceFuture: Future<Output = Self::Output>; //!     type Output; //!     fn async_call_once( //!         self, //!         args: Args //!     ) -> Self::CallOnceFuture; //! } //! ``` //! //! This signature *consumes* the async closure (`self`) and returns a `CallOnceFuture`. //! How do we deal with the fact that the coroutine is supposed to take a reference //! to the captured `x` from the parent closure, when that parent closure has been //! destroyed? //! //! This is the second piece of magic of async closures. We can simply create a //! *second* `async` coroutine body where that `x` that was previously captured //! by reference is now captured by value. This means that we consume the outer //! closure and return a new coroutine that will hold onto all of these captures, //! and drop them when it is finished (i.e. after it has been `.await`ed). //! //! We do this with the analysis below, which detects the captures that come from //! borrowing from the outer closure, and we simply peel off a `deref` projection //! from them. This second body is stored alongside the first body, and optimized //! with it in lockstep. When we need to resolve a body for `FnOnce` or `AsyncFnOnce`, //! we use this "by move" body instead. use itertools::Itertools; </ins> use rustc_data_structures::unord::UnordSet; use rustc_hir as hir;

Discussion:
Something is still wrong w/ async call shims. I think I'm not doing the transform correctly or something. Putting this up so I don't forget about it, but I'll fix it.
ohhhhh lol it's drop glue. Huh.
Oh hell yes this is actually totally wrong wtf:
Change:
pub use core::char::{MAX, from_digit, from_u32, from_u32_unchecked}; #[stable(feature = "rust1", since = "1.0.0")] pub use core::char::{EscapeDebug, EscapeDefault, EscapeUnicode}; <ins> #[stable(feature = "char_from_str", since = "1.19.0")] pub use core::char::ParseCharError; </ins> // unstable reexports #[unstable(feature = "try_from", issue = "33417")]

Discussion:
I'm not sure if this is an oversight. But the implementation should be trivial. I'll add tests and implement it, if it is fine.
Strings aren't indexable and .len() doesn't count the number of chars. :smile: What comes to mind first is an iterator inspecting the two first chars:
xD I didn't test my code, but you get the gist. I had a impl at first, but then edited it
cc
Triage: this has not been .
PRs welcome!
I can take this. I was also thinking of adding a impl for , but unsure if it would be better to wait for to get closer to stabilization and use that instead of adding another empty enum to std
wait, that wouldn't work bc of lifetime issues regardless, right? :(
Change:
/// Creates a null raw pointer. /// <ins> /// This function is equivalent to zero-initializing the pointer: /// `MaybeUninit::<*const T>::zeroed().assume_init()`. /// The resulting pointer has the address 0. /// </ins> /// # Examples /// /// ```

Discussion:
This has come up in two places recently: and We should do the following: On , document that is equivalent to Either before or after it lands, update the text in to document that "allocated objects" cannot contain the 0 address (alternatively, if that PR lands with text that says that an allocated object cannot contain the "null" address, update the text to mention that null is equal to 0) Are there other places we should update too? cc
there was some discussion in https://rust-
Int-to-ptr casts are terrible, I'd rather not do that. In fact these two are not equivalent for Miri (but that might be a Miri limitation, int2ptr is just hard or impossible to handle precisely for a tool like Miri). We should say that it returns a pointer whose address is 0, but we shouldn't commit to which provenance it has.
adds the docs for this.
Change:
None, Some(std::num::NonZeroU32), } <ins> // @hasraw type_layout/enum.Uninhabited.html 'Size: ' // @hasraw - '0 bytes (<a href="https://doc.rust-lang.org/stable/reference/glossary.html#uninhabited">uninhabited</a>)' pub enum Uninhabited {} // @hasraw type_layout/struct.Uninhabited2.html 'Size: ' // @hasraw - '8 bytes (<a href="https://doc.rust-lang.org/stable/reference/glossary.html#uninhabited">uninhabited</a>)' pub struct Uninhabited2(std::convert::Infallible, u64); </ins>

Discussion:
Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
I'm ambivalent, I don't think showing zero is necessarily wrong, especially since that's what's reported by .
In my opinion, I think that while size 0 is not wrong, that showing that it's uninhabited is more right, or at least more clear and makes the distinction.
I don't understand uninhabited when I first see it. It is a hard word compared to 0. I think 0 is easier. Why not both? What if we show ? Also, what if the enum is not empty but have a single/multiple ZST like phantom type?
I think displaying 0 is better as well, but we can do as suggested and simply display both.
0 is wrong. 0 means "this is a zero sized type", like or ; it can be created. Uninhabited types cannot be created, they are things like and . IMO posting 0 there is actively misleading. See also Ok, then we can link to some docs. I didn't see anything in the nomicon but I'm sure they'd take a PR adding it to "exotically sized types".
This is a bug imo, it allows transmuting from ZSTs to uninhabited types which is UB.
Even if they cannot be created, their size remain 0 as they don't "exist", however since they cannot be constructed, it makes sense to mention they're unhabited types. Well, I don't have a strong conviction on this in any case. I think we all agree for the mention of "unhabited" though.
Yeah, that solved the issue of 0 which is wrong. I do think it is better to link it to , but I think it's wrong to put that in "size" such that it should be in "type" instead, because it doesn't have a size to begin with. Well, there are parts where rust sacrificed correctness for ease of understanding, one example is which means uniqueness not exactly mutable all the time.
claim
Note that uninhabited is orthogonal to size. You can have an uninhabited type of any size.

So I think showing uninhabitedness is good, but in addition to the size+align, not instead.
Hmm, I think that will report that the size is always 0 for an uninhabited type though, unless that's changed recently.
That would surprise me, since that'd be different from what and do:
Change:
); debug!("save: data written to disk successfully"); } <del> Err((path, err)) => { sess.dcx().emit_err(errors::WriteNew { name, path, err }); } </del> <ins> Err((path, err)) => sess.dcx().emit_fatal(errors::WriteNew { name, path, err }), </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. --With as a dependency. <!-- 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. --: This is repeated for what seems like every parallel compilation unit.
It appeared to be related to running out of space in the target directory.
Thank you for opening the issue and that explanation. This is probably fixed by (which will be in 1.76 but not 1.75) but I'll try to reproduce the crash just in case it isn't fixed by that.
The reproducer script I cooked up for reproduces this ICE backtrace on stable, so I'm linking this to that PR.
Change:
} &ty::Coroutine(def_id, args) => { let f_ty = if let Some(var) = parent_ty.variant_index { <del> let gen_body = if def_id == self.body.source.def_id() { self.body </del> <ins> // If we're currently validating an inlined copy of this body, // then it will no longer be parameterized over the original // args of the coroutine. Otherwise, we prefer to use this body // since we may be in the process of computing this MIR in the // first place. let gen_body = if def_id == self.caller_body.source.def_id() { self.caller_body </ins> } else { self.tcx.optimized_mir(def_id) };

Discussion:
on commit If you don't set a you will OOM while optimizing syn with these very silly flags. I also have another example of this that produces a "but found ConstICE. They look similar, I'll post the other one later if someone wants.
I've been able to minimize to this:
Here is a further minimized -only repro: The came out of the innards of . The use of is not critical, but the use of a type with both a lifetime and a type generic is; for example, will do too. Tested with the above RUSTFLAGS, under . T/ <details<summaryBacktrace</summary</details
Change:
#[stable(feature = "rust1", since = "1.0.0")] impl PartialEq<OsStr> for str { <ins> #[inline] </ins> fn eq(&self, other: &OsStr) -> bool { *other == *OsStr::new(self) }

Discussion:
Godbolt link: I expect these two snippets have the same optimized asm but they don't:
I think the bigger problem here is that the quite trivial AsRef and PartialEq implementations did not get inlined. I would not expect anything to optimize well without those getting inlined.
I'm not sure we can expect these two to give you the same assembly. They are actually a bit different -- the first one will construct conditionally ( will call the closure only for ), whereas the second one will create the unconditionally before even checking if the parameter is or . As for the differences in the assembly wrt. comparisons themselves, this seems to be due to the difference between the code to check for equality of vs . I wonder, do you have a particular benchmark/workload where the first function is slower than expected?
Still, if I change the first snippet like below, [the asm][1] is different too: [1]:
is effectively a pointer cast, so it is warranted to expect assembly of at least similar quality. Inlining does not happen because we do happen to have generated machine code for these trivial functions in Tacking some s should suffice?
After inlining some methods in , I got the same asm between those two snippets:
Change:
<ins> // test for #117058 - check that attributes are validated on various kinds of statements. struct A; fn func() {} fn main() { #[allow(two-words)] //~^ ERROR expected one of `(`, `,`, `::`, or `=`, found `-` if true { } else { } #[allow(two-words)] //~^ ERROR expected one of `(`, `,`, `::`, or `=`, found `-` (1); #[allow(two-words)] //~^ ERROR expected one of `(`, `,`, `::`, or `=`, found `-` match 1 { _ => {} } #[allow(two-words)] //~^ ERROR expected one of `(`, `,`, `::`, or `=`, found `-` while false {} #[allow(two-words)] //~^ ERROR expected one of `(`, `,`, `::`, or `=`, found `-` {} #[allow(two-words)] //~^ ERROR expected one of `(`, `,`, `::`, or `=`, found `-` A {}; #[allow(two-words)] //~^ ERROR expected one of `(`, `,`, `::`, or `=`, found `-` func(); #[allow(two-words)] //~^ ERROR expected one of `(`, `,`, `::`, or `=`, found `-` A; #[allow(two-words)] //~^ ERROR expected one of `(`, `,`, `::`, or `=`, found `-` loop {} } </ins>

Discussion:
https://crater-
searched nightlies: from nightly-2023-08-01 to nightly-2023-10-10 regressed nightly: nightly-2023-09-15 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsthis bisection may look pretty nonsensical, but I did manually confirm that nightly-2023-09-14 worked and nightly-2023-09-16 didn't. I am surprised that this ever parsed, and given that there's only a single random repo that regressed, and the regressing code is a mistake, I don't think this is a problematic regression. anyways.
Agreed that we don't necessarily need a fix, but we should try to make sure that this is indeed limited to this one case (i.e., it's not some broader incompatibility that may have gone uncaught in Crater)
The change here is that AST validation is now checking that the attribute is valid. Some other cases: Marking as needs-test, with the new behavior being correct
Change:
impl Drop for ModuleLlvm { fn drop(&mut self) { unsafe { <ins> ManuallyDrop::drop(&mut self.tm); </ins> llvm::LLVMContextDispose(&mut *(self.llcx as *mut _)); } }

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> #![feature(fn_delegation)] #![allow(incomplete_features)] trait Trait { reuse Trait::foo { &self.0 } //~^ ERROR recursive delegation is not supported yet } reuse foo; //~^ ERROR recursive delegation is not supported yet fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'no entry found for key'', 'thread 'rustc' panicked at 'no entry found for key'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [hircrate] getting the crate HIR [hirattrs] getting HIR owner attributes in `` [entry_fn] looking up the entry function of a crate [analysis] running analysis passes on this crate --
cc
Change:
expected, }); self.try_suggest_return_impl_trait(err, expected, found, fn_id); <del> self.note_caller_chooses_ty_for_ty_param(err, expected, found); </del> <ins> self.try_note_caller_chooses_ty_for_ty_param(err, expected, found); </ins> return true; } }

Discussion:
The statement "the caller chooses a type for which can be different from " is confusing because and are always different. I think it would be best to supress that note when the types only differ in reference-ness. The message was introduced in . No response No response
label +D-confusing
Thanks, that note definitely doesn't make sense. CC (). I suggested to move out of in order to catch more cases but that was a bit too aggressive as can be witnessed here — that's on me. We should replicate some parts of , namely checking that the type param in question does not occur in the return expression type. That did cross my mind back then but I didn't really follow up on that thought for some reason.
Thanks for the cc I'll take a look ~today/tomorrow
Opened to avoid making the note if found return type contains the expected return type (type parameter).
Change:
<ins> // check-pass fn main() { let array = [0x42u8; 10]; for b in &array { let lo = b & 0xf; let hi = (b >> 4) & 0xf; } } </ins>

Discussion:
Compiled with: Using: Gives:
The problem is not tied to box:
No longer ICEs after
Ops, sorry, I reopen until a test is present.

: <details<summary<strongBacktrace</strong</summary<p</p</detailssearched nightlies: from nightly-2019-10-03 to nightly-2020-07-05 regressed nightly: nightly-2020-02-16 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with:
Minified, It seems possible to ICE on stable, though I'm not sure if it counts? <details<summaryStable error</summary</details
The ICE is fixed in the latest nightly, marking as .