jiebi/CodeConvo huggingface dataset:
Change:
($dst:expr,) => ( writeln!($dst) ); <del> ($dst:expr, $fmt:expr) => ( write!($dst, concat!($fmt, "n")) ); ($dst:expr, $fmt:expr, $($arg:tt)*) => ( write!($dst, concat!($fmt, "n"), $($arg)*) </del> <ins> ($dst:expr, $($arg:tt)*) => ( $dst.write_fmt(format_args_nl!($($arg)*)) </ins> ); }

Discussion:
The following all compile and run for example: I would expect them to produce "error: format argument must be a string literal." like does. This is because they use things like but accepts other literals not just . I assume this isn't intentional.
One way to fix this is to replace 's definition with I would prefer to force and friends to take strings but at least this keeps it consistent. EDIT: I honestly don't like how automatically stringifies, it seems kinda ugly and I feel like there should be a separate macro that does compile-time stringification. This would almost certainly be super backwards-incompatible though.
awesome! Why do the places that need 's stringifying functionality not use so doesn't duplicate functionality? That would solve this issue. EDIT: Turns out is different to , the latter only accepts literals whereas the former will verbatim stringify token trees, such as .
Seems like it'd be a breaking change to "fix" this.
For it is explicit and by design, so that part is no problem.
good point, actually has it's own unintuitive behaviour similar but different to .
Why do we consider that the code like works to be a bug? I understand that forbidding it will make more consistent and explicit but we're trading in some convenience here. The other option could be to make behave in same way.
it's not documented so technically something needs to fixed, even if it's just the documentation. If we make behave the same then surely we'd have to change and as well to keep things consistent and I don't think that's a good idea as this isn't even useful. I think this should either be fixed as a breaking change, I doubt it will break much if any real world code, or just depreciated.
thanks for the clarifications, thats makes sense now. I'm not sure and should behave exactly as and as the two groups of macros serve different purposes. Maybe one more special case doesn't worth it however.
Libs team consensus: while it may be desirable to clean this up, this is not breakage we're willing to take on during the Rust 1.x series. I've a new tag, closed-as-desirable-breakage, to help us track issues like this that we might want to revisit if we ever produce a 2.0 release.
related issue: accepts non-bools
Sadly, has been implemented with this bug, so is also affected: .
This would be improved by
Change:
currently_processing_generics: bool, /// The current enclosing function (used for better errors). <del> current_function: Option<Span>, </del> <ins> current_function: Option<(FnKind<'ast>, Span)>, </ins> /// A list of labels as of yet unused. Labels will be removed from this map when /// they are used (in a `break` or `continue` statement)

Discussion:
Hi, ... returns: () Message says , even though it does have a parameter, which is kinda confusing. This happens only on beta and nightly, since current stable doesn't provide that hint at all. Thanks, Patryk.
This happened to me on an old nightly (I believe 1.38.0 when it was still nightly, I may be wrong)
Running into this issue on latest stable as well. What is the actual problem?
I just ran into what appears to be the same issue on , in the context of a trait method.
Change:
//~^ ERROR functions are not allowed in enum definitions //~| HELP unlike in C++, Java, and C#, functions are declared in `impl` blocks //~| HELP see https://doc.rust-lang.org/book/ch05-03-method-syntax.html for more information <ins> //~| HELP enum variants can be `Variant`, `Variant = <integer>`, `Variant(Type, ..., TypeN)` or `Variant { fields: Types }` </ins> } fn main() {}

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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Although I know Enums take to form of: I sometimes find myself accidentally defining them as I would a Struct (): The current output is: This always takes more than a few seconds to parse and then realize my mistake. Is it possible to change this to something like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Do you have any suggestion for how the compiler should distinguish between "trying to write an enum with struct syntax" and "trying to write a struct but used the enum keyword"?
Linking to the topic on internals where some other folks have left suggestions (). Although none of those directly address your question. My gut reaction is to assume that if the "enum" keyword is used that truly was the intention of the developer, but if it wasn't, hopefully some help message like the : Would provide enough information to trigger an "Oh wait did I really want to use an enum here?"
claim
Change:
match err { LayoutError::Unknown(..) | LayoutError::ReferencesError(..) => Self::UnknownLayout, LayoutError::SizeOverflow(..) => Self::SizeOverflow, <ins> LayoutError::Cycle(err) => Self::TypeError(*err), </ins> err => unimplemented!("{:?}", err), } }

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'not implemented: Cycle'', 'thread 'rustc' panicked at 'not implemented: Cycle'' 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
/ ping :grin:
Change:
} } <del> /// Pushes new obligations into `out`. Returns `true` if it was able /// to generate all the predicates needed to validate that `ty0` /// is WF. Returns false if `ty0` is an unresolved type variable, /// in which case we are not able to simplify at all. fn compute(&mut self, ty0: Ty<'tcx>) -> bool { let mut walker = ty0.walk(); </del> <ins> /// Pushes all the predicates needed to validate that `ty` is WF into `out`. fn compute(&mut self, ty: Ty<'tcx>) { let mut walker = ty.walk(); </ins> let param_env = self.param_env; while let Some(arg) = walker.next() { let ty = match arg.unpack() {

Discussion:
returns if it can't make progress on an inference variable, and the original obligation should be retried later. However, doesn't check that return type and may (incorrectly) return no obligations. On I suggested this: I'm pretty sure now that it would've prevented this bug. <hr/Looking at the users, only uses this function, and only for the user-specified bounds, so it's possible inference variables are impossible to find (unless normalization introduces them, I guess?). It might be fine to just create obligation for the instead of bailing out (see below, this is the same as moving out of ) It's true that can't be found as the first type in the recursive call, but is a , and it uses . (EDIT: Read the code more carefully and the check is , so while it's not an early like I would prefer, it does seem to only trigger on the root type) However, a few other things call and it would be fine for them to create an obligation rather than erroring out, so maybe itself should do that check? cc
changes the return type of to a and discards it using . Might cause us to be slightly more cautious in the future.
I'm working on a fix that makes itself never bail out, so the check is done in , hopefully that will also work nicely for consts. EDIT: opened .
Change:
FakeReadCause, Local, LocalDecl, LocalInfo, LocalKind, Location, Operand, Place, PlaceRef, ProjectionElem, Rvalue, Statement, StatementKind, Terminator, TerminatorKind, VarBindingForm, }; <del> use rustc_middle::ty::{self, suggest_constraining_type_param, Instance, Ty}; use rustc_span::{source_map::DesugaringKind, symbol::sym, Span}; </del> <ins> use rustc_middle::ty::{self, suggest_constraining_type_param, Ty, TypeFoldable}; use rustc_span::source_map::DesugaringKind; use rustc_span::symbol::sym; use rustc_span::Span; </ins> use crate::dataflow::drop_flag_effects; use crate::dataflow::indexes::{MoveOutIndex, MovePathIndex}; use crate::util::borrowck_errors; use crate::borrow_check::{ <del> borrow_set::BorrowData, prefixes::IsPrefixOf, InitializationRequiringAction, MirBorrowckCtxt, PrefixSet, WriteKind, </del> <ins> borrow_set::BorrowData, diagnostics::Instance, prefixes::IsPrefixOf, InitializationRequiringAction, MirBorrowckCtxt, PrefixSet, WriteKind, </ins> }; use super::{

Discussion:
Given a situation where an iterator is : We should suggest using in these cases. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Or flatten/flat_map?
I want for us to detect cases of trying to operate on iterators of iterators because the only option then is to allocate or completely rework the logic. The former will help newcomers, experts will know enough to try the later.
claim
Couldn't we still recommend both? Recommending bad practices seems suboptimal.
Change:
<del> Subproject commit 2855b2143972df7102333193aa3c83ddce227e36 </del> <ins> Subproject commit 8fbb23f2549e75b89967f09b9293607bd3bb96a6 </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver 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 compiler team prioritization.
[triagebot]
Change:
#[stable(feature = "rust1", since = "1.0.0")] impl PartialEq for OsStr { <ins> #[inline] </ins> fn eq(&self, other: &OsStr) -> bool { self.bytes().eq(other.bytes()) }

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> /// An error which can be returned when parsing a char. #[stable(feature = "char_from_str", since = "1.19.0")] #[derive(Clone, Debug)] pub struct ParseCharError { kind: CharErrorKind, } impl ParseCharError { #[unstable(feature = "char_error_internals", reason = "this method should not be available publicly", issue = "0")] #[doc(hidden)] pub fn __description(&self) -> &str { match self.kind { CharErrorKind::EmptyString => { "cannot parse char from empty string" }, CharErrorKind::TooManyChars => "too many characters in string" } } } #[derive(Copy, Clone, Debug, PartialEq, Eq)] enum CharErrorKind { EmptyString, TooManyChars, } #[stable(feature = "char_from_str", since = "1.19.0")] impl fmt::Display for ParseCharError { fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { self.__description().fmt(f) } } #[stable(feature = "char_from_str", since = "1.19.0")] impl FromStr for char { type Err = ParseCharError; #[inline] fn from_str(s: &str) -> Result<Self, Self::Err> { let mut chars = s.chars(); match (chars.next(), chars.next()) { (None, _) => { Err(ParseCharError { kind: CharErrorKind::EmptyString }) }, (Some(c), None) => Ok(c), _ => { Err(ParseCharError { kind: CharErrorKind::TooManyChars }) } } } } </ins> #[unstable(feature = "try_from", issue = "33417")] impl TryFrom<u32> for char { type Error = CharTryFromError;

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:
llvm_abiname: "lp64d".into(), supported_sanitizers: SanitizerSet::ADDRESS, max_atomic_width: Some(64), <ins> supported_split_debuginfo: Cow::Borrowed(&[SplitDebuginfo::Off]), </ins> ..base::android::opts() }, }

Discussion:
On riscv64gc linux, split-debuginfo ="unpacked" caused error: A dwo section may not contain relocations. For rust 1.64, this error occurs. For rust <=1.64, cargo didn't pass flag to rustc. For rust 1.64, a segmentation fault happens in rustc. For rust < 1.64, it builds fine I think the behavior of rust < 1.64 is correct. The following steps: caused the following failure: No response Related:
Transferred to rust-lang/rust, since this looks to be a compiler issue.
says that LLVM doesn't support this combination of flags. It's unclear to me whether it's impossible or just not implemented yet, but in the meantime, cargo should probably stop passing -C split-debuginfo to proc-macros? there's some mention of in the upstream issue, I'm not sure how that's related.
The report above doesn't mention proc-macros. It seems to happen for normal binaries. The following seems to fail for me: If split-debuginfo isn't supported on this target, then rustc should report that it isn't supported (Cargo already tests for this). I believe that is defined by the field in the target definition.
I'm getting the same issue with when cross compiling for , it seems to be all values except that causes issues.
Change:
<ins> #![feature(min_const_generics)] // This test checks that non-static lifetimes are prohibited under `min_const_generics`. It // currently emits an error with `min_const_generics`. This will ICE under `const_generics`. fn test<const N: usize>() {} fn issue_75323_and_74447_1<'a>() -> &'a () { test::<{ let _: &'a (); 3 },>(); //~^ ERROR a non-static lifetime is not allowed in a `const` &() } fn issue_75323_and_74447_2() { test::<{ let _: &(); 3 },>(); } fn issue_75323_and_74447_3() { test::<{ let _: &'static (); 3 },>(); } fn issue_73375<'a>() { [(); (|_: &'a u8| (), 0).1]; //~^ ERROR a non-static lifetime is not allowed in a `const` } fn main() {} </ins>

Discussion:
Nightly on playground <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
we should forbid lifetimes in anonymous constants to avoid this issue.

results in
Could this be a duplicate of ?
:+1: This probably has the same fix. I do think that the issues are different enough to keep this one open though
Change:
span, UnsafeOpInUnsafeFnCallToFunctionWithRequiresUnsafe { span, <del> function: &tcx.def_path_str(*did), </del> <ins> function: &with_no_trimmed_paths!(tcx.def_path_str(*did)), </ins> }, ), }

Discussion:
In some external crate, say : Main crate: : With , this gives the following ICE: <details<summary<strongBacktrace</strong</summary<p</p</detailsThis is because the lint to insert the name in the diagnostic message (this delays a good path bug), then the lint because it's in an external macro, which means we don't emit any diagnostic which triggers the good path bug. This ICE is currently preventing rustc from building with enabled. I see several ways to fix this: don't print the function name. It arguably carries little value, with the span already pointing to the offending function call, and brings THIR unsafeck in line with MIR unsafeck (cc ). 't trim the path. This might lead to longer messages but other lints already do this so it is probably acceptable? 't create the lint if we're in an external macro and we know the lint will be cancelled anyway. It's a little hacky and breaks down if changes are made to lint emission. the lint emission API to allow lint messages to be lazily evaluated. label +A-diagnostics +requires-nightly claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Error: Label thir-unsafeck can only be set by Rust team members Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
Would not trimming the path also be acceptable ? (via )
It looks like some lints are already not trimming paths so this is probably acceptable? I can do that if that's the preferred option.
claim
Change:
// As with typical function arguments, owned pointers // are automatically converted to references <del> (@s).draw_reference(); </del> (~s).draw_reference(); // Unlike typical function arguments, the self value will

Discussion:
Their continued existence in the tutorial is causing confusion over what the status of this feature is. Let all the world know that managed pointers are relegated to the dustbin of history!
It's unclear to me if the tutorial is being rewritten from scratch by Mozilla. There's not much motivation for anyone to work on it if it's just going to be thrown out.
That may be true, but if a good samaritan wanted to do just enough work to delete mentions of them from the current tutorial, it would not be unappreciated.
Hi, I am the one who asked about this initially. I have started to work on it now.
At this point I do think it's worthwhile to keep maintaining the tutorial. Even if it doesn't survive as the tutorial, it does contain a lot of information that will end up disseminated elsewhere.
Not maintaining the tutorial leads to a growing collection of inaccurate or wrong information. Removing it could give newcomers a better first-time experience of Rust.
Change:
fn configure_cmake(builder: &Builder<'_>, target: Interned<String>, cfg: &mut cmake::Config) { <ins> // Do not print installation messages for up-to-date files. // LLVM and LLD builds can produce a lot of those and hit CI limits on log size. cfg.define("CMAKE_INSTALL_MESSAGE", "LAZY"); </ins> if builder.config.ninja { cfg.generator("Ninja"); }

Discussion:
The "log is too long" error in reminded me about this possibility. will avoid printing installation messages for up-to-date files into the log. There are many of them in the log as you can see.
Ok, since it turned out to be a real problem blocking PRs, I'll try to implement it myself today.
Fixed in
Change:
<ins> // Verify that elided lifetimes inside anonymous constants are not forced to be `'static`. // check-pass fn foo() -> [(); { let a = 10_usize; let b: &'_ usize = &a; *b }] { [(); 10] } fn bar() -> [(); 10] { [(); { let a = 10_usize; let b: &'_ usize = &a; *b }] } fn main() {} </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 compile Instead, this happened: It errored <!-- 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. --: </p</details
this is also present with repeat exprs:
cc and
const generic defaults also are buggy around
Change:
pub type MonitorMsg = (TestDesc, TestResult, Vec<u8> ); <del> unsafe impl Send for MonitorMsg {} </del> fn run_tests<F>(opts: &TestOpts, tests: Vec<TestDescAndFn> ,

Discussion:
Compiling with works fine, definitely does not, though: And, if the bound in is removed, the code compiles fine with or without . So... somehow the test runner is causing a tuple of arity 3 specifically to be inferred to something completely ridiculous.
cc I guess?
points out that specifically having causes the problem.
cc me
FYI: discovered this problem while working on
Slightly more minimized:
contains: This causes the problem.
I'll take a look at it.
Oh, I see you tracked it down -- I thought it might be something like that. This is in fact something I was talking to about as a possible danger of the way we're treating builtin bounds right now, though in a different context.
In fact, I think that the for a tuple ought to be a coherence violation to begin with, actually.
(I think there was language about specifically this in the OIBIT RFC)
I agree with comments here and after a quick chat on IRC with him, we agreed that implementations of built-in traits (and likely default trait impls in the future) should be allowed just on and .
Change:
macro_rules! and_the_heavens_reject_not { () => { <del> // ↓ But let's test that we still lint for unused parens around // function args inside of simple, one-deep macros. </del> #[allow(dead_code)] fn the_night_for_the_morrow() -> Option<isize> { Some((2)) } <del> //~^ WARN unnecessary parentheses around function argument </del> } }

Discussion:
The latest beta contains a new? l lint that triggers on macro by example code. This does not necessarily make sense because macros could be used to construct nearly arbitrary custom syntax for example something requiring to wrap a single element into a parenthesis. The strange thing here is that seems to only happen on beta, not on nightly, not on current stable. Found via Error message: rustc version:
My head can't come up with an example that requires parentheses. macros are hygenic, so there should be no problem in omitting the parentheses and just writing will be fine. Can you give me a counter example?
A real world example is the diesel  macro. Somewhere in the inner it does some clever things to support plain types and tuples by just saying where is some repeated type variable. Depending on the number of actual types there this will result in which is a single type or which is a tuple. It's probably possible to rewrite that code doing the same stuff but that would involve a lot of duplication (Because than you would need to have a special case for a single type everywhere).
So somehing like this: You're right. The question is: should we remove the lint for all macros? Only for macros that contain repetitive expansions? (Is that even possible to detect?)
modify labels: A-lint T-compiler
Would be great to get that fixed till it is part of the next stable release.
This seems to occur first on nightly-2019-11-02
nominating for discussing at T-compiler + T-lang meeting, namely to take peoples' temperature with respect to the idea of just not linting this case when the flagged code appears as part of a macro definition.
also, marking as P-high w.r.t. answer the question(s) posed here. (I personally don't think the severity of the actual impact is likely to be worth a P-high rating; the priority is likely just temporary until the discussion happens.)
The language team discussed this last week. The general consensus was that we can stop linting when the redundant parens are inside the macro (as opposed to e.g. where the spans are from the outside). We believe this is fine as the lint is mostly a style thing which does not protect from anything correctness or performance related.
I've played a bit around with this issue today.

Seems like conditions need to be adjusted to also check if we are in macro expanded code. I've tried something like but that does remove more warnings that we want.
I think the questions have been basically answered in terms of what path we see best going forward. Self-assigning, removing I-nominated.