jiebi/CodeConvo huggingface dataset:
Code change:
fn avg<T=i32>(_: T) {} //~^ ERROR defaults for type parameters are only allowed //~| WARNING hard error <ins> struct S<T>(T); impl<T=i32> S<T> {} //~^ ERROR defaults for type parameters are only allowed //~| WARNING hard error </ins> fn main() {}

Related discussion:
text: If I understand correctly, type parameter defaults have no effect in the block . Just like in PR , this should have a warning and then an error. Example cc
Argh, I guess I failed to cover those?
Nominating for triage.
triage: P-high
Code change:
hir::ItemKind::Fn(..) | hir::ItemKind::Ty(..) | hir::ItemKind::Static(..) <ins> | hir::ItemKind::Existential(..) </ins> | hir::ItemKind::Const(..) => { intravisit::walk_item(self, &item); }

Related discussion:
text: The following code gives "warning: enum is never used: ": This regressed pretty recently. cc
27.0 does not warn, 1.28.0 does.
triage: P-medium; This seems like a papercut that should be easy to work-around (at least if one isn't using ...).
switched to P-high after prompting from
whoops forgot to tag with T-compiler in time for the meeting...
assigning to
I'm grabbing this, I think I broke it and it should be easy to fix
Code change:
self.primitive_locations.insert(prim, def_id); } <del> self.stack.push(krate.name.to_string()); </del> krate = CacheBuilder { tcx, cache: self, empty_cache: Cache::default() }.fold_crate(krate); for (trait_did, dids, impl_) in self.orphan_trait_impls.drain(..) {

Related discussion:
text: It should say instead.
Relevant code: I think the fix is to use the crate name instead of .
Also, I would be curious to see if you can remove altogether by using : That might break renamed modules maybe? I don't remember how modules interact with re-exports.
Code change:
/// /// # Example /// ``` <del> /// #![feature(io_into_inner_error_parts)] </del> /// use std::io::{BufWriter, ErrorKind, Write}; /// /// let mut not_enough_space = [0u8; 10];

Related discussion:
text: <!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilisation. Make sure to include the relevant RFC for the feature if it has one. Otherwise provide a short summary of the feature and link any relevant PRs or issues, and remove any sections that are not relevant to the feature. Remember to add team labels to the tracking issue. For a language team feature, this would e.g., be . Such a feature should also be labeled with e.g., . This label is used to associate issues (e.g., bugs and design questions) to the feature. --This is a tracking issue for and . The feature gate for the issue is . Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label. <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [x] Implement these methods - see [x] Adjust documentation [x] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide]) [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev- <!-- Include any open questions that need to be answered before the feature can be stabilised. --These new methods are being introduced as an unstable feature to give time to validate their names, types, and documentation, before stabilisation. Implementation (with docs) is in , currently in review/rework.
fcp merge Check out recap of this API in
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [ ] [x] [ ] [x] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
Code change:
/// /// # Example /// ``` <del> /// #![feature(io_into_inner_error_parts)] </del> /// use std::io::{BufWriter, ErrorKind, Write}; /// /// let mut not_enough_space = [0u8; 10];

Related discussion:
text: See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
Code change:
<del> #![feature(inherent_associated_types)] #![allow(dead_code, incomplete_features)] #![crate_type = "lib"] #![deny(unused_attributes)] // run-rustfix pub trait Trait { type It; const IT: (); fn it0(); fn it1(); fn it2(); } pub struct Implementor; impl Implementor { #[doc(hidden)] // no error type Inh = (); #[doc(hidden)] // no error const INH: () = (); #[doc(hidden)] // no error fn inh() {} } impl Trait for Implementor { type It = (); //~^^ ERROR `#[doc(hidden)]` is ignored //~|  WARNING this was previously accepted const IT: () = (); //~^^ ERROR `#[doc(hidden)]` is ignored //~|  WARNING this was previously accepted #[doc(alias = "aka")] fn it0() {} //~^^ ERROR `#[doc(hidden)]` is ignored //~|  WARNING this was previously accepted #[doc(alias = "this", )] fn it1() {} //~^^ ERROR `#[doc(hidden)]` is ignored //~|  WARNING this was previously accepted #[doc()] fn it2() {} //~^^ ERROR `#[doc(hidden)]` is ignored //~|  WARNING this was previously accepted //~|  ERROR `#[doc(hidden)]` is ignored //~|  WARNING this was previously accepted } </del>

Related discussion:
text: The warning by claims that on an impl item is ignored by rustdoc, but it isn't necessarily. The warning says: which is not true in the following repro: This warning is a false positive. Rustdoc does pay attention to this attribute. For the code above, the rendered documentation of and looks like: <table<tr<td<img src="https://user-" height="185"</td<td<img src="https://user-" height="300"</td</tr</tableAfter removing the supposedly unused attribute and rendering again, the "nasty uninteresting type" that we wanted not shown is going to get rendered on both pages: <table<tr<td<img src="https://user-" height="185"</td<td<img src="https://user-" height="300"</td</tr</table( : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
My bad, I did not notice that at all . I can adjust the lint once it's decided how we are going to proceed with my changes in general (see / blocked on ). claim
In summary, on methods in trait impl blocks does not lead to any visual changes in the documentation whereas on associated types and constants, it hides the implementation (or “the thing to the right of the ”). This weirdly deviates from my (former) personal mental model of how is supposed to work and be used. As far as I know, in all other cases, it leads to items, impl blocks, fields (“names” or “declarations”) not being shown. Here, however, the “name” keeps being shown, only the “value” is hidden. Hiding an inherent assoc item for example, hides the item completely. “Hiding” a trait impl item is, in my opinion, currently handled inconsistently by rustdoc and shouldn't lead to any visual changes (or rather “shouldn't be allowed”). Out of curiosity, @ dtolnay, how / why do you use this feature? Do you use it to reduce visual clutter? Edit: Ah, well, I overlooked the top right picture. So in some cases the item is indeed entirely hidden, not just the value.
Should I remove the lint entirely or should I adjust ?
Code change:
<del> #![feature(inherent_associated_types)] #![allow(dead_code, incomplete_features)] #![crate_type = "lib"] #![deny(unused_attributes)] // run-rustfix pub trait Trait { type It; const IT: (); fn it0(); fn it1(); fn it2(); } pub struct Implementor; impl Implementor { #[doc(hidden)] // no error type Inh = (); #[doc(hidden)] // no error const INH: () = (); #[doc(hidden)] // no error fn inh() {} } impl Trait for Implementor { type It = (); //~^^ ERROR `#[doc(hidden)]` is ignored //~|  WARNING this was previously accepted const IT: () = (); //~^^ ERROR `#[doc(hidden)]` is ignored //~|  WARNING this was previously accepted #[doc(alias = "aka")] fn it0() {} //~^^ ERROR `#[doc(hidden)]` is ignored //~|  WARNING this was previously accepted #[doc(alias = "this", )] fn it1() {} //~^^ ERROR `#[doc(hidden)]` is ignored //~|  WARNING this was previously accepted #[doc()] fn it2() {} //~^^ ERROR `#[doc(hidden)]` is ignored //~|  WARNING this was previously accepted //~|  ERROR `#[doc(hidden)]` is ignored //~|  WARNING this was previously accepted } </del>

Related discussion:
text: Just wanted to add that this is also affecting , but in a different way: <img width="500" src="https://user-"The isn't there at all without the : <img width="500" src="https://user-"Based on the above, this isn't correct: it actually hides the entire thing, at least for associated constants.
In your case, it's inherent associated items being accidentally flagged which is which was meaning the most recent nightly should not have your issue anymore. Sorry for the inconvenience. The longer I look this lint, the less I like it.
Code change:
| LL |     async fn foo() {} |     ^^^^^^^^^^^^^^^^^ <ins> | = note: `async` trait functions are not currently supported = note: consider using the `async-trait` crate: https://crates.io/crates/async-trait </ins> error: aborting due to 10 previous errors <del> For more information about this error, try `rustc --explain E0670`. </del> <ins> Some errors have detailed explanations: E0670, E0706. For more information about an error, try `rustc --explain E0670`. </ins>

Related discussion:
text: we currently emit We should tell people that trait functions are not possible , and possibly point them to . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Created
Code change:
<del> Subproject commit 7c06679f93df53f83bbf61b197f2e5c39f5d7633 </del> <ins> Subproject commit ae9e9cb47c7b79d8bb29fab90929bd9b3606348a </ins>

Related discussion:
text: Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. 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! cc the PR reviewer, and -- nominating for prioritization.
Broken by
Miri fix:
triage: miri breakage gets P-medium.
Code change:
<ins> error: allocator `MyAllocatorWhichMustNotSuspend` held across a suspend point, but should not be --> $DIR/allocator.rs:24:9 | LL |     let x = Box::new_in(1i32, MyAllocatorWhichMustNotSuspend); |         ^ LL | LL |     suspend().await; |               ----- the value is held across this suspend point | help: consider using a block (`{ ... }`) to shrink the value's scope, ending before the suspend point --> $DIR/allocator.rs:24:9 | LL |     let x = Box::new_in(1i32, MyAllocatorWhichMustNotSuspend); |         ^ note: the lint level is defined here --> $DIR/allocator.rs:4:9 | LL | #![deny(must_not_suspend)] |         ^^^^^^^^^^^^^^^^ error: aborting due to 1 previous error </ins>

Related discussion:
text: This code here has a potential issue: If the Box has a custom allocator, then that will not be checked at all. So whatever is used for, it ignores anything stored in custom allocators. It seems like this is just for a lint, so this is probably not critical, but I guess should still be fixed. Cc -- not sure whom else to ping for coroutine state machine transform things?
Cc (also a regular occurrence in this file's )
Lol sorry, I thought I had clicked enter on a comment but I must've not. Let me rewrite it. Yeah, this is approximately the level of urgency you determined. This code exists for an unstable lint, . I don't expect people to be writing , but technically they could.
Code change:
across a recover boundary"] pub trait RecoverSafe {} <del> /// A marker trait representing types which do not contain an `UnsafeCell` by /// value internally. </del> <ins> /// A marker trait representing types where a shared reference is considered /// recover safe. /// /// This trait is namely not implemented by `UnsafeCell`, the root of all /// interior mutability. </ins> /// /// This is a "helper marker trait" used to provide impl blocks for the /// `RecoverSafe` trait, for more information see that documentation.

Related discussion:
text: Test Case 1: Test Case 2: Both produce errors like this: CC
Hm, so the first case here should work (e.g. should subvert basically everything), although the second case is correct in yielding an error (albeit not a very good one)
Is the second case not allowed then? 's documentation suggests that manually implementing it is okay to do: I figured only existed to wrap types which you couldn't yourself, but for which you can ensure their invariants are upheld across the boundary. And what about moving values into the closure? can't be unwrapped, at least not currently.
Oh wait sorry I misread your second example, I failed to notice the manual ! This is basically a case where closure captures are coming into play. The closures aren't annotated with , so outer variables are captured by-reference which means that the actual types being tested against the trait here are and . In the first case that should be handled by , but the second is legitimately indicating that it's not a recover-safe type (b/c the reference is different than the by-value). You should be able to get around this via either plus or via . Certainly an interesting interaction going on here though. One would likely expect that if isn't recover safe that would fix the problem but it's likely what you really need to do is due to the way closures largely work.
There's , why not ? Coherence?
Nah unfortunately that'd defeat the purpose of the distinction. The type is itself recover safe, it's just that's not (so the distinction need to be there)
It's unfortunate that fails due to coherence or something like that:
Hm interesting, I guess yeah you'll be forced to move the reference inside the wrapper rather than having a reference to the wrapper
Is it possible to implement then? My use case can contain and friends but I'm guaranteeing that they're unobservable in user code after recovery because I immediately re-panic after escaping the FFI stack.
I guess I can just use once it's fixed :stuckouttongue:. I see your PR has been accepted so I'll look forward to trying it on tonight's nightly. When do the buildbots fire?
Yeah currently you can implement (being renamed to ) I believe (although I can't say I've tried). For now though yeah I'd recommend just using plus closures.
Code change:
across a recover boundary"] pub trait RecoverSafe {} <del> /// A marker trait representing types which do not contain an `UnsafeCell` by /// value internally. </del> <ins> /// A marker trait representing types where a shared reference is considered /// recover safe. /// /// This trait is namely not implemented by `UnsafeCell`, the root of all /// interior mutability. </ins> /// /// This is a "helper marker trait" used to provide impl blocks for the /// `RecoverSafe` trait, for more information see that documentation.

Related discussion:
text: The PR is in but'll take a few hours at least to land.
the problem with moving at this point in time is that I call in different branches of a but I pass the same closed-over value to it; I can't do the branch in the closure because I need to do some FFI cleanup afterwards regardless of whether a panic happened or not (which also requires the closed-over value). It would help if derived and/or so I could reuse it without constructing a new value for each arm, but that would probably require some discussion because I don't know if it's safe or not. I'll probably just implement and fix the name after your PR drops. A quick check confirms that it works just fine. Thanks anyways!
Oh yeah we could totally add more traits like and to , there shouldn't be any safety concerns there.
Updating code to modern functions and traits in makes this compile, so I'm going to close.
Code change:
// tokens like `<<` from `rustc_lexer`, and then add fancier error recovery to it, // as there will be less overall work to do this way. let token = unicode_chars::check_for_substitution(self, start, c, &mut err); <ins> if c == 'x00' { err.help("source files must contain UTF-8 encoded text, unexpected null bytes might occur when a different encoding is used"); } </ins> err.emit(); token? }

Related discussion:
text: <!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --Saving a Hello World program as UTF-16: and trying to compile it causes about as many errors as there are characters in the file complaining of . Instead, using some heuristics to determine that the file is saved as UTF16 and printing a more helpful error message would be much friendlier to new users who are most likely to run into this issue. <!-- 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
There's still a question. Should throw an error and exit, or read the file using UTF 16?
I do not think rustc should parse the file as UTF-16, as this would introduce an ambiguity. I opened this issue only to address the poor UX of the current error messages.
release-assignment This seems more complicated than expected, because I dont know any reliable way to check if the file is utf-16.
Maybe add a help message when output error "unknown start of token: u{0}".
Code change:
} for child in self.resolver.module_children_or_reexports(module_id) { <del> if child.vis == Visibility::Public { </del> <ins> if child.vis == Visibility::Public || self.document_private_items { </ins> if let Some(def_id) = child.res.opt_def_id() { self.add_traits_in_parent_scope(def_id); }

Related discussion:
text: The ICE appears with and , but not . Beta: <details<summary<strongBacktrace</strong</summary<p</p</details
this is a regression affecting the release that is being prepared today.
I'll take a look.
Code change:
fn read_scope_id(&mut self) -> Option<u32> { self.read_atomically(|p| { p.read_given_char('%')?; <del> p.read_number(10, None) </del> <ins> p.read_number(10, None, true) </ins> }) }

Related discussion:
text: According to the , "The four octets are in decimal notation, divided by . (this is called 'dot-decimal notation'). Notably, octal numbers and hexadecimal numbers are not allowed per IETF RFC 6943"; however the parsing of the violates the "strict" form mentioned in —this form is what prohibits octal and hexadecimal numbers—meanwhile the conforms to it. IETF RFC 6943 Section 3.1.1. states: If the af argument of inetpton() is AFINET, the src string shall be in the standard IPv4 dotted-decimal form: where "ddd" is a one to three digit decimal number between 0 and The inetpton() function does not accept other formats (such as the octal numbers, hexadecimal numbers, and fewer than four numbers that inetaddr() accepts). As shown above, inetpton() uses what we will refer to as the "strict" form of an IPv4 address literal. Some platforms also use the strict form with getaddrinfo() when the AINUMERICHOST flag is passed to it. I tried this code: I expected to see this happen: both s not causing a panic since the first has an octet represented by more than three base-10 numbers despite the requirement per RFC 6943 stating each octet be a "one to three digit decimal number". The second is valid per RFC 6943 since it is a string of exactly 4 octets separated by where each octet is a "one to three digit decimal number". Instead, this happened: Both lines cause a panic. : : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
I believe that the second input () is not valid, since the spec explicitly says that octal numbers are disallowed, and is an octal number in the loose form. The example in the RFC for an octal number is , which parses to if you use octal, but if you use decimal. If you instead have it parse it always as , that means that bad things can happen, such as different tools interpreting as different things.
Code change:
fn read_scope_id(&mut self) -> Option<u32> { self.read_atomically(|p| { p.read_given_char('%')?; <del> p.read_number(10, None) </del> <ins> p.read_number(10, None, true) </ins> }) }

Related discussion:
text: If you read the source code where the ipv4 address is parsed, it specifically disallows that: Regarding , the documentation only says that the disallowing of hexadecimal and octal numbers are according to IETF RFC 6943, and does not say anything about only allowing three digits. Also, four or more zeroes are an edge case, and thus the only numbers that can be parsed there with more than three digits, due to the disallowing of octal numbers apart from .
From the :
I'm confused by these comments. Padded zeros is not unique to the base-8 numeral system. Base-2, Base-3, etc. all have the property of having an infinite number of padded zeros with the convention being to truncate them all. After all is also valid in base-8, base-9, etc. The documentation is quite clear that the octets are to be interpreted in base-10 though, so this problem of how to interpret the octets is solved. Consequently the last octet in is interpreted as 1 in base-10 for the same reason the first octet in is interpreted as 127 in base-10 and not some other value (e.g., 87 in base-10) namely because the documentation says so. After all objecting to on the grounds that the last octet could be in base-8—again, all of the octets there could be in base-8—doesn't apply to the fact that is also rejected by the parsing algorithm since clearly each of those octets are not in base-8 since is not a symbol in the base-8 numeral system. This is of course nothing more than a consequence of incorrectly assuming padded 0s means base-8. The inconsistent treatment of 0 (in base-10) is also a consequence of this incorrect assumption. Why is 0 (in base-10) allowed to be represented by one or more s, but 1 (in base-10) cannot have padded s? There is nothing special about the syntactic representation of 0 (in base-10) that warrants this inconsistent treatment. To me the solution is clear: more strictly follow IETF RFC 6943 and enforce that each octet be one-to-three digits in length.