jiebi/CodeConvo huggingface dataset:
Change:
if let InnerAttributeParsePolicy::Permitted = inner_parse_policy { self.expected_tokens.push(TokenType::Token(token::Not)); } let style = if self.token == token::Not { self.bump(); <del> if let InnerAttributeParsePolicy::NotPermitted { reason } = inner_parse_policy { let span = self.token.span; self.diagnostic() .struct_span_err(span, reason) .note("inner attributes, like `#![no_std]`, annotate the item  enclosing them, and are usually found at the beginning of  source files. Outer attributes, like `#[test]`, annotate the  item following them.") .emit() } </del> ast::AttrStyle::Inner } else { ast::AttrStyle::Outer

Discussion:
Given the following we currently emit We should emit at least the following We might also want to provide suggestions when it makes sense (like turning the attr into an outer attr).
Hey , I tried to solve this with a little help of on a rust meetup. I wasn't able to run because of the following message. But I started to add some code you can read here: is this going into the right direction?
thank you for taking a look at this! You should be able to run the tests with . Use to update the relevant files. The code you've written would generate the following output: Instead, we'd want this to be a single error. What you'd want to do is 1) get the span for the prior attribute from 2) expand to also hold an extra field and 3) change the following to be This lets you point at the prior span in the same error. The second part of this ticket is changing the linked code to no longer use , but rather synthesize a new span from the first 's span to the closing . You can use to do so. Finally, we change the above to be something like
Are you still working on this? I'm thinking of giving it a try.
Go on! I don’t have so much time atm so just go there step by step while learning rust. If you want so solve it - awesome
Change:
match kind { Kind::Build => describe!( compile::Std, <del> compile::Rustc, </del> <ins> compile::Assemble, </ins> compile::CodegenBackend, compile::StartupObjects, tool::BuildManifest,

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've lost so much of my life to this. It looks like the critical missing line is . I would expect this to happen whenever I pass .
The part of emitting is , which is called by . The bit emitting 'Copy ...' is . Notably, does not_ call .
This does not fix the issue and I'm not sure why:
It looks like bootstrap mistakenly thinks that the compiler has been linked and is cached.
So this is still a bug, but it turns out it wouldn't do what I want anyway because it doesn't build . So it would only be able to build crates with (basically nothing).
Yeah you want something like build --stage 1 src/libcore (though we don't support separate crate builds currently, but we could). I think it's not possible today to get bootstrap to copy the compiler but not build anything with it - the compiler itself isn't considered an artifact in some sense.
Right, this issue is asking that to change. I think this would still be useful for what I'm doing now which is only printing the AST and not even doing name resolution ().
Once this is fixed, the docs for in rustc-dev-guide () should be moved to .
Change:
fn visit_assoc_item(&mut self, i: &'a AssocItem, ctxt: visit::AssocCtxt) { let def_data = match &i.kind { <del> AssocItemKind::Fn(_, FnSig { header, decl }, generics, body) if header.asyncness.is_async() => { return self.visit_async_fn( i.id, i.ident.name, i.span, header, generics, decl, body.as_deref(), ); } </del> AssocItemKind::Fn(..) | AssocItemKind::Const(..) => DefPathData::ValueNs(i.ident.name), AssocItemKind::TyAlias(..) => DefPathData::TypeNs(i.ident.name), AssocItemKind::Macro(..) => return self.visit_macro_invoc(i.id),

Discussion:
I was migrating my library (Mammut) to use reqwest and be async, and the compiler ICEd. I don't know how to reduce it further than this. I tried this code: I expected to see this happen: A successful build or another compile error Instead, this happened: I also tried this on the latest nightly and it emits the same error. : Backtrace:
Reproduced with lastest nighlty: ICE from macro resolving I believe. cc
cc
triage: P-high, removing nomination tag. (instead, going to proritize going through the P-high issues that have accumulated over last two weeks.)
Visiting from triage.. the next step is to reduce the reproducer.
Reduced ():
Further reduced:
Fixed in
Change:
#[cfg(target_os = "vxworks")] id: u16, ) -> &mut process::Command; <ins> /// Sets the supplementary group IDs for the calling process. Translates to /// a `setgroups` call in the child process. #[unstable(feature = "setgroups", issue = "38527", reason = "")] fn groups( &mut self, #[cfg(not(target_os = "vxworks"))] groups: &[u32], #[cfg(target_os = "vxworks")] groups: &[u16], ) -> &mut process::Command; </ins> /// Schedules a closure to be run just before the `exec` function is /// invoked. ///

Discussion:
already offers and methods to control the user identity of the child process (calling respectively). For complete control of Unix credentials, there should also be a way to call and the concept of the supplementary group list are; I would expect this not to be a portability concern.) This feature would eliminate a use of and an unsafe block (to call ) from the program I'm currently writing, which is a port to Rust of a setuid C program. For illustration, this function exists in the C version: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I would be prepared to consider a PR to add .
claim
Change:
// Before we go into the whole placeholder thing, just // quickly check if the self-type is a projection at all. match obligation.predicate.skip_binder().trait_ref.self_ty().kind() { <del> ty::Alias(..) => {} </del> <ins> // Excluding IATs here as they don't have meaningful item bounds. ty::Alias(ty::Projection | ty::Opaque, _) => {} </ins> ty::Infer(ty::TyVar(_)) => { span_bug!( obligation.cause.span,

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 --
This might also be related to cc
label F-inherentassociatedtypes claim
Change:
self.expr(sp, ast::ExprKind::Tup(exprs)) } <del> pub fn expr_fail(&self, span: Span, msg: Symbol) -> P<ast::Expr> { self.expr_call_global( </del> <ins> pub fn expr_unreachable(&self, span: Span) -> P<ast::Expr> { self.expr_macro_call( </ins> span, <del> [sym::std, sym::rt, sym::begin_panic].iter().map(|s| Ident::new(*s, span)).collect(), thin_vec![self.expr_str(span, msg)], </del> <ins> self.macro_call( span, self.path_global( span, [sym::std, sym::unreachable].map(|s| Ident::new(s, span)).to_vec(), ), ast::token::Delimiter::Parenthesis, ast::tokenstream::TokenStream::default(), ), </ins> ) } <del> pub fn expr_unreachable(&self, span: Span) -> P<ast::Expr> { self.expr_fail(span, Symbol::intern("internal error: entered unreachable code")) } </del> pub fn expr_ok(&self, sp: Span, expr: P<ast::Expr>) -> P<ast::Expr> { let ok = self.std_path(&[sym::result, sym::Result, sym::Ok]); self.expr_call_global(sp, ok, thin_vec![expr])

Discussion:
In chrono we have support for behind a feature flag. As a workaround for I the line: It now gives a new error: cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The derived implementation for an enum is using . Manually implementing and using is a workaround.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
cc
I'm actually not sure this is a T-libs issue. I suspect it's related to , but I haven't had a chance to look into it yet.
I have confirmed this is an issue with the expansion of on s and aim to have a PR up tonight. As is a built-in macro, it is technically in T-compiler land, I believe. claim
PR is up, including a regression test:
Change:
self.const_uint(self.type_i1(), val as u64) } <ins> fn const_i16(&self, i: i16) -> &'ll Value { self.const_int(self.type_i16(), i as i64) } </ins> fn const_i32(&self, i: i32) -> &'ll Value { self.const_int(self.type_i32(), i as i64) }

Discussion:
uses , and declares it to return i32, in reality it returns c_int, so this is a potential portability concern. Maybe memcmp can be made an intrinsic to resolve this.
It also takes a parameter, not a .
Neither of these are a practical issue (yet). crate libc does not support any other configuration than so far.
cc
The extern function is now in
What should we do next? Should we try to create a intrinsic?
Hi, I believe this issue is causing array comparisons on the AVR architecture to break (see the linked issue, ). Is there any consensus on a path forward here?
Change:
} else { sp }; <del> // FIXME: contrast `t.def_id` against `param.bounds` to not suggest // traits already there. That can happen when the cause is that // we're in a const scope or associated function used as a method. err.span_suggestions( sp, &message(format!( "restrict type parameter `{}` with", param.name.ident(), )), candidates.iter().map(|t| { format!( "{}{} {}{}", </del> <ins> let trait_def_ids: FxHashSet<DefId> = param .bounds .iter() .filter_map(|bound| bound.trait_def_id()) .collect(); if !candidates.iter().any(|t| trait_def_ids.contains(&t.def_id)) { err.span_suggestions( sp, &message(format!( "restrict type parameter `{}` with", </ins> param.name.ident(), <del> if impl_trait { " +" } else { ":" }, self.tcx.def_path_str(t.def_id), if has_bounds.is_some() { " + " } else { "" }, ) }), Applicability::MaybeIncorrect, ); </del> <ins> )), candidates.iter().map(|t| { format!( "{}{} {}{}", param.name.ident(), if impl_trait { " +" } else { ":" }, self.tcx.def_path_str(t.def_id), if has_bounds.is_some() { " + " } else { "" }, ) }), Applicability::MaybeIncorrect, ); } </ins> suggested = true; } Node::Item(hir::Item {

Discussion:
Given the following test and nightly 2020-01-12: I get that this is not supposed to work without const generics, but the error message suggestion is very funny: With const generics:
Weird suggestion is on current stable as well.
The ICE component is fixed by , the diagnostics issue remains ()
I think it's another example of now.
Change:
<ins> warning: any use of this value will cause an error --> $SRC_DIR/libcore/hint.rs:LL:COL | LL |     unsafe { intrinsics::unreachable() } |              ^^^^^^^^^^^^^^^^^^^^^^^^^ |              | |              entering unreachable code |              inside `std::hint::unreachable_unchecked` at $SRC_DIR/libcore/hint.rs:LL:COL |              inside `foo` at $DIR/const_unsafe_unreachable_ub.rs:9:18 |              inside `BAR` at $DIR/const_unsafe_unreachable_ub.rs:14:28 | ::: $DIR/const_unsafe_unreachable_ub.rs:14:1 | LL | const BAR: bool = unsafe { foo(false) }; | ---------------------------------------- | note: the lint level is defined here --> $DIR/const_unsafe_unreachable_ub.rs:13:8 | LL | #[warn(const_err)] |        ^^^^^^^^^ error[E0080]: evaluation of constant expression failed --> $DIR/const_unsafe_unreachable_ub.rs:17:3 | LL |   assert_eq!(BAR, true); |   ^^^^^^^^^^^---^^^^^^^^ |              | |              referenced constant has errors | = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info) error: erroneous constant used --> $DIR/const_unsafe_unreachable_ub.rs:17:3 | LL |   assert_eq!(BAR, true); |   ^^^^^^^^^^^^^^^^^^^^^^ referenced constant has errors | = note: `#[deny(const_err)]` on by default = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to 2 previous errors; 1 warning emitted For more information about this error, try `rustc --explain E0080`. </ins>

Discussion:
Currently one cannot call in constant functions, so one cannot add hints of the form: These types of hints can heavily influence code generation, which can substantially change the performance of when they are invoked at run-time. It would be a shame to have to write and call and because the code generated for is sub-par. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
One cannot do any sort of conditional control flow, so would currently be less than useless. Any test you can write would be undefined behaviour
the RFC for / in const was merged and is pending an implementation right? When that's implemented, will still be useless?
No it makes sense after we have conditional control flow.
As I understand / in const functions is now implemented. Can be made into a now?
yes. Basically you just need to add the attribute to the intrinsic and wrapper function. This is documented at https://rustc-dev- Let me know if anything is unclear (in which case we should update the guide)
Hi, It looks like previous PR is not being worked on currently. I'm working on this and will create a PR soon. claim
As mentioned in , this issue should be reopened (to track stablization)
cc ^
After a short discussion on Zulip, it was decided that it's best to wait for to stabilize to avoid a potential footgun wherein users use this instead of , leading to UB at runtime. I'm subscribed to the issue and intend to file a PR to stabilize this once the aforementioned happens.
Change:
LL |     const B: u8 = Self::A; |     ^^^^^^^^^^^^^^^^^^^^^^ = note: ...which again requires normalizing `<() as Tr>::A`, completing the cycle <del> note: cycle used when const-evaluating `main` </del> <ins> note: cycle used when const-evaluating `main::promoted[2]` </ins> --> $DIR/defaults-cyclic-fail.rs:14:1 | LL | fn main() {

Discussion:
Evaluating of promoteds currently looks very confusing in the query stack: is not a const, so "const-evaluating " is just nonsense. I presume that this is easy to fix but only would know how. ;) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Also see
Let's give a try :wink:
claim
awesome. :) Let us know if you need any help. I am not very familiar with that specific code, but can still help with more general questions, and I hope can help with the specifics. :D
Change:
<ins> error[E0283]: type annotations needed --> $DIR/overflow-computing-ambiguity.rs:12:5 | LL |     hello(); |     ^^^^^ cannot infer type of the type parameter `T` declared on the function `hello` | = note: cannot satisfy `_: Hello` = help: the following types implement trait `Hello`: Foo<'a, &'a T> Foo<'static, i32> note: required by a bound in `hello` --> $DIR/overflow-computing-ambiguity.rs:9:22 | LL | fn hello<T: ?Sized + Hello>() {} |                      ^^^^^ required by this bound in `hello` help: consider specifying the generic argument | LL |     hello::<T>(); |          +++++ error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0283`. </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 have a full repro in , but the short version is, it seems like some cases of code that look_ like an omitted type should be inferrable: while certain dependencies, leading to , are in the compile pathway (I could only get it to reproduce via a weird dependency chain via a workspace and a couple of public crates), can lead to an overflow: If the dependency chain is altered in any way that I could divine, the expected error is output: <!-- 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. --I've reproduced this bug both in and in . :
Bisects to nightly-2023-10-07. In nightly-2023-10-06, we get "the expected error" shown above.
Looks like , because reproduces the issue, but the previous commit on master () does not.
Minimal:
I'll put up a fix in a sec
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
import.crate_lint(), ); let no_ambiguity = self.r.ambiguity_errors.len() == prev_ambiguity_errors_len; <ins> if let Some(orig_blacklisted_binding) = orig_blacklisted_binding { self.r.blacklisted_binding = orig_blacklisted_binding; } </ins> import.vis.set(orig_vis); if let PathResult::Failed { .. } | PathResult::NonModule(..) = path_res { // Consider erroneous imports used to avoid duplicate diagnostics.

Discussion:
Reproduction code: If I re-export in the module, it works as expected, having enum in the type-namespace and variant in the value-namespace ().
Compiler team check-in: I'm marking this as P-medium for now as it is not classified as a regression, although it seems like a fairly major problem. appears to be on it, though.
Feel free to add the I-nominated label if you think it should be P-high
late last year. could you take a look at this to see if it is valid for the invariant being checked not to hold in this case? If I comment out the the output is reasonable:
I'll see what happens (that's why I self-assigned). The assert is there to catch the cases that resolve logic assumes to be impossible. It may work ok if the assert is removed, but it may also mean some deeper issues, this needs a more detailed look.
The above error message without the looks a lot like and .
but it may also mean some deeper issues was exactly the case here! Thank you for reporting. Fixed in
Change:
<ins> // Fixed by #67160 trait Trait1 { type A; } trait Trait2 { type Type1<B>: Trait1<A=B>; //~^ ERROR: generic associated types are unstable //~| ERROR: type-generic associated types are not yet implemented } fn main() {} </ins>

Discussion:
This code (): results in an ICE:
Isn't that a close cousin of
Not really, this is an associated function rather than an inner function.
I'm investigating this. Still repros on . With : <details<summaryBacktrace </summary</details
After investigating, the current ICE is caused by the () inside of not being able to locate the generic parameter it is trying to substitute for. The code at fault is: Which should try and find based on the (), but the current code only handles the situation like .
No longer ICEs, I believe down to Looking at the backtrace on nightly-2019-12-05 this seems related to and also
This no longer ICEs OR errors, at least for me. What backtrace do you mean? AFAICT this can be closed.
Whoops, wrote the wrong date down. I meant the nightly when it did ICE, it was 2019-12-01 or thereabouts. Yeah it can be closed once there's a regression test
Change:
<ins> // Fixed by #67160 trait Trait1 { type A; } trait Trait2 { type Type1<B>: Trait1<A=B>; //~^ ERROR: generic associated types are unstable //~| ERROR: type-generic associated types are not yet implemented } fn main() {} </ins>

Discussion:
paniked when I tried to use GAT, I didn't know does not support it then. Anyway I think it is not supposed to panic. I have confirmed with version 1.39 on Windows, my PC version 1.36 on Linux. It said,
Seems a duplicate of , I did not noticed it when I was opening this issue, sorry. There is also a small difference that I did not turn on
cc &
This should be fixed in the next nightly

This is a toy example I made in order to later make tests which run for with . This is the error I get: Error notes: - compiler flags: I don't know if this kind of pattern is intended as part of the feature or in its future, but if not, I think it can be satisfied by using a procedural macro so that's probably alright. The point of the pattern, as I mentioned at the beginning of the post, is to be able to test a particular generic type's implementation up to an arbitrary range of numeric constants. While implementing another project to help test the feature, I stumbled upon the problem of wanting to test hundreds of different constants, but having no way of doing so with say, a loop over a range of constants. This is one way I thought of making it work. Am I making the right decisions here? How should I go about testing hundreds of constants? Thanks :)
Note: another example that also panics. I know, yes, expressions aren't yet supported as const parameters. But it has the same panic, which is WEIRD! When I wrote this one, I thought "okay maybe inside a statement, the compiler won't try things like because the case when is is already covered... and with exhaustiveness check it should know that N = 0 won't enter the second branch". But I must be wrong there, or otherwise how did it panic? Error:
Minified: I'm pretty sure that I saw this ICE before, but I can't find it ;/
This is just a result of having an expression () as a const generic argument. I don't actually think there's a canonical issue, though many of the issues are essentially the same. is the best tracking issue.
No longer ICEs on the latest nightly
Oh, the new output is interesting. It probably needs to be monomorphized so that the compiler detects the infinite recursion. And then we could also write one that doesn't have infinite recursion :3 In order to force an error, a test function should suffice right?
What do you mean?
I mean that I imagined it might detect that the function recurses infinitely onto itself. But I guess it reads it lazily, and lets monomorphization do the job of recursing the function? which would make a lot of sense to me.
Change:
warnings: &mut warnings, suggest_unsafe_block: true, }; <ins> // params in THIR may be unsafe, e.g. a union pattern. for param in &thir.params { if let Some(param_pat) = param.pat.as_deref() { visitor.visit_pat(param_pat); } } // Visit the body. </ins> visitor.visit_expr(&thir[expr]); warnings.sort_by_key(|w| w.block_span);

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: rustc rejecting this code. We are transmuting arbitrary types without unsafe, this is clearly unsound. Instead, this happened: rustc accepted this code, and it SIGSEGVs at runtime. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Seems to have regressed between 1.76 and 1.77. In 1.76 (and below) it gave: It's probably related to the THIR unsafeck which in .
I'll take a look at this. I think I may have found out what's going on. claim
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Reopening for beta nomination.
Fix backported via