jiebi/CodeConvo huggingface dataset:
Change:
<ins> // check-pass // compile-flags: -Zsave-analysis trait Trait { type Assoc; } fn main() { struct Data<T: Trait> { x: T::Assoc, } } </ins>

Discussion:
I wasn't sure if it was right to report this here or elsewhere, so here it is for now... Trying to compile with works, but running the from the same toolchain results in the following:
looks like
cc
triage: P-high. Removing nomination label.
Easy way to reproduce. empty project to dependencies RLS Errors: And
although supposedly this has been fixed a couple of days ago, latest nightly rls still crashes on petgraph:
Chances are this has been fixed with Could you please update to the newest nightly now and see if you can reproduce this?
yes this is fixed now, thanks!

RLS cannot build my project, which uses gstreamer. Compiling it normally with rustc works fine. Affected project for reference: I launched RLS manually with
Probably unearthed by
cc
Recompiled everything with , same issue.
works fine.
I’m sure it’s what - it’s an unearthed bug when you pass -Zsave-analysis, hence why it crashes only when using RLS.
I have the same error when using rust nightly and directly or indirectly referencing the crate. The project builds fine but crashes. Steps to reproduce: Create a new project Add to the Run Downgrading to and makes the error go away.
pre-triage: not sure what priority to assign to this. Probably P-high but I want to discuss with team. Leaving I-nominated unprioritized for now.
triage: P-high. Cc (can you take point on this?)
Yup, assigning to myself, shouldn’t be hard to fix
What assistance from others, if any, could help you resolve this issue?
Minimal reproducer (based on petgraph ICE):
Is anyone else available you can offload this bug to?
visiting for triage. Assigning to self to remember to look into this later
So I have a fix that does not ICE but doesn't seem to actually 'fix' the behaviour. The problem is that we can't nest typeck tables for because it doesn't have one because it doesn't have a body; however we hit the assertion when trying to resolve member type when resolving a qualified path using because the DefId paths don't properly match. The fix that I have is not to try to nest when a given NodeId doesn't have associated typecktables but instead use an empty table approach (e.g. used in privacy code). This means we don't hit the assertion but IIUC we can't properly resolve a qualified path this way. I think long-term the solution would be to traverse HIR directly rather than doing so using AST (that's another case where we have a mismatch of nested DefIds for which we can't get typeck tables to properly resolve a ). I'll submit the PR with the fix later today.
Change:
<ins> // edition:2018 trait Test<T> { fn is_some(self: T); //~ ERROR invalid `self` parameter type } async fn f() { let x = Some(2); if x.is_some() { println!("Some"); } } fn main() {} </ins>

Discussion:
produces an expected error: , the original error is replaced with this: : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Nominating because: The trait impl does not exist, the compiler hallucinated it into existence Inherent methods are supposed to take precedence over trait methods This might indicate a quite serious bug in the compiler.
I would suggest stable- and beta-nominating the fix for this PR; it seems like this could warrant a point release. cc
modify labels: beta-nominated stable-nominated
Phew; looks like precedence works correctly in non-error code at least: Crisis averted? :)
assign
unnominating for back ports; we don't backport nominate issues, just Pull Requests.
claim I'll take a look, since is finding this to be mighty tricky to track down
I managed to get similar symptoms without async but with . But this time the trait compiles.
I am 99% sure that also applies here.
The async case is fixed by , I think we should break out the arbitrary self types case into a distinct bug.
Change:
); } <del> fn describe_lints(sess: &Session, lint_store: &LintStore, loaded_plugins: bool) { </del> <ins> /// Write to stdout lint command options, together with a list of all available lints pub fn describe_lints(sess: &Session, lint_store: &LintStore, loaded_plugins: bool) { </ins> println!( " Available lint options:

Discussion:
I tried this code: I expected to see this happen: Rustdoc prints a list of all lints, the same way rustc does. Instead, this happened: Rustdoc ignored the flag. <!-- 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. --: rustdoc 1.53.0-nightly ( 2021-04-03) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
option is parsed into , but is then ignored: It should be pretty straightforward to instead call when this flag is set. claim
Make sure you call init_lints first, or it will be missing rustdoc's own lints.
Re adding a test for this... is there any way to have check only for whether some substring appears within stderr? Else every time a lint is /removed, or its level modified, the test will need updating—which seems far too brittle to me?
I mean, personally that seems ok to me as long as you can update it with . But if you think it's a hassle you could use .
Change:
let raw_shift_bits = self.read_scalar(args[1])?.to_bits(layout.size)?; let width_bits = layout.size.bits() as u128; let shift_bits = raw_shift_bits % width_bits; <del> let inv_shift_bits = (width_bits - raw_shift_bits) % width_bits; </del> <ins> let inv_shift_bits = (width_bits - shift_bits) % width_bits; </ins> let result_bits = if intrinsic_name == "rotate_left" { (val_bits << shift_bits) | (val_bits >> inv_shift_bits) } else {

Discussion:
The following code ICEs when compiled with a rustc with debug-assertions enabled: The problem is in the implementation of , specifically in this line: The subtraction overflows here. Cc
Fix should be:
Ya I'll take this on :+1:
awesome! above already pretty much gave the mentoring instructions, except for one thing: please also add a test case. Or rather, please extend the existing test case at . Let me know if you need any more assistance.
looks like you are both on this now? Not sure how that happened...
Change:
// Only consider direct calls to functions let terminator = bb_data.terminator(); if let TerminatorKind::Call { <del> func: Operand::Constant(ref f), .. } = terminator.kind { if let ty::FnDef(callee_def_id, substs) = f.ty.sty { </del> <ins> func: ref op, .. } = terminator.kind { if let ty::FnDef(callee_def_id, substs) = op.ty(caller_mir, self.tcx).sty { </ins> if let Some(instance) = Instance::resolve(self.tcx, param_env, callee_def_id,

Discussion:
This code: should not pattern-match on , but rather call its method to get its type. What this means is that should inline as well as (but today it doesn't). cc
Actually it should handle both cases, I think. Handling the constant is useful when the type has been erased but constant propagation managed to propagate the actual function anyway.
It's type-based today, but it only handles the case. While handling function pointer types based on the value would be interesting, it's not done today.
Working on this one :)
Change:
pub fn sequence_element_type(cx: &ctxt, ty: t) -> t { match get(ty).sty { <del> ty_vec(mt, Some(_)) => mt.ty, </del> <ins> ty_vec(mt, _) => mt.ty, </ins> ty_ptr(mt{ty: t, ..}) | ty_rptr(_, mt{ty: t, ..}) | ty_box(t) | ty_uniq(t) => match get(t).sty { ty_vec(mt, None) => mt.ty,

Discussion:
fails to compile: cc
What does the l-wrong label mean here?
It means that the current behavior of the compiler is incorrect.
Change:
use crate::deref_separator::deref_finder; use rustc_attr::InlineAttr; use rustc_const_eval::transform::validate::validate_types; <ins> use rustc_hir::def::DefKind; </ins> use rustc_hir::def_id::DefId; use rustc_index::bit_set::BitSet; use rustc_index::Idx;

Discussion:
<!-- [31mICE[0m: Rustc '-Zmir-opt-level=0 -Zpolymorphize=on -Zinline-mir=yes -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'index out of bounds: the len is 6 but the index is 6'', 'thread 'rustc' panicked at 'index out of bounds: the len is 6 but the index is 6'' 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<!-- query stack: [optimizedmir] optimizing MIR for [unusedgenericparams] determining which generic parameters are unused by [analysis] running analysis passes on this crate --
cc
Change:
Box::new(Result { ident: res, <del> span: sp, </del> <ins> span: sp.with_ctxt(sp.ctxt().apply_mark(cx.current_expansion.mark)), </ins> }) }

Discussion:
If any linting or suggestion is done in this case, it should suggest cc this has been in rustc forever, but clippy is only lately going crazy on it. Could this have come from your PR, too?
Hmm, shouldn't have been affected, but I'll investigate.
this is messing up clippy pretty bad. Any idea where to start looking?
So I tried to figure out what's going on, but I got lost in the code. As far as I can see it should be setting the expansion info. But it appears the passed to doesn't contain the expansion info. So maybe we need to generate a new span here with the from ?
The span passed to is the call site span, so it shouldn't contain the expansion info. The issue here is that is using the call site span directly in the expansion ( is call site span). To fix this, the macro should add expansion info to the call site span like does . Adding that line in should fix this issue. Are there other built-in macros that also have this problem in practice or is it just ?
I'd assume others have it too, but I'll check. So the passed call site span should only be used directly for error reporting, but never for creating ast items?
Right, unless you want an AST item with the raw (unexpanded) call site span -- I don't think we ever want that.
Change:
<ins> // This previously triggered an ICE. pub(in crate::r#mod) fn main() {} //~^ ERROR expected module, found unresolved item </ins>

Discussion:
Rust version affected Both stable and nightly: How to reproduce Run on this code: Stacktrace Potentially related issue: , although here it happens only with not
Can confirm on .
MCVE: Bisected to find regression is in nightly , from: to the above ICE. As far as I can tell only rustdoc triggers it, but I don't know enough to say that for certain.
Cannot reproduce the ICE with the above MCVE on latest nightly ()
After too much time bisecting, it has worked since , more specifically commit which is this rollup: . My guess is that this is another bug fixed by .
I can confirm that probably fixed this. I've submitted the MCVE as a regression test:
Change:
use crate::fmt; use crate::hash::{self, Hash}; use crate::iter::TrustedLen; <del> use crate::marker::Unsize; </del> use crate::mem::{self, MaybeUninit}; use crate::ops::{Index, IndexMut}; use crate::slice::{Iter, IterMut};

Discussion:
This is a tracking issue for the unstable feature in the standard library. This is likely to be deprecated and removed in favor of generic integers one day, and in the meantime there are not many consumers of it.
Note that the feature specifically covers the trait. There's some other code in core::array, but it's all implicitly stable.
The FixedSizeArray trait would be great, except for many uses the ranges of sizes it's implemented for simply isn't what you need, and there is no way to expand it. Thus it is mostly useless in the current form.
Could the compiler magically have an "infinite" (generated on demand) number of impls of ? If that happens and the type parameter is made into an associated type (and maybe an associated const for the size is ), then most of the other impls that currently only go up to N=32 could be made generic .
If/when the issue of using associated consts like consts is resolved, that is, allow to compile; then an infinite number of FixedSizeArray impls would give us the same thing as generic integer parameters. This suggests to me that completing associated constants is basically the same problem as allowing generic integer parameters.
for now could be moved to a crate since it doesn't use any compiler magic anyway
has a similar trait, called :
Triage: no changes
Something did change in this trait is now implemented for all sizes: The trait is also unstable:
I wrote about extending and stabilizing this trait.
This trait isn't used anywhere and doesn't seem to be needed any more now that we have const generics. fcp close
Team member has proposed to close 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 close, 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.
Change:
// cannot be longer than `isize::MAX`. They also guarantee that // `self` is in bounds of `slice` so `self` cannot overflow an `isize`, // so the call to `add` is safe. <del> unsafe { slice.as_ptr().add(self) } </del> <ins> unsafe { crate::intrinsics::assume(self < slice.len()); slice.as_ptr().add(self) } </ins> } #[inline]

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: Compile with on () I expected to see this happen: Both functions should compile to approximately the same thing, with no bounds check on the since the optimizer should be able to see that the slice is at least of length 2 due to the previous unchecked indexing. Instead, this happened: contains a bounds check (only does not contain a bounds check). rustc stable (1.73.0), nightly (2023-10-17), and 1.58.0 (when was stabilized) all have approximately the same codegen. : (no backtrace) label +C-optimization -C-bug
contains an assume intrinsic, doesn't. Might be worth adding it to the latter and see how that impacts perf, it's not guaranteed that it would actually improve things since we'd be emitting more IR and llvm would have to work harder. Commonly it's the case that if one uses one does so for all accesses on the slice, so this seems like an unusual pattern.
Change:
///     .create(true) /// ///     // Sets the flag value to `SecurityIdentification`. <del> ///     .security_qos_flags(1) </del> <ins> ///     .security_qos_flags(winapi::SECURITY_IDENTIFICATION) </ins> /// <del> ///     .open("foo.txt"); </del> <ins> ///     .open(r".pipeMyPipe"); </ins> /// ``` /// /// [`CreateFile`]: https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858.aspx

Discussion:
By default, opening a named pipe on Windows allows the server to impersonate the client. This is a security vulnerability. Pass to prevent this. Since it fixes a security hole, I don’t think this needs an RFC.
Where do we use named pipes?
Nowhere, but it is possible to open a named pipe as a file.
Could you be more clear? What exactly needs to change inside Rust? I assume we'd have to add some form of detection around file opening in windows..?
Whenever libstd calls CreateFileW(), it needs to pass these flags to avoid a local privilege escalation exploit.
can you tell anything about what potential issue you hit when trying to work on this in Or do you have WIP code of the test you where working on?
A simple explanation of the security problem: What could be a problem with setting these flags always: the flag is the same as . The first is supposed to be used with named pipes, the other for files and directories. So if we start to unconditionally add , it will in reality set the in almost all cases. Now I've never seen a system with 'hierarchical storage' where would be necessary. It is intended for systems that combine fast store like hard drives, with slow bulk storage like tapes. File operations like indexing, searching, or backup that want to work well on such systems should open files that have the attribute with this flag. Otherwise a lot of data from tape may be put back online on hard drives. See at The Old New Thing. While investigation this, I found another issue with : one of the values it takes is , whis is simply . Currently, when you set , it will silently be ignored unless you also happen to set (which our API is supposed to set automatically). Easy to fix though. Now I don't care much for working well with hierarchical storage. But we should not break it without having some sort of workaround available. We can say that if user code contains it should be able to handle Windows-specific oddities such as this one. We could make it so that even is enough to disable automatic sqos flags. But it doesn't feel great to just drop a security measure when the user could be doing something unrelated, such as the buffering hint . Only set when we know what we are trying to open is a named pipe.

I think all named pipes start with , and we know the filename when setting the flags. But I am not sure if this really works, or if it is possible for an unprivileged process to create a symbolic link to one in the object manager. I don't know if I'll get to making a PR and doing the required testing, just writing down what I've found so far.
Change:
/// `//[foo]`), then the property is ignored unless `cfg` is /// `Some("foo")`. fn load_from(&mut self, testfile: &Path, cfg: Option<&str>, config: &Config) { <del> // Mode-dependent defaults. self.remap_src_base = config.mode == Mode::Ui && !config.suite.contains("rustdoc"); </del> <ins> // In CI, we've sometimes encountered non-determinism related to truncating very long paths. // Set a consistent (short) prefix to avoid issues, but only in CI to avoid regressing the // contributor experience. if CiEnv::is_ci() { self.remap_src_base = config.mode == Mode::Ui && !config.suite.contains("rustdoc"); } </ins> let mut has_edition = false; if !testfile.is_dir() {

Discussion:
it seems like the source directory in the printout for ui tests uses "fake-test-src-base" rn, e.g. this prevents ctrl+leftclick in vscode to take me directly to the relevant point in the source of the failing test. it would be nice to somehowo keep the actual path in the output for ui tests and only normalize it when writing into the stderr file? see https://rust- for more details
Note that we already print the real path in the "--- [ui] ... stdout ---" line at the top, but it would be nice to have this in addition so that line/column jumping works too.
One possible workaround is to only pass remap-path-prefix in CI. I think it may also be possible to solve the problem on with a different mechanism entirely by stripping out the the directory with test normalization for UI tests involving closures? https://rustc-dev-
I think there are two reasons why this may be a suboptimal solution: 1) You'd still have to deal with the showing up depending on the path length. 2) The difference between and is that the version indicates that has printed a full path, whereas for the non- version only a filename was printed. It may be useful / desirable to be able to distinguish the two cases in the output files.
makes sense - in that case the simplest fix is to gate remap-path-prefix on
Change:
<del> //@ run-pass //@ ignore-sgx not supported #![allow(deprecated)] use std::thread; fn main() { thread::sleep_ms(250); } </del>

Discussion:
Perhaps I'm holding it wrong? About a fifth of the rustc UI test suite to fail on wasm32-unknown-emscripten when trying to run . In all cases we get an error like this:
Does this target use some different main symbol name?
... do we need to pass --no-entry to lib builds? can you check if (some of) the failing tests are lib crates? Actually what am I doing, I can check
I can't get past the building test helpers for this target cross-compiling from msvc host, not sure what's up with that.
Huh. cc Can you make it any further?
Because there's an open PR for this.
In the open platform support docs PR this says It's recommended to test the  target instead for WebAssembly compatibility. ... so I don't know, is this expected failure?
See I was able to get past the build helpers stage by properly acquring the toolchain and making relevant env vars available to bootstrap. Didn't bother trying to diagnose past stage 1 std and tests because there's like a chain of failures. Notably I see
The failing link command includes: if we replace that with , then it links as expected. But then it fails to run it at: We should invoke with node.
So I guess for starters we should do:
Combined with setting the runner to this fixes most of the failing tests:
The failures seem to be: and seems like it hangs? sounds like an xfail.
Change:
<del> error[E0284]: type annotations needed: cannot satisfy `the constant `foo::{opaque#0}::{constant#0}` can be evaluated` </del> <ins> error[E0284]: type annotations needed </ins> --> $DIR/parent_generics_of_encoding_impl_trait.rs:9:5 | LL |     generics_of_parent_impl_trait::foo([()]); <del> |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot satisfy `the constant `foo::{opaque#0}::{constant#0}` can be evaluated` </del> <ins> |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot infer the value of const parameter `N` declared on the function `foo` </ins> | note: required by a bound in `foo` --> $DIR/auxiliary/generics_of_parent_impl_trait.rs:6:48

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. --Based on the example in , which after the changes in would output an error. The following code, however, does not output such an error, although I believe it should. Given the following code: <!-- Please provide a link to --The current output is: This only happens if the is included. This also compiles if you don't include the call of in main. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
dont think this is related to adtconstparams as this has the same error:
the reason this happens is because from we don't infer the value for . The error message should be improved by using in this branch for that the predicates should be searched for a relevant inference variable.
going to mentor this issue in case someone wants to fix this
claim