jiebi/CodeConvo huggingface dataset:
Change:
landed in 1.57, causing derived and implementations to be ignored during dead code analysis. The for 1.57 don't mention this change anywhere. There's discussion in the original PR about including it in the release notes, but looks like nobody got around to it. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think this is also worth a mention in the compatibility notes for 1.57, given that it can break builds where is set.
label +D-incorrect +D-invalid-suggestion
label -D-incorrect -D-invalid-suggestion
My bad there, had two different issues open.
I'd be happy to approve a PR adding a line to the release notes about this.
claim

Discussion:
- [Macro attributes may follow `#[derive]` and will see the original (pre-`cfg`) input.][87220] - [Accept curly-brace macros in expressions, like `m!{ .. }.method()` and `m!{ .. }?`.][88690] - [Allow panicking in constant evaluation.][89508] <ins> - [Ignore derived `Clone` and `Debug` implementations during dead code analysis.][85200] </ins> Compiler --------

Compatibility notes ------------------- <ins> - [Ignore derived `Clone` and `Debug` implementations during dead code analysis.][85200] This will break some builds that set `#![deny(dead_code)]`. </ins> Internal changes ---------------- These changes provide no direct user facing benefits, but represent significant

- [Added an experimental backend for codegen with `libgccjit`.][87260] <ins> [85200]: https://github.com/rust-lang/rust/pull/85200/ </ins> [86191]: https://github.com/rust-lang/rust/pull/86191/ [87220]: https://github.com/rust-lang/rust/pull/87220/ [87260]: https://github.com/rust-lang/rust/pull/87260/
Change:
Initial title: formatargsnl! should link to formatargs! where they mention it currently contains: It would be nicer as: … although I also find which made it . It looks like that was undone at some point? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It seems that is removed in
claim
Was it intentional, though? The PR description says But that does not apply to which has: CC
After some discussion in that PR, it was deemed that a macro being did not warrant, on its own, marking the macro as . Hence why a bunch of such macros were unhidden by that PR, but maybe shouldn't have been part of those? I really don't have a strong opinion here myself, so lemme wash my hands , but: on the one hand, I do lean towards not hiding, in general, some of these macros since it may reduce a bit too much their the other hand, I'll grant that there is a difference, alas quite subtle / currently hard-to-express, between -and-expected-to-eventually-be-stabilized, and perma-; for the latter it seems more legitimate to mark them as . Given the description of the unstability of , it seems like it's the latter?
“On its own” is important here. is used for two categories of APIs: Those that are not stable yet, but have a tracking issue and might become stable at some point The "perma-unstable" APIs, that ideally should be private to a crate but need to be public typically to let some other standard library crate use them. I think that depending on its category each item with should either point to a tracking issue, or be . Here “only for internal language use” seems to point to the latter.
Yeah, I share the feeling: AFAIC, feel free to go and make it again then
One potential argument against hiding the macro from the docs is that it shows up in the compiler errors originating from the use of format strings (i.e. "note: this error originates in the macro "). Having it surfaced to the user this way but hidden from the docs might not be great.
This is being stabilized in , so I think the answer is pretty clearly "no" now (but the discussion here is interesting for other perma-unstable macros).

Discussion:
($fmt:expr, $($args:tt)*) => {{ /* compiler built-in */ }}; } <del> /// Same as `format_args`, but can be used in some const contexts. </del> <ins> /// Same as [`format_args`], but can be used in some const contexts. </ins> /// /// This macro is used by the panic macros for the `const_panic` feature. ///

($fmt:expr, $($args:tt)*) => {{ /* compiler built-in */ }}; } <del> /// Same as `format_args`, but adds a newline in the end. </del> <ins> /// Same as [`format_args`], but adds a newline in the end. </ins> #[unstable( feature = "format_args_nl", issue = "none",
Change:
Hey! Ran into what appears to be a bug - crate's exported macros each appear twice in the left sidebar: ! Toolchain versions (per log): rustc 1.60.0-nightly ( 2022-02-09), docsrs 0.6.0 ( 2022-02-01) Please let me know if I can provide additional info.
Thank you for the report! This is definitely not an issue with itself, but with rustdoc. is this known? Should a rustdoc issue be created?
Not known afaik. Please do file an issue (or transfer this one)!
Seems similar to
Thanks for transferring the issue. One difference between this and - both macros are exported using a wildcard in crate root (not rename):
Well, just another reexport issue. It's common around here. :laughing: I'll try to take a look in the next days.
This is what I have on currently nightly: ! So I guess it's fixed?
Trying locally with the latest nightly (, more current than that of issue open) I get the same initial landing page for but if I click on one of the macros listed (e.g. "drill down") duplicates still appear on the sidebar: ! So the tiny bug is still there, just deeper/hidden on the latest nightly?
Ah indeed! I can also reproduce it now. Will take another look tomorrow then.

Discussion:
fn build_sidebar_items(&self, m: &clean::Module) -> BTreeMap<String, Vec<NameDoc>> { // BTreeMap instead of HashMap to get a sorted output let mut map: BTreeMap<_, Vec<_>> = BTreeMap::new(); <ins> let mut inserted: FxHashMap<ItemType, FxHashSet<Symbol>> = FxHashMap::default(); </ins> for item in &m.items { if item.is_stripped() { continue;

let short = item.type_(); let myname = match item.name { None => continue, <del> Some(ref s) => s.to_string(), </del> <ins> Some(s) => s, </ins> }; <del> let short = short.to_string(); map.entry(short).or_default().push(( myname, Some(item.doc_value().map_or_else(String::new, |s| plain_text_summary(&s))), )); </del> <ins> if inserted.entry(short).or_default().insert(myname) { let short = short.to_string(); let myname = myname.to_string(); map.entry(short).or_default().push(( myname, Some(item.doc_value().map_or_else(String::new, |s| plain_text_summary(&s))), )); } </ins> } if self.shared.sort_modules_alphabetically {

<ins> // This test ensures that there is no macro duplicates in the sidebar. goto: file://|DOC_PATH|/test_docs/macro.a.html // Waiting for the elements in the sidebar to be rendered. wait-for: ".sidebar-elems .others .macro" // Check there is only one macro named "a" listed in the sidebar. assert-count: ( "//*[@class='sidebar-elems']//*[@class='others']/*[@class='block macro']//li/a[text()='a']", 1, ) // Check there is only one macro named "b" listed in the sidebar. assert-count: ( "//*[@class='sidebar-elems']//*[@class='others']/*[@class='block macro']//li/a[text()='b']", 1, ) </ins>

impl EmptyTrait2 for HasEmptyTraits {} #[doc(cfg(feature = "some-feature"))] impl EmptyTrait3 for HasEmptyTraits {} <ins> mod macros; pub use macros::*; </ins>

<ins> #[macro_export] macro_rules! a{ () => {}} #[macro_export] macro_rules! b{ () => {}} </ins>
Change:
When is invoked both by vscode and from the terminal directly, "bootstrap" is rebuilt each time. I think in the end this is due to that line: Indeed is almost certainly different between the two environments. (vscode lives inside a sandbox, it just runs too many untrusted things to be granted access to my files and keys.) Rebuilding on every change seems excessive, is that truly needed? Cc
We could probably move that into this if: I think that would still be fine and maybe enough to avoid trouble in practice? That if is the reason we it in the first place.
is unset for me (in both environments, unless vscode sets it itself), so that would help for my particular case I think.
RUSTC is likely set for you -- this is a build script environment, where it should be set to something. IIRC, I had some trouble assuming it was an absolute path in all cases which is why this ad-hoc canonicalization logic was .
is set by x.py:
The fix in seems wrong to me - if bootstrap isn't rerun when changes, it will still break moving the directory, even if the path is absolute. If you want to fix it properly, you'd probably have to remove this handling from the build script altogether and into rustbuild instead.
I'm not sure I follow your logic -- bootstrap is still rerun when RUSTC changes, just not when it is a relative path. My assumption (perhaps wrong, happy to be corrected) there is that a relative path is only encountered when we're being invoked with a more global rustc (e.g., /usr/bin/rustc, which is in PATH normally).
Nothing changed about rebuilds when changes. The PR only changes things about rebuilds when changes but stays the same. Put differently: we still emit for every env var we actually read. If we had build script helpers for that do the automatically, then they would behave like the post- code.
ah, I missed that only was changed and not . Yes, that fix seems right to me then. Probably you can rerun even less, right, only when it's a lookup () and not when it's a relative path ()? Maybe that's not happening in practice though.
It checks for and not for a lookup.

Discussion:
fn main() { println!("cargo:rerun-if-changed=build.rs"); println!("cargo:rerun-if-env-changed=RUSTC"); <del> println!("cargo:rerun-if-env-changed=PATH"); </del> println!("cargo:rustc-env=BUILD_TRIPLE={}", env::var("HOST").unwrap()); // This may not be a canonicalized path. let mut rustc = PathBuf::from(env::var_os("RUSTC").unwrap()); if rustc.is_relative() { <ins> println!("cargo:rerun-if-env-changed=PATH"); </ins> for dir in env::split_paths(&env::var_os("PATH").unwrap_or_default()) { let absolute = dir.join(&rustc); if absolute.exists() {
Change:
Possibly related to as both ICEs arise from , but this ICE occurs on a different line. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
No longer ICEs since

Discussion:
<ins> #![feature(type_alias_impl_trait)] type Foo = impl Fn() -> Foo; fn foo() -> Foo { foo //~ ERROR: overflow evaluating the requirement `fn() -> Foo {foo}: Sized` } fn main() {} </ins>

<ins> error[E0275]: overflow evaluating the requirement `fn() -> Foo {foo}: Sized` --> $DIR/issue-53398-cyclic-types.rs:6:5 | LL |     foo |     ^^^ | = help: consider increasing the recursion limit by adding a `#![recursion_limit = "256"]` attribute to your crate (`issue_53398_cyclic_types`) error: aborting due to previous error For more information about this error, try `rustc --explain E0275`. </ins>

<ins> // check-pass #![feature(generators, generator_trait)] #![feature(type_alias_impl_trait)] use std::ops::{Generator, GeneratorState}; use std::pin::Pin; type RandGenerator<'a> = impl Generator<Return = (), Yield = u64> + 'a; fn rand_generator<'a>(rng: &'a ()) -> RandGenerator<'a> { move || { let _rng = rng; loop { yield 0; } } } pub type RandGeneratorWithIndirection<'a> = impl Generator<Return = (), Yield = u64> + 'a; pub fn rand_generator_with_indirection<'a>(rng: &'a ()) -> RandGeneratorWithIndirection<'a> { fn helper<'b>(rng: &'b ()) -> impl 'b + Generator<Return = (), Yield = u64> { move || { let _rng = rng; loop { yield 0; } } } helper(rng) } fn main() { let mut gen = rand_generator(&()); match unsafe { Pin::new_unchecked(&mut gen) }.resume(()) { GeneratorState::Yielded(_) => {} GeneratorState::Complete(_) => {} }; } </ins>

<ins> // check-pass #![feature(type_alias_impl_trait)] trait SomeTrait {} impl SomeTrait for () {} trait MyFuture { type Output; } impl<T> MyFuture for T { type Output = T; } trait ReturnsFuture { type Output: SomeTrait; type Future: MyFuture<Output = Result<Self::Output, ()>>; fn func() -> Self::Future; } struct Foo; impl ReturnsFuture for Foo { type Output = impl SomeTrait; type Future = impl MyFuture<Output = Result<Self::Output, ()>>; fn func() -> Self::Future { Result::<(), ()>::Err(()) } } fn main() {} </ins>

<ins> #![feature(type_alias_impl_trait, generator_trait, generators)] use std::ops::Generator; trait Runnable { type Gen: Generator<Yield = (), Return = ()>; fn run(&mut self) -> Self::Gen; } struct Implementor {} impl Runnable for Implementor { type Gen = impl Generator<Yield = (), Return = ()>; fn run(&mut self) -> Self::Gen { move || { //~ ERROR: type mismatch resolving yield 1; } } } fn main() {} </ins>

<ins> error[E0271]: type mismatch resolving `<[generator@$DIR/issue-94429.rs:16:9: 18:10] as Generator>::Yield == ()` --> $DIR/issue-94429.rs:16:9 | LL | /         move || { LL | |             yield 1; LL | |         } | |_________^ expected integer, found `()` error: aborting due to previous error For more information about this error, try `rustc --explain E0271`. </ins>
Change:
I'm seeing an internal compiler error on the following input, found by : The ICE happens after correctly reporting the error "unknown start of token", so low priority. I guess that one part of the code treats as whitespace, while another part of the code treats it as not whitespace, causing a logic error with this input. Affected versions: nightly 2022-02-26 and beta 1.60.0-beta1 are affected, but stable 1.59.0 does not ICE. <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Fixed by , different enough to the test that I'll mark as needs-test. But anybody feel free to close this if we don't generally add fuzzed inputs to tests

Discussion:
<ins> // check-fail // dont-check-compiler-stdout // dont-check-compiler-stderr fn�a<e>(){fn�p(){e}} //~ ERROR unknown start of token: u{fffd} //~^ ERROR unknown start of token: u{fffd} //~^^ ERROR can't use generic parameters from outer function [E0401] //~^^^ WARN type parameter `e` should have an upper camel case name fn main(){} </ins>
Change:
The following code states that rounds up to the next 64 kB: However, if is any of (where x is a non-negative number) it will not properly round up. Additionally, the least significant byte is retained, I doubt that is intended either. Am I missing something? Otherwise I believe it's meant to be instead of to properly round up. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
To be honest, I think this line may as well be removed. As the comment says, the OS will do the rounding up in any case. And as the : So 64 KB isn't technically guaranteed. I'm not sure there's anything to be gained by doing the rounding up ourselves.
label +O-windows +T-libs
claim

Discussion:
// PTHREAD_STACK_MIN bytes big.  Windows has no such lower limit, it's // just that below a certain threshold you can't do anything useful. // That threshold is application and architecture-specific, however. <del> // Round up to the next 64 kB because that's what the NT kernel does, // might as well make it explicit. let stack_size = (stack + 0xfffe) & (!0xfffe); </del> let ret = c::CreateThread( ptr::null_mut(), <del> stack_size, </del> <ins> stack, </ins> thread_start, p as *mut _, c::STACK_SIZE_PARAM_IS_A_RESERVATION,
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!
Ah, now division needs : in the docs it says this is equivalent -- so, both and need to be fully initialized? That's different from the LLVM operation so I am slightly surprised. (OTOH this intrinsic is by-value and its type would not allow uninit data anyway so I guess the question is somewhat moot.)
Whoops. Yes, that's the intent, it's also called a "blend" in SIMD jargon. It not having much in common is due to it merely having a shared name from outside the LLVM terminology.
I don't think it strictly has to have both being init, though... for this purpose, it is sufficient to assume that the stated equivalence holds in the case of uninit data only if both sides are also considered implicitly frozen by this operation. One of the purposes IS to allow composing a partially initialized vector with another that fills in the blanks in order to get a fully initialized vector. The important detail is that the operation is fully branchless: it may be valid to execute it using branches, but it does not need any to complete.
Well, it is still quite relevant whether calling the intrinsic with uninit data in a "dead" element is UB or not. But for now I will simply make it UB, and then if that is ever a problem we can see what we want to do.
It should not be, though I think that the resulting vector from a should always be fully initialized as a postcondition, which means it may be UB if both sides of a selection are uninitialized data (and the mask itself has to be initialized). We don't have MaybeUninit vectors yet though.
In that case, at least on the LLVM side, equivalence with does not hold -- under that equivalence, if any input is , the output will be . That seems like an odd requirement, what would motivate this? Definitely. Yeah so in a sense the discussion is rather moot currently and maybe I shouldn't have started it. (But by default Miri does not check integer initialization, so this still makes a difference for that case.)
Because ultimately, is "really" trying to be And there's a suite of separately-defined LLVM intrinsics... the intrinsics... that we will probably introduce Rust equivalents of if we get around to working with MaybeUninit vectors. And all of those will probably use or something in their nomenclature.
I don't understand how that motivates introducing UB when "forwarding" uninit data. I expected the type of with to be something like . Such an intrinsic could even be safe to call, but requiring the "selected" values to be initialized would prevent that, and I do not understand the benefit of that.
Hmm, perhaps you are right then.

Discussion:
<del> Subproject commit e05a543f74dbdd0580b2bd35ddb7f8e144d9edda </del> <ins> Subproject commit c6b3f687d5d9917b626f80a730552a185052ff28 </ins>
Change:
ICE encountered in a , will post more details when i trace it further:
I am able to reproduce the issue with this code and : And it's combination of ("introduce" the ICE, preexisting issue) and (trigger the lint which trigger the ICE).
Further reduced to:

Discussion:
self.flat_map_node(node) } <del> fn flat_map_stmt(&mut self, mut node: ast::Stmt) -> SmallVec<[ast::Stmt; 1]> { </del> <ins> fn flat_map_stmt(&mut self, node: ast::Stmt) -> SmallVec<[ast::Stmt; 1]> { </ins> // FIXME: invocations in semicolon-less expressions positions are expanded as expressions, // changing that requires some compatibility measures. if node.is_expr() {

self.cx.current_expansion.is_trailing_mac = false; res } <del> _ => assign_id!(self, &mut node.id, || noop_flat_map_stmt(node, self)), </del> <ins> _ => noop_flat_map_stmt(node, self), </ins> }; }

<ins> // This test checks that there is no ICE with this code // // check-pass // compile-flags:--check-cfg=names() -Z unstable-options fn main() { #[cfg(crossbeam_loom)] //~^ WARNING unexpected `cfg` condition name {} } </ins>

<ins> warning: unexpected `cfg` condition name --> $DIR/stmt-no-ice.rs:7:11 | LL |     #[cfg(crossbeam_loom)] |           ^^^^^^^^^^^^^^ | = note: `#[warn(unexpected_cfgs)]` on by default warning: 1 warning emitted </ins>
Change:
If using format inside a closure (e.g. in iter functions) and the returning String is passed into a function that takes less args, rustc panics. Minimized code snippet: version: 1.60.0-beta.2 and 1.61.0-nightly query: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
playground link:
Probably duplicate of
Actually, not sure if it's a duplicate of . Still failing on master after the fix for that one landed, and failed with the same error (and not a duplicated adjustment bug) on beta. I will look into it! claim
Minimized:

Discussion:
self.demand_suptype(provided_arg.span, formal_input_ty, coerced_ty); }; <ins> let minimum_input_count = formal_input_tys.len(); </ins> // Check the arguments. // We do this in a pretty awful way: first we type-check any arguments // that are not closures, then we type-check the closures. This is so

}) } <del> let minimum_input_count = formal_input_tys.len(); </del> for (idx, arg) in provided_args.iter().enumerate() { // Warn only for the first loop (the "no closures" one). // Closure arguments themselves can't be diverging, but

err.emit(); } <del> // We also need to make sure we at least write the ty of the other // arguments which we skipped above. if c_variadic { fn variadic_error<'tcx>(sess: &Session, span: Span, ty: Ty<'tcx>, cast_ty: &str) { use crate::structured_errors::MissingCastForVariadicArg; </del> <ins> for arg in provided_args.iter().skip(minimum_input_count) { let arg_ty = self.check_expr(&arg); </ins> <del> MissingCastForVariadicArg { sess, span, ty, cast_ty }.diagnostic().emit(); } </del> <ins> if c_variadic { // We also need to make sure we at least write the ty of the other // arguments which we skipped above, either because they were additional // c_variadic args, or because we had an argument count mismatch. fn variadic_error<'tcx>(sess: &Session, span: Span, ty: Ty<'tcx>, cast_ty: &str) { use crate::structured_errors::MissingCastForVariadicArg; </ins> <del> for arg in provided_args.iter().skip(expected_arg_count) { let arg_ty = self.check_expr(&arg); </del> <ins> MissingCastForVariadicArg { sess, span, ty, cast_ty }.diagnostic().emit(); } </ins> // There are a few types which get autopromoted when passed via varargs // in C but we just error out instead and require explicit casts.

<ins> fn main() { (|| {})(|| { //~^ ERROR this function takes 0 arguments but 1 argument was supplied let b = 1; }); } </ins>

<ins> error[E0057]: this function takes 0 arguments but 1 argument was supplied --> $DIR/wrong_argument_ice-4.rs:2:5 | LL |       (|| {})(|| { |  _____^^^^^^^_- | |     | | |     expected 0 arguments LL | | LL | |         let b = 1; LL | |     }); | |_____- supplied 1 argument error: aborting due to previous error For more information about this error, try `rustc --explain E0057`. </ins>
Change:
HashMap clearly has itermut while HashSet does not. Docs should be changed to reflect this. I would be happy to do this, but as I have not contributed to Rust before, wanted to make sure I didn't miss something here.
I also realize that the key itself is reference as seen here but feel the wording here being updated is still valid.
I agree this wording should be updated. Perhaps "or " should just be removed.
are you still planning on making this change?
label +A-docs +E-easy

Discussion:
//! ``` //! //! While many collections offer `iter()`, not all offer `iter_mut()`. For <del> //! example, mutating the keys of a [`HashSet<T>`] or [`HashMap<K, V>`] could //! put the collection into an inconsistent state if the key hashes change, so //! these collections only offer `iter()`. </del> <ins> //! example, mutating the keys of a [`HashSet<T>`] could put the collection //! into an inconsistent state if the key hashes change, so this collection //! only offers `iter()`. </ins> //! //! [`into_iter()`]: IntoIterator::into_iter //! [`HashSet<T>`]: ../../std/collections/struct.HashSet.html <del> //! [`HashMap<K, V>`]: ../../std/collections/struct.HashMap.html </del> //! //! # Adapters //!