jiebi/CodeConvo huggingface dataset:
Change:
.generic_activity("codegen prelude") .run(|| crate::abi::codegen_fn_prelude(fx, start_block)); <del> for (bb, bb_data) in fx.mir.basic_blocks.iter_enumerated() { </del> <ins> for (bb, bb_data) in traversal::mono_reachable(fx.mir, fx.tcx, fx.instance) { </ins> let block = fx.get_block(bb); fx.bcx.switch_to_block(block);

Discussion:
tracking issue: Inspired by comment in For things like it'd be nice to not have to even give LLVM the code for the else branch to have to emit. Ought to save time and binary size. Tentatively marked mir-opt, since we presumably still need to make the MIR for it, in order to borrow-check and such the unreachable code. But might need to be codegen-time instead to pick up on monomorphized inline constants. Hopefully should be doable relatively easily when the const is an inline const, since that forces const folding already, and thus there should just be a in the MIR.
Well, turns out this already works for simple constants in MIR! However, the place I actually needed it was more like , which doesn't work with today. So maybe come back to this once that's fixed.
This should be done by which AFAIK is run unconditionally. I wonder if its match needs to be expanded? Is there mcve?
The problem is that this can't be done on generic constants, as we don't mir-optimize post-monomorphization. We could start doing some benchmarks to see how bad running all mir opts (or at least a select few) would be if we duplicated, substituted and optimized MIR bodies for concrete generic parameters.
I would say qualifies as an MCVE as the monomorphized gives the following llvm ir
Maybe it should also be evaluated together with polymorphization or constevaluatablechecked since those can cut down on the duplication before applying further optimizations.
Bonus points if this can avoid monomorphizing functions called in the dead code too. Demo extracted from : (cc ) Would be great to not codegen all the downstream stuff that's only called in the else block of a .
FYI this should work with
Totally wild (and probably bad) idea: could we avoid borrow-checking unreachable code? After all, the purpose of borrow-checking is to prevent memory unsafety at runtime, but unreachable code cannot be memory unsafe, because it never executes!
We already do! As a , (But this isn't really the right issue to discuss possible extensions to that.)
This seems closely related to and
recent PR seems related here? If the condition becomes a constant during codegen, we should be entirely skipping it now and not even generate LLVM IR.

However, if that dead code calls functions, those still get codegen'd as usual -- the collector that determines which function to codegen doesn't know about dead branches. We'd have to embed a (simple) monomorphization-time reachability analysis in the collector to fix that.
Change:
stringify!($MaxV), ");", $EndFeature, " ```"), #[stable(feature = "rust1", since = "1.0.0")] <ins> #[rustc_promotable] </ins> #[inline] pub const fn max_value() -> Self { !0 } }

Discussion:
apint fails to compile (https://crater-) on beta. Note that the crate must be compiled in test mode.
cc -- I believe this is your crate, though it seems plausible this is a bug in the compiler
cc -- beta/stable regression, would be good to proactively triage before meeting if possible
Could this be promotion-related?
Yea. The call to on arrays does not actually do what it advertises, it derefs to a slice and then does . We stopped allowing const fns in promoteds is still marked as promotable, so that shouldn't be the issue. I'll investigate later today when I get back to a PC
yeah that's my crate thanks for linking! I have already stumbled upon this CI error but couldn't yet find time to wrap my head around it. Though I thought it was a bug in a former version of the borrow checker that now got fixed. So if I understood correctly simply using a instead of plain would solve that issue? Maybe we should reiterate on this design for on arrays if that's the case. :D
minimal repro Nope, it's a new bug that I was sure we had regression tests against.
This was injected between rustc 1.31.0-nightly ( 2018-10-03) and rustc 1.31.0-nightly ( 2018-10-04) Log of bors commits in that time in the details block <details% git log .. --author bors --format=oneline Auto merge of - nikomatsakis:universes-refactor-1, r=scalexm Auto merge of - matthewjasper:mir-function-spans, r=pnkfelix Auto merge of - Manishearth:clippyup, r=oli-obk Auto merge of - pietroalbini:rollup, r=pietroalbini Auto merge of - christianpoveda:master, r=kennytm Auto merge of - oli-obk:local_promotion, r=eddyb Auto merge of - arielb1:evaluate-outlives, r=nikomatsakis Auto merge of - KiChjang:issue-, r=nikomatsakis Auto merge of - davidtwco:issue-, r=petrochenkov </details
Hmm I wonder if this could somehow be a consequence fo ...?

update: probably not, since this afflicts both AST-borrowck and MIR-borrowck.
Full diff: (limiting promotability of const fns) also fell in there.
I even unit tests, but never any for promoting functions from the libstd. will only work if a function call is promoted in the same crate where the function is declared. I think the solution is to make the const qualifier eagerly call while a function is qualified to cache the result (in the query engine), so that the query is never evaluated in the perspective of another crate (and add an ) to to safeguard against messing this up
Discussed a bit with and investigated independently. Some details of note: The implementation of relies on . If you don't have the latter, the former will essentially be silently ignored, AFAICT. It seems like there are some holes in 's analysis above. In particular, I attempted to make a unit test with multiple crates, and it seemed like promotion was still happening. See here:
reassigning to for followup investigation and hopefully fixing.
Change:
} #[test] <ins> fn cell_set() { let cell = Cell::new(10); cell.set(20); assert_eq!(20, cell.get()); let cell = Cell::new("Hello".to_owned()); cell.set("World".to_owned()); assert_eq!("World".to_owned(), cell.into_inner()); } #[test] fn cell_replace() { let cell = Cell::new(10); assert_eq!(10, cell.replace(20)); assert_eq!(20, cell.get()); let cell = Cell::new("Hello".to_owned()); assert_eq!("Hello".to_owned(), cell.replace("World".to_owned())); assert_eq!("World".to_owned(), cell.into_inner()); } #[test] fn cell_into_inner() { let cell = Cell::new(10); assert_eq!(10, cell.into_inner()); let cell = Cell::new("Hello world".to_owned()); assert_eq!("Hello world".to_owned(), cell.into_inner()); } #[test] </ins> fn refcell_default() { let cell: RefCell<u64> = Default::default(); assert_eq!(0, *cell.borrow());

Discussion:
broke a library of mine where I had code like this: calls that used to call this trait method now call the new inherent method, but since that’s unstable the crate didn’t build until I . After that I could remove the trait since the new method has the same behavior. Anyway, this is just FYI. If we don’t want this kind of breakage we can’t add any new method to existing types ever, so that doesn’t sound viable. If the new method had had different behavior or if I wanted to keep supporting older compilers, it wouldn’t be too hard to rename my trait’s method or use UFCS.
Yeah in general we reserve the right to break downstream code with differences in method resolution because the downstream code can always be written in an "elaborated" form which works on all compilers (e.g. using ufcs). If a change to the standard library breaks an excessive amount of code in the ecosystem, though, then we'd need to take the steps much more purposefully.
Sounds good. Again, I don’t expect anything to change here and only made the previous comment to let people know this happened. I made this particular crate as an experiment, I don’t know of anyone actually using it.
Given that the core changes to the bounds on existing methods were instantly stable, it doesn't make a lot of sense to keep and as unstable. I propose we immediately stabilize these APIs. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, 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! See for info about what commands tagged team members can give me.
ping (checkbox)
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
What’s the next step here? Batch stabilization PR near the end of the release cycle?
Yep, I'm preparing one right now.
Change:
fn expand_rn(cx: &mut ExtCtxt, sp: Span, args: &[TokenTree]) -> Box<MacResult + 'static> { <del> static NUMERALS: &'static [(&'static str, u32)] = &[ </del> <ins> static NUMERALS: &'static [(&'static str, usize)] = &[ </ins> ("M", 1000), ("CM", 900), ("D", 500), ("CD", 400), ("C",  100), ("XC",  90), ("L",  50), ("XL",  40), ("X",   10), ("IX",   9), ("V",   5), ("IV",   4), ("I",    1)]; <del> let text = match args { [TokenTree::Token(_, token::Ident(s, _))] => s.to_string(), </del> <ins> if args.len() != 1 { cx.span_err( sp, &format!("argument should be a single identifier, but got {} arguments", args.len())); return DummyResult::any(sp); } let text = match args[0] { TokenTree::Token(_, token::Ident(s, _)) => s.to_string(), </ins> _ => { cx.span_err(sp, "argument should be a single identifier"); return DummyResult::any(sp);

Discussion:
The first example
Thanks, these are hard to keep in sync, as they don't get automated testing :/
Change:
<ins> use std::rc::Rc; type Foo<'a, T> = &'a dyn Fn(&T); type RcFoo<'a, T> = Rc<Foo<'a, T>>; fn bar_function<T>(function: Foo<T>) -> RcFoo<T> { //~^ ERROR mismatched types let rc = Rc::new(function); } fn main() {} </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It seems that the ICE does not occur on latest nightly.
Yes indeed. I was told to still submit bugs even when they only occur on newest Beta.
label +E-needs-test
claim To add the test
If someone finds out which nightly pr fixed it I guess we could consider a backport to beta?
I fixed this in . I'll beta nominate it.
Change:
// option. This file may not be copied, modified, or distributed // except according to those terms. <del> #![feature(generators, generator_trait, rustc_attrs)] </del> <ins> #![feature(generators, generator_trait)] </ins> use std::ops::Generator; <del> fn main() { #![rustc_error] // rust-lang/rust#49855 </del> <ins> fn main() { </ins> let _b = { let a = 3; unsafe { (|| yield &a).resume() }

Discussion:
Code shows a case where doesn't stay borrowed for long enough allowing it to be mutated while a reference to it exists. I think treating generators as if they implement would fix this, but I'm not sure if this will end up causing incorrect errors in other places.
Change:
mentioned earlier, you can use double colons to refer to sub-modules and the functions inside of them. <ins> (Note: when importing a crate that has dashes in its name "like-this", which is not a valid Rust identifier, it will be converted by changing the dashes to underscores, so you would write `extern crate like_this;`.) </ins> Also, Cargo assumes that `src/main.rs` is the crate root of a binary crate, rather than a library crate. Our package now has two crates: `src/lib.rs` and `src/main.rs`. This pattern is quite common for executable crates: most

Discussion:
/u/DroidLogician on reddit that the syntax is undocumeted, at least in the crates and module chapter of TRPL. this seems like your territory :)
Also the syntax.
As mentioned later in that reddit thread, is now without quotes. hasn't worked since the addition of turning into in crate names.
I think this can be closed.
Change:
error: cannot specialize on trait `SpecMarker` <del> --> $DIR/specialize_on_trait.rs:15:1 </del> <ins> --> $DIR/specialize_on_trait.rs:15:9 </ins> | LL | impl<T: SpecMarker> X for T { <del> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ </del> <ins> |         ^^^^^^^^^^ </ins> error: aborting due to previous error

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. --Given the following code: <!-- Please provide a link to -- The current output is: <!-- The following is not always necessary. --Ideally the output should not reference the debug format of an internal type <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. The output might also be different depending on the Edition. -- modify labels +F-specialization +A-specialization +requires-nightly
Change:
vis: ast::Visibility::Public, }))); <del> match self.expand(krate_item).make_items().pop().unwrap().unwrap() { ast::Item { attrs, node: ast::ItemKind::Mod(module), .. } => { </del> <ins> match self.expand(krate_item).make_items().pop().map(P::unwrap) { Some(ast::Item { attrs, node: ast::ItemKind::Mod(module), .. }) => { </ins> krate.attrs = attrs; krate.module = module; }, <ins> None => { // Resolution failed so we return an empty expansion krate.attrs = vec![]; krate.module = ast::Mod { inner: orig_mod_span, items: vec![], }; }, </ins> _ => unreachable!(), };

Discussion:
An ICE occurs when invoking a procedural macro attribute on the root of a crate with . Relevant backtrace frames: This happens on the latest nightly . cc
If you haven't started on this one I'll go ahead and take a crack at it since people are stumbling on it.
That second unwrap is which is infallible. That's kind of misleading, but okay.
Change:
use crate::collections::TryReserveError; use crate::fmt; use crate::hash::{Hash, Hasher}; <del> use crate::iter::FromIterator; </del> <ins> use crate::iter::{FromIterator, FusedIterator}; </ins> use crate::mem; use crate::ops; use crate::rc::Rc;

Discussion:
iterates over (which point to a slice of bytes in memory). When the code points expire (no more bytes available in the slice), there is no chance of the iterator ever returning more values. Therefore, should implement . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It is currently fused in practice and I don't think there's a good reason to change that in the future. This would technically be an API change but one that should have no negative impact to existing code. Which is the long winded way of saying I agree.
Thanks for the quick response! I realize that this is an API change but didn't feel it'd warrant a "feature suggestion". I guess for now I'm just throwing the idea out there.
This is a great idea and I'd be happy to see a PR that implements it. I was just ticking off a checklist. It's not a breaking change and it is useful, so implementing it should not be at all controversial.
Sounds good, I'll get to it tomorrow! claim
Note that, procedurally, a new trait impl is insta-stable so will need a FCP. (That's totally ok, just wanted to note it. You can and should send a PR for it.)
Change:
}, ); <del> err.span_suggestion(span, msg, "", Applicability::MaybeIncorrect); </del> <ins> if span.is_empty() { // HACK: Avoid ICE when types with the same name with `derive`s are in the same scope: //     struct NotSM; //     #[derive(PartialEq, Eq)] //     struct NotSM<T>(T); // With the above code, the suggestion would be to remove the generics of the first // `NotSM`, which doesn't *have* generics, so we would suggest to remove no code with // no code, which would trigger an `assert!` later. Ideally, we would do something a // bit more principled. See closed PR #109082. } else { err.span_suggestion(span, msg, "", Applicability::MaybeIncorrect); } </ins> } else if redundant_lifetime_args && redundant_type_or_const_args { remove_lifetime_args(err); remove_type_or_const_args(err);

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. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: The message is kinda bad and trying to highlighting code that only exists behind the derive (is not visible to the user) Debug ice: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Change:
<ins> # ignore-cross-compile we need to execute the binary # ignore-windows we create files with < and > in their names include ../tools.mk ifdef RUSTC_BLESS_TEST RUSTC_TEST_OP = cp else RUSTC_TEST_OP = $(DIFF) endif all: echo '"comes from a file with a name that begins with <"' > "$(TMPDIR)/<leading-lt" echo '"comes from a file with a name that ends with >"' > "$(TMPDIR)/trailing-gt>" cp silly-file-names.rs "$(TMPDIR)/silly-file-names.rs" $(RUSTC) "$(TMPDIR)/silly-file-names.rs" -o "$(TMPDIR)/silly-file-names" "$(TMPDIR)/silly-file-names" > "$(TMPDIR)/silly-file-names.run.stdout" $(RUSTC_TEST_OP) "$(TMPDIR)/silly-file-names.run.stdout" silly-file-names.run.stdout </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. --Requirement: Create an empty file called '', i.e. using <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Hmm, we should only disallow (since that's what we use for non-real "files") although I guess or even just might be a valid path itself? Internally we can tell apart between the two, I'm guessing this is to avoid tools seeing something with or in it and misinterpreting it as not a real file? But in that case we'd want a real error not an assert. cc
Marked as p-medium based on the discussion on the
PR with fix:
Change:
<ins> TokenStream [ Literal { kind: Integer, symbol: "1", suffix: None, span: #0 bytes(172..173), }, Literal { kind: Integer, symbol: "17", suffix: Some("u8"), span: #0 bytes(182..186), }, Literal { kind: Float, symbol: "42.", suffix: None, span: #0 bytes(195..198), }, Literal { kind: Float, symbol: "3.14", suffix: Some("f32"), span: #0 bytes(207..214), }, Literal { kind: Byte, symbol: "a", suffix: None, span: #0 bytes(223..227), }, Literal { kind: Byte, symbol: "xFF", suffix: None, span: #0 bytes(236..243), }, Literal { kind: Char, symbol: "c", suffix: None, span: #0 bytes(252..255), }, Literal { kind: Char, symbol: "x32", suffix: None, span: #0 bytes(264..270), }, Literal { kind: Str, symbol: ""str"", suffix: None, span: #0 bytes(279..288), }, Literal { kind: StrRaw(1), symbol: ""raw" str", suffix: None, span: #0 bytes(297..311), }, Literal { kind: StrRaw(3), symbol: "very ##"raw"## str", suffix: None, span: #0 bytes(320..347), }, Literal { kind: ByteStr, symbol: ""byte" str", suffix: None, span: #0 bytes(356..371), }, Literal { kind: ByteStrRaw(1), symbol: ""raw" "byte" str", suffix: None, span: #0 bytes(380..402), }, Literal { kind: CStr, symbol: ""c" str", suffix: None, span: #0 bytes(411..423), }, Literal { kind: CStrRaw(1), symbol: ""raw" "c" str", suffix: None, span: #0 bytes(432..451), }, ] 1 17u8 42. 3.14f32 b'a' b'xFF' 'c' 'x32' ""str"" r#""raw" str"# r###"very ##"raw"## str"### b""byte" str" br#""raw" "byte" str"# c""c" str" cr#""raw" "c" str"# </ins>

Discussion:
Current output as of nightly-2023-06-20: The correct output would have . The ToString of procmacro::Literal is the only interface by which proc macros are able to inspect literals. It is supposed to include the entire literal, with quotes and escape sequences and everything as originally appear in the source code. Without this, it is impossible for proc macros to operate correctly on literals. For example, it would currently be impossible for a proc macro to tell the difference between and , but those are not the same token. Mentioning tracking issue: Mentioning since you have worked on this feature in the past. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Does resolve this or is there more?
Not fixed as of rustc 1.73.0-nightly ( 2023-08-02).
Change:
.label = unused variable .suggestion = if this is intentional, prefix it with an underscore passes_used_compiler_linker = `used(compiler)` and `used(linker)` can't be used together

Discussion:
Consider the following file in a cargo package: Cargo will warn that is not used. Upon running , cargo will change the second parameter from to , making the compilation fail. Even worse, if contained a field then would change the variable without producing any warning. a new cargo binary project with the above snippet in (presumably with ) No response No response
just applies any  suggestion produced by . In this case, the suggestion from is to replace with . I went ahead and ran to see if it could help me understand what is going on better: ` (I cleaned up the expanded code slightly, but it is the same) Looking at the expanded code, it makes me think that is seeing in as the source of the problem since it expands to and is unused in this case. The normal suggestion is to add an underscore to so it would not be "unused". So suggests to change the being passed to the macro call as it does not understand that the warning is really coming from within the macro, not the call itself. It also could be suggesting this as is not valid rust (macro?) syntax. If you change your example slightly, correctly suggests the problem comes from within the macro call. To me, this seems like a problem with , but I do not know enough about the compiler internals to be 100% certain.
Transferred to rust-lang/rust, since the suggestions are generated by the compiler.
Yes, this issue comes from rustc. The lint is emitted from here Maybe we only point out that there is an unused variable coming from , but without the suggestion? I'm not sure what is a proper lint for this test case. any thoughts on it?
The quick and straightforward way to fix this would be to only emit the suggestion in this lint if the span has the root context, but then a subset of valid suggestions wouldn't be emitted. I had an older PR that I'm having trouble finding that would automatically do that for every diagnostic, but IIRC it had some negative perf impact when not implementing it very simplistic. In this we can probably instead check that all of the spans involved have the same . If they don't, don't suggest changes.