jiebi/CodeConvo huggingface dataset:
Change:
let has_lifetime = self.token.is_lifetime() && self.look_ahead(1, |t| t != &token::Colon); let lifetime = has_lifetime.then(|| self.expect_lifetime()); // For recovery, see below. let (borrow_kind, mutbl) = self.parse_borrow_modifiers(lo); <del> let expr = self.parse_prefix_expr(None); </del> <ins> let expr = if self.token.is_range_separator() { self.parse_prefix_range_expr(None) } else { self.parse_prefix_expr(None) }; </ins> let (hi, expr) = self.interpolated_or_expr_span(expr)?; let span = lo.to(hi); if let Some(lt) = lifetime {

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: is a valid expression (a  literal), so this error is misleading. It should at a minimum have a suggestion to replace with the valid version , and probably should just work. It also imho ideally shouldn't be a hard parser error blocking semantic passes; the parse of is fairly unambiguously intended, even if we decide we should still require the parenthesis. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'm interested! Where should I look first? (I have no experience in rustc, some general experience in compilers tho)
The is a good place to start. If you have some compiler development experience already, that should get you going quickly enough. One specifically relevant section is is likely to be where you'll need to change. Also, ; you can to assign yourself to the issue to track that you're working on it.
For extra context, is accepted in expression position at least for both , , and obviously , so I have absolutely no idea what makes different that it causes a parser error in this case.
claim
Change:
padding: 0 20px 20px 17px;; } <ins> .item-info .stab { display: table; } </ins> .stab { border-width: 1px; border-style: solid;

Discussion:
I'm not sure if this change is intentional or not, but I thought it's worth reporting in case it's a bug. ! !
cc Was this change intentional?
I don't think so!
We found it out with and we weren't sure whether it was good or not (from a "look" point of view) and simply decided to wait and see if people liked it or not. So, should we revert it or not? :)
As a random person on the internet, I prefer the old look better. Although I admit that's at least partially due to familiarity with it.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
I would revert it
I'll change the look then.
I think I might like the new look better, but it's a slight preference and I seem to be outvoted. :)
I don't think we should be changing the UI by accident. I'm open to a discussion in changing it, but it shouldn't have changed without a discussion, so we should change it back in the meantime.
Agreed. I'll send a fix in the next two days.
Change:
// wait for the child task to exit before we exit p1.recv(); }) <ins> test!(fn sends_off_the_runtime() { use rt::thread::Thread; let (p, c) = Chan::new(); let t = Thread::start(proc() { for _ in range(0, 1000) { c.send(()); } }); for _ in range(0, 1000) { p.recv(); } t.join(); }) test!(fn try_recvs_off_the_runtime() { use rt::thread::Thread; let (p, c) = Chan::new(); let (pdone, cdone) = Chan::new(); let t = Thread::start(proc() { let mut hits = 0; while hits < 10 { match p.try_recv() { Data(()) => { hits += 1; } Empty => { Thread::yield_now(); } Disconnected => return, } } cdone.send(()); }); for _ in range(0, 10) { c.send(()); } t.join(); pdone.recv(); }) </ins> }

Discussion:
Reporting this here after asking in IRC something like this: where c_callback is called from a thread created by the c library crashes the application after a while with: previously SharedChan seemed to work without problem
cc It looks like the new can no longer be used outside a runtime?
Whoops, testing a fix now (sorry about that!)
thanks!
sorry to post on a closed issue, but i'm finding the same problem now in SyncChan/SyncPort not sure if it's a real bug or in this case it's supposed to work like that?
You won't be able to use those off the runtime because a send involves then receiving which blocks the task. You're only able to block if you have a local rust task available.
that's what i was suspecting, thanks!
Change:
/// ``` #[stable(feature = "rust1", since = "1.0.0")] pub fn insert(&mut self, index: usize, element: T) { <ins> #[cold] #[inline(never)] fn assert_failed(index: usize, len: usize) -> ! { panic!("insertion index (is {}) should be <= len (is {})", index, len); } </ins> let len = self.len(); <del> assert!(index <= len); </del> <ins> if !(index <= len) { assert_failed(index, len); } </ins> // space for the new element if len == self.buf.capacity() {

Discussion:
I've spotted, that panic message could've provided details on what values led to this panic, instead of mentioning condition only. Generally speaking this and some other s in Vec could've been more detailed. If it's okay to step in, I'd like to offer my help. In case of I'd suggest calling this instead I find this more informative than Candidates for improval: aforementioned : : : :
Does triaging mean a green light for this suggestion?
No, I just apply the relevant labels. :)
Though this is a small change with little time required to fix, so I'd just make the PR if I were you. :)
Note: uses the same kind of assertion in (as the old check had aliasing issues). Depending on which PR lands first, we should make sure it gets the same panic message as the others.
I think it makes sense to follow the message, that is being currently printed, when trying to access element out of bounds via . Current message template is . I followed this idiom to keep it consistent.
Change:
/// /// The stabilized version of this intrinsic is /// [`std::hint::unreachable_unchecked`](../../std/hint/fn.unreachable_unchecked.html). <ins> #[rustc_const_unstable(feature = "const_unreachable_unchecked", issue = "53188")] </ins> pub fn unreachable() -> !; /// Informs the optimizer that a condition is always true.

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:
/// `Region` and `Const` are all interned. #[derive(Copy, Clone, PartialEq, Eq, Hash)] pub struct GenericArg<'tcx> { <del> ptr: NonZeroUsize, </del> <ins> ptr: NonNull<()>, </ins> marker: PhantomData<(Ty<'tcx>, ty::Region<'tcx>, ty::Const<'tcx>)>, } <ins> #[cfg(parallel_compiler)] unsafe impl<'tcx> rustc_data_structures::sync::DynSend for GenericArg<'tcx> where &'tcx (Ty<'tcx>, ty::Region<'tcx>, ty::Const<'tcx>): rustc_data_structures::sync::DynSend { } #[cfg(parallel_compiler)] unsafe impl<'tcx> rustc_data_structures::sync::DynSync for GenericArg<'tcx> where &'tcx (Ty<'tcx>, ty::Region<'tcx>, ty::Const<'tcx>): rustc_data_structures::sync::DynSync { } unsafe impl<'tcx> Send for GenericArg<'tcx> where &'tcx (Ty<'tcx>, ty::Region<'tcx>, ty::Const<'tcx>): Send { } unsafe impl<'tcx> Sync for GenericArg<'tcx> where &'tcx (Ty<'tcx>, ty::Region<'tcx>, ty::Const<'tcx>): Sync { } </ins> impl<'tcx> IntoDiagnosticArg for GenericArg<'tcx> { fn into_diagnostic_arg(self) -> DiagnosticArgValue<'static> { self.to_string().into_diagnostic_arg()

Discussion:
and currently store pointers as , which is not ideal: They should really work with pointers and strict provenance APIs like , , etc. See a PR fixing a similar issue for some context: (note: in that one I ended up rewriting the whole thing, I think this issue requires far less changes). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
(I do plan to work on this, but if you want to work on this instead — feel free to , I can mentor you) <subcc
claim
Could you briefly describe and , also a comprehensive insight about this issue would greatly help, although I had a look at which currently is an . If I understand correctly, we are building a for this and aim to improve existing implementations as seen in languages like C++ by making it more strict, and there is some discussion that can basically do most of what C++ can and this addition might have some diverging path. Let me know, so I can move forward!
claim
Hi strict provenance means that we aren't doing pointer-int conversions and only operate through pointer types like suggested by OP. and currently use which doesn't work under strict provenance. If you'd like I can work on this issue.
Did you mean to mentor me for the same? I would be happy to learn!
is already working on this issue, is this right? Let's not override other people working on it already unless they agree or it's been several weeks with no response.
Hi yes I am working on this issue. This is my first time contributing so it will take me sometime. I will reassign the issue to me.
claim
Hi Just checking in :) Are you still working on this issue?
Yup I am still working on this issue :)
Let us know on Zulip if you need any help
with this resolved, I think rustc is free from "fuzzy provenance casts" :)
Awesome :-)
Change:
<ins> #[macro_export] macro_rules! attrs_on_struct { ( $( #[$attr:meta] )* ) => { $( #[$attr] )* pub struct ExpandedStruct; } } </ins>

Discussion:
Doctest test names have changed due to . Doc comments that pass through a macro defined in another crate now seem to report a different span. /// assert!(true); /// running with previously looked like this: Now the test names look like this: Frankly, neither are particularly great. It would be nice if the test name used the span from where the macro was invoked, not where it was defined.
I think this also affects normal backtraces :( Just got this rather unuseful backtrace while bootstrapping: full:
cc
What you're describing is entirely in the opposite direction, is the old (and arguably bad) kind of that's impossible to get anymore. I've hidden your comment to focus on the reported issue.
That makes sense, we have a way to get the outermost invocation, that is used by / and : We'd just need to use this in .
cc
cc
Removed label, left nomination for to decide about this issue.
Well, using what suggested seems like the best thing to do.
Change:
_ => "`self` value is a keyword only available in methods with a `self` parameter" .to_string(), }); <del> if let Some(span) = &self.diagnostic_metadata.current_function { err.span_label(*span, "this function doesn't have a `self` parameter"); </del> <ins> if let Some((fn_kind, span)) = &self.diagnostic_metadata.current_function { // The current function has a `self' parameter, but we were unable to resolve // a reference to `self`. This can only happen if the `self` identifier we // are resolving came from a different hygiene context. if fn_kind.decl().inputs.get(0).map(|p| p.is_self()).unwrap_or(false) { err.span_label(*span, "this function has a `self` parameter, but a macro invocation can only access identifiers it receives from parameters"); } else { err.span_label(*span, "this function doesn't have a `self` parameter"); } </ins> } return (err, Vec::new()); }

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:
pub const LOG2_E: f32 = 1.44269504088896340735992468100189214_f32; /// log<sub>2</sub>(10) <del> #[unstable(feature = "extra_log_consts", issue = "50540")] </del> <ins> #[stable(feature = "extra_log_consts", since = "1.43.0")] </ins> pub const LOG2_10: f32 = 3.32192809488736234787031942948939018_f32; /// log<sub>10</sub>(e)

Discussion:
Specifically, and . PR:
Has anyone used these constants at all and want to pitch in for stabilisation of these? These have landed for a while and I'm curious how many people are using them.
+1 for stabilization. (Tried to see if log<sub2</sub(10) exists and found that it is unstable .)
(Mind providing the specific use case? Curious to see if people are using this for anything other than scientific computing.)
to estimate the "&minus;log<sub2</sub(probability)" of collision of two values chosen randomly from a set, which will be used to derive the probability of collision of N values (≈ 1 &minus; e<sup-pN<sup2</sup/2</sup, p &ll; 1, N &gg; 1). log<sub2</subis chosen instead of natural log because the set size is often 2<supn</sup(e.g. u32), but sometimes it is drawn from a set of n decimal digits which would then involve n·log<sub2</sub(10).
One ) is = shannons (bits). Currently the constant is duplicated in .
I can't @ anyone from the libs team but do you think we'd be able to start an FCP for this?
cc .
fcp merge I believe the stabilization includes .
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! 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.
Does this need a stabilization report/PR?
It needs a PR.

Not sure if we should include in that though; would you be willing to open a separate tracking issue for that, considering how that wasn't included in the FCP for this one?
There is already .
Oh, my bad. I for some reason noticed that this issue got linked in the PR and thought that there wasn't a separate tracking issue.
Change:
executables: true, panic_strategy: PanicStrategy::Abort, relocation_model: "static".to_string(), <ins> code_model: Some("medium".to_string()), </ins> emit_debug_gdb_scripts: false, abi_blacklist: super::riscv_base::abi_blacklist(), eliminate_frame_pointer: false,

Discussion:
(which is equivalent to GCC's mcmodel=medany). I believe that this means that it is now possible to cherry pick the relevant commits and expose support from Rust. See also: rust-embedded/wg/issues/218
great ! would be useful for me as well: Kendryte K210 expects code to run from fixed address , so medlow relocations get truncated
Greetings from Oxidize! It'd be great if someone could bump LLVM, so we can start adding support for Linux/RV64 targets. It was suggested might be the person to ping about this. Is there a specific LLVM version you would recommend? I assume we want at least , but I imagine there may be other upstream fixes that are needed. Thanks! CCing
Rust can already target bare metal Rv64 (with the riscv64imac-unknown-none-elf target). What is missing is the ability to place the code/symbols at locations outside the range [-2GB, 2GB]. That isn't too much of an issue for writing supervisor mode code which can just configure the MMU to map those addresses to point to RAM, but machine mode can't pick the memory layout of the board it runs on. You actually can get away with having code outside this range as long as there aren't any indirect jumps or static variables there. It is very restrictive and inconvenient, but you might be able to get away with it for a small amount of code.
I also really want these patches to be merged. I've already tried to merge upstream branch as well as to deduce a cherry-pick-able set of commits but failed in both cases. Because of that, I can't tell whether these patches will fix the issue or not. At the moment I'm stuck waiting for help. I'm ready to give it another try, but I need some guidance. Maybe or could help me?
There's instructions/rationale about updating LLVM hosted at https://rust- Instructions are slightly out of date but I'll send a PR to fix them.
(Current status) This patch arrived in LLVM: Now LLVM is able to generate pc-relative address load instructions for global variables and functions.
Change:
) -> &'tcx List<ty::PolyExistentialPredicate<'tcx>> { let predicates: Vec<ty::PolyExistentialPredicate<'tcx>> = predicates .iter() <del> .map(|predicate| match predicate.skip_binder() { </del> <ins> .filter_map(|predicate| match predicate.skip_binder() { </ins> ty::ExistentialPredicate::Trait(trait_ref) => { let trait_ref = ty::TraitRef::identity(tcx, trait_ref.def_id); <del> ty::Binder::dummy(ty::ExistentialPredicate::Trait( </del> <ins> Some(ty::Binder::dummy(ty::ExistentialPredicate::Trait( </ins> ty::ExistentialTraitRef::erase_self_ty(tcx, trait_ref), <del> )) </del> <ins> ))) </ins> } <del> _ => predicate, </del> <ins> ty::ExistentialPredicate::Projection(..) => None, ty::ExistentialPredicate::AutoTrait(..) => Some(predicate), </ins> }) .collect(); tcx.mk_poly_existential_predicates(&predicates)

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 --
claim
Change:
<ins> // run-pass // aux-build:const_generic_lib.rs extern crate const_generic_lib; struct Container(const_generic_lib::Alias); fn main() { let res = const_generic_lib::function(const_generic_lib::Struct([14u8, 1u8, 2u8])); assert_eq!(res, 14u8); let _ = Container(const_generic_lib::Struct([0u8, 1u8])); } </ins>

Discussion:
In a folder , I have a blank library crate with the following : In a folder , I have a blank binary crate with the follow : 's uses crate with the following line: Running or in will produce the following ICE:
triage: P-high. Assigning to self for initial investigation. Removing I-nominated label. assigning as well, as someone who will likely resolve this faster than it will take me to build
Oh, given that this is using const generics (an unstable feature), it probably should be P-medium rather than P-high. I won't change the label yet, but if triage on thursday rolls around and I haven't seen a good reason to keep it P-high, I'll change the label then.
If downstream crates could ICE because they're using a type alias with const generics, even if they don't enable themselves, it seems like slightly more of an issue. (Sorry, I don't have time to look into this issue at the moment.)
It's not just type aliases, but also other constellations of cross-crate usage that are giving this ICE:
I continue to have the impression that if you use stable Rust, it will be used on all of your crates, and therefore you won't hit this bug. (don't get me wrong; I've commented elsewhere, rust-call bug in particular, where I do worry about impact on downstream crates from upstream crates using certain features that have bugs) But I still think this only warrants P-medium. Reclassifying as such.
Encountered this issue and documented it . The associated code is .
I just hit this issue as well in my project. Unfortunately I cannot share the code I'm hitting this with. A repro would look very similar to est31's example , but in my case the affected type isn't even exposed to the bin application. It's only. <details<summaryClick for stack</summary<p</p</details
Also when the type is wrapped privately (i.e., ) and exported like that, it seems to be triggered.
Change:
<ins> // run-pass // aux-build:const_generic_lib.rs extern crate const_generic_lib; struct Container(const_generic_lib::Alias); fn main() { let res = const_generic_lib::function(const_generic_lib::Struct([14u8, 1u8, 2u8])); assert_eq!(res, 14u8); let _ = Container(const_generic_lib::Struct([0u8, 1u8])); } </ins>

Discussion:
Hey everybody :) I was trying to test matrix*vector in aljabar crate by running "cargo test" on: and got this: Not sure if it's a known issue or not but if there's anything else you need from me please let me know :)
version:
verbose trace:
It would help if you can reduce the problem to a minimal reproducer without the crate. (Also note that ICEs are common for .)
Not sure if i can manage that. Could be over my head.
there is a minimal example here:
Change:
hir::MatchSource::AwaitDesugar | hir::MatchSource::TryDesugar => {} } } <del> Useful(unreachable_subpatterns) => { for span in unreachable_subpatterns { </del> <ins> Useful(unreachables) => { let mut unreachables: Vec<_> = unreachables.into_iter().flatten().collect(); // Emit lints in the order in which they occur in the file. unreachables.sort_unstable(); for span in unreachables { </ins> unreachable_pattern(cx.tcx, span, id, None); } }

Discussion:
The match remains exhaustive with highlighted pattern removed, but it does not produce any warnings: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I know where the problem comes from: this bit of code tries to handle unreachable sub-or-patterns diagnostics, but it's a bit of a hack. What remains is to come up with a better solution. claim