jiebi/CodeConvo huggingface dataset:
Change:
/// The idea then is to lower the `T: 'X` constraint into multiple /// bounds -- e.g., if `'X` is the union of two free lifetimes, /// `'1` and `'2`, then we would create `T: '1` and `T: '2`. <ins> #[instrument(level = "debug", skip(self, infcx, propagated_outlives_requirements))] </ins> fn try_promote_type_test( &self, infcx: &InferCtxt<'_, 'tcx>,

Discussion:
This code compiles after although it shouldn't: () This is similar to in that we're not taking into account placeholder regions when "promoting" type-tests from the closure to its caller: label T-types regression-from-stable-to-beta C-bug A-NLL I-unsound <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I guess it would be an easy fix claim
The unsoundness exploitation in can easily be adapted for this issue, so it is in fact a soundness issue:
issue touched in today's T-compiler meeting, . Will also be discussed tomorrow during the T-types meeting.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Change:
#![feature(duration_zero)] #![feature(exact_size_is_empty)] #![feature(extern_types)] <del> #![feature(fixed_size_array)] </del> #![feature(flt2dec)] #![feature(fmt_internals)] #![feature(hashmap_internals)]

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:
} pub fn fsync(&self) -> io::Result<()> { <del> cvt_r(|| unsafe { libc::fsync(self.0.raw()) })?; Ok(()) </del> <ins> cvt_r(|| unsafe { os_fsync(self.0.raw()) })?; return Ok(()); #[cfg(any(target_os = "macos", target_os = "ios"))] unsafe fn os_fsync(fd: c_int) -> c_int { libc::fcntl(fd, libc::F_FULLFSYNC) } #[cfg(not(any(target_os = "macos", target_os = "ios")))] unsafe fn os_fsync(fd: c_int) -> c_int { libc::fsync(fd) } </ins> } pub fn datasync(&self) -> io::Result<()> {

Discussion:
As far as I know doens't sync data onto disk on macos. (Depending on kernel & file system it might not do so on linux either). Which is why does use on mac for and implies syncing data, so shouldn't it use fcntl, too?
Change:
<ins> // check-pass #![deny(named_arguments_used_positionally)] fn main() { let value: f64 = 314.15926; let digits_before_decimal = 1; let digits_after_decimal = 2; let width = digits_before_decimal + 1 + digits_after_decimal; println!( "{value:0>width$.digits_after_decimal$}", value = value, width = width, digits_after_decimal = digits_after_decimal, ); } </ins>

Discussion:
Running clippy or build on the Vaultwarden code-base using breaks. It is broken since and still works on Tried to run before running this without luck. If you need any more information, please let me know. Vaultwarden: Working: Broken since: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Looks like this is a duplicate of , , , , , and Sorry for the clutter ;)

<!-- 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. --Upon running , the compiler panics when having as a dependency. and complete without error. Probably this is related to ? <!-- 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. --: and : : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p: </p</details
Appears to be a duplicate of
Change:
var infos = [ "Prefix searches with a type followed by a colon (e.g., <code>fn:</code>) to  <del> restrict the search to a given type.", "Accepted types are: <code>fn</code>, <code>mod</code>, <code>struct</code>,  </del> <ins> restrict the search to a given item kind.", "Accepted kinds are: <code>fn</code>, <code>mod</code>, <code>struct</code>,  </ins> <code>enum</code>, <code>trait</code>, <code>type</code>, <code>macro</code>,  and <code>const</code>.", "Search functions by type signature (e.g., <code>vec -&gt; usize</code> or 

Discussion:
The rustdoc help says However, in Rust lingo, or isn't a "type". is a type. And , and certainly aren't "types". IMO this should at least be qualified to something like "item type", but I think "item kind" would be even better.
Cc
Change:
[[package]] name = "libgit2-sys" <del> version = "0.9.1" </del> <ins> version = "0.10.0" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "a30f8637eb59616ee3b8a00f6adff781ee4ddd8343a615b8238de756060cc1b3" </del> <ins> checksum = "d9ec6bca50549d34a392611dde775123086acbd994e3fff64954777ce2dc2e51" </ins> dependencies = [ "cc", "libc",

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
Change:
= note: required for `()` to implement `IntoFuture` = note: this error originates in the macro `f` (in Nightly builds, run with -Z macro-backtrace for more info) <del> error: aborting due to 3 previous errors </del> <ins> error[E0277]: `()` is not a future --> $DIR/unnecessary-await.rs:36:20 | LL |     for x in [] {}.await |                   -^^^^^ |                   || |                   |`()` is not a future |                   help: remove the `.await` | = help: the trait `Future` is not implemented for `()` = note: () must be a future or must implement `IntoFuture` to be awaited = note: required for `()` to implement `IntoFuture` error: aborting due to 4 previous errors </ins> For more information about this error, try `rustc --explain E0277`.

Discussion:
File: auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: Version information Command:
&lt;!-- Include a backtrace in the code block by setting in your environment. E.g. . --&lt;details&lt;summary&lt;strongProgram output&lt;/strong&lt;/summary&lt;p&lt;/p&lt;/details
additional ices with &lt;!-- Include a backtrace in the code block by setting in your environment. E.g. . --&lt;details&lt;summary&lt;strongProgram output&lt;/strong&lt;/summary&lt;p&lt;/p&lt;/details
&lt;!-- Include a backtrace in the code block by setting in your environment. E.g. . --&lt;details&lt;summary&lt;strongProgram output&lt;/strong&lt;/summary&lt;p&lt;/p&lt;/details
slightly more reduced
Change:
<ins> // Regression test for issue #114529 // Tests that we do not ICE during const eval for a // break-with-value in contexts where it is illegal #[allow(while_true)] fn main() { [(); { while true { break 9; //~ ERROR `break` with value from a `while` loop }; 51 }]; [(); { while let Some(v) = Some(9) { break v; //~ ERROR `break` with value from a `while` loop }; 51 }]; } </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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I can't reproduce this on the latest nightly. Can you confirm that this doesn't reproduce anymore?
This may only be triggerable with a rustc that was built with debug assertions on
Yes, hence the label :sweat_smile:
No longer needs debug assertions to crash :tada:
`
Edit: Ignore it. Wrong bisection. For some reason it was bisecting to 2023-10-04 on my machine despite the fact that the issue was reported much earlier than this date.
The issue occurs because the interpreter tries to assign the value from to a temporary MIR local of type which produces a type mismatch and results in the ICE. Such faulty MIR should not have been generated. However, the while loop, although detected as malformed during AST lowering, successfully typecks. Had it not and had been set to , the MIR would not have been generated. Therefore as far as I understand the solution is to fail typeck and set to for code like this. claim
Change:
<ins> // issue: rust-lang/rust#114463 // ICE cannot convert `ReFree ..` to a region vid #![feature(generic_const_exprs)] //~^ WARN the feature `generic_const_exprs` is incomplete and may not be safe to use and/or cause compiler crashes fn bug<'a>() { [(); (|_: &'a u8| (), 0).1]; //~^ ERROR cannot capture late-bound lifetime in constant } pub 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

<!-- [31mICE[0m: Rustc '-Zcrate-attr=feature(constrefstostatic) -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: expected wide pointer extra data (e.g. slice length or trait object vtable)', 'error: internal compiler error: expected wide pointer extra data (e.g. slice length or trait object vtable)' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion information Command: &lt;!-- Include a backtrace in the code block by setting in your environment. E.g. . --&lt;details&lt;summary&lt;strongProgram output&lt;/strong&lt;/summary&lt;p&lt;/p&lt;/details&lt;!-- query stack: [evaltoallocationraw] const-evaluating + checking [evaltoconstvalueraw] simplifying constant for the type system [analysis] running analysis passes on this crate --
cc
You can add to get this kind of stacktrace:
Change:
return DIT(ref ? unwrap<MDNode>(ref) : NULL); } <ins> extern "C" const uint32_t LLVMRustDebugMetadataVersion = DEBUG_METADATA_VERSION; extern "C" void LLVMRustAddModuleFlag(LLVMModuleRef M, const char *name, uint32_t value) { unwrap(M)->addModuleFlag(Module::Warning, name, value); } </ins> extern "C" DIBuilderRef LLVMDIBuilderCreate(LLVMModuleRef M) { return new DIBuilder(*unwrap(M)); }

Discussion:
Here's a recent session of mine Even if I continue into my own function (actually the symbol ), I'm not getting any source level debugging. Is there an extra option that I should be passing or should this be "just working"? I compiled a C executable with and I got nice debug-info without doing anything extra in lldb. cc
This is a known issue with the Servo team, fwiw.
Does clang give you usable debug symbols?
I do indeed get nice debugging with clang:
Could you dump the IR from clang and rustc for similar programs?
I'd also be interested in seeing if clang produces dSYM bundles and whether there are any observable differences between them and the ones that rustc produces. Relevant literature at .
This has the two IR outputs:
Clang: rustc: That's some strong difference there.
I spent a while tracking this down due to a red herring, but the actual issue is simple: the DWARF version is too high. As of OS X 10.9, 'dwarfdump' and 'dsymutil', the latter of which is required to aggregate DWARF info from .o files into the final executable, appear to ignore DWARF information with version 3. Rust uses LLVM's default of DWARF 4. clang defaults to DWARF 2 on OS X; in fact, the version of clang distributed with Xcode (but not the version I have installed through MacPorts? too tired to investigate this properly) seems to ignore -gdwarf-3 and above, so probably better to go with 2 than 3. Workaround: . I believe the correct way to solve this is for rustc to set the LLVM module flag "Dwarf Version", as clang does. It should also set "Debug Info Version", which, as far as I can tell, causes a separate issue where anything reading bitcode files using a new version of LLVM (e.g. the versions of llvm-dis or llc compiled by rust) will magically discard all the debug metadata.
you are my new favorite person in the world, thank you for figuring this out!!! I would be more than ok accepting a patch to pass these arguments by default! Pull requests are always welcome :)
Ship it, shipt it! :cactus:
This is a great find indeed!

For anyone interested, here is another source of information on DWARF on Mac OS X: The DWARF standard says that namespaces are not supported yet in version 2. I'd be interested in what the consequences of this are. Other than that I don't think we use anything that needs a newer version than 2. I'd be happy to turn this information into a fix and a pull request but I don't have a Mac to test it (yet). Thanks again :+1:
cc me
Change:
fn forbidden_narratives() -> Result<isize, ()> { missing_discourses()? //~^ ERROR try expression alternatives have incompatible types <del> //~| HELP try wrapping with a success variant </del> } fn main() {}

Discussion:
Reproduced on versions: - Isolated example to reproduce: Actual error: Mentioned suggestion about "wrap into " is incorrect at all. There we should deref the value from the . - - Expected error: (something like this)
Here's where the suggestion gets issued: The motivation was to solve (where a -expression appears in tail position, which seemed likely to be a common mistake), but it turns out that there are other situations where we run into a type mismatch between match arms of a desugared expression. We regret the error.
Here's another case of this:
I see what's happening, we're only checking wether the error came from a desugaring, disregarding the types involved. It should be possible to check that information as well, even if the suggestion is only provided when it's a where everything but the error type matches. (I think it's ok if the supplied error cannot be converted to the expected error, as this suggestion exposes newcomers to a non-obvious construct at least.)
Clippy to detect this that we might want to uplift ...
(But for now I'm just going to remove the suggestion.)
Change:
--> $DIR/issue-87635.rs:4:5 | LL |     pub fn bar() <del> |     ^^^^^^^^^^^- |                | |                help: provide a definition for the function: `{ <body> }` </del> <ins> |     ^^^^^^^^^^^^- help: provide a definition for the function: `{ <body> }` </ins> error: aborting due to 2 previous errors

Discussion:
It suggests when it should suggest or at least suggest () Errors: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Probably the "free function without body" variant has this bug as well.
The code at issue:
I think I'll take a shot at this. claim
That was... an easy fix. to That provides this: which isn't entirely satisfactory imo cause the suggestion span is directly after the rather than a space after, but it's at least valid Rust code that can be formatted into more "properly" formatted Rust code.
It appears that it has a similar bug: Looks like this can probably be fixed similarly.
Oh wait, that bug was caused by me. It looks like I'll probably have to implement a better solution.
Okay, so it appears that this bug is triggered in inherent impls with and without a semicolon, and in free functions with a semicolon. I'll have to find some kind of way to change the span depending on if it had a semicolon or not.
Okay, so it looks like in 99% of cases that trigger the same code path as this error: free fn free const free static free type inherent const inherent fn trait const trait type trait fn the existing code is already correct, as in those cases a semicolon is (usually) required. Either we can modify the parser to give some kind of indication to the AST validator that an inherent fn/const/type has no semicolon at the end, or we can just use a hack to check if there's a semicolon at the end of the span
I'm not quite sure how this should be fixed :/
I would suggest asking in since someone there can probably give advice.
Change:
<ins> error: `main` function is not allowed to be `#[track_caller]` --> $DIR/error-with-main.rs:1:1 | LL |   #[track_caller] |   ^^^^^^^^^^^^^^^ LL | / fn main() { LL | |     panic!("{}: oh no", std::panic::Location::caller()); LL | | } | |_- `main` function is not allowed to be `#[track_caller]` error: aborting due to previous error </ins>

Discussion:
Crash occurs in both 1.46.0 beta and in current nightly. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I made the false assumption that this was rustc crashing, but it's actually the binary that crashes upon running it.
Cc We probably just want to ban track caller on main (and maybe any lang item function?)
claim
Same with : results in edit: I think is a more general problem so I won't change that here
Assigning as and removing .
Change:
Ok((Some(vr), TrailingToken::MaybeComma)) }, <del> ) </del> <ins> ).map_err(|mut err|{ err.help("enum variants can be `Variant`, `Variant = <integer>`, `Variant(Type, ..., TypeN)` or `Variant { fields: Types }`"); err }) </ins> } /// Parses `struct Foo { ... }`.

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Although I know Enums take to form of: I sometimes find myself accidentally defining them as I would a Struct (): The current output is: This always takes more than a few seconds to parse and then realize my mistake. Is it possible to change this to something like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Do you have any suggestion for how the compiler should distinguish between "trying to write an enum with struct syntax" and "trying to write a struct but used the enum keyword"?
Linking to the topic on internals where some other folks have left suggestions (). Although none of those directly address your question. My gut reaction is to assume that if the "enum" keyword is used that truly was the intention of the developer, but if it wasn't, hopefully some help message like the : Would provide enough information to trigger an "Oh wait did I really want to use an enum here?"
claim
Change:
base.max_atomic_width = Some(64); base.pre_link_args.get_mut(&LinkerFlavor::Gcc).unwrap().push("-m64".to_string()); base.stack_probes = true; <ins> base.static_position_independent_executables = true; </ins> Ok(Target { llvm_target: "x86_64-unknown-linux-musl".to_string(),

Discussion:
With musl we can generate static binaries just fine. But without much work we can even generate a static position independent executable, which would enable Address Space Layout Randomization for free. For this to work, we need: rustc: gcc: remove any has or replace musl with is a program printing all the AUX vectors, which also contains the entry address of the program. As you can see it changes with every start of the program.
If there will be no native support, at least ship along with and add some possibility to change the startup file.
something like:
The workaround may be similar to what I recently did to statically link to bionic libc () - produce a with and then link manually. ( has nice defaults, but is pretty inflexible when you need to do something different with linking, modulo custom target specifications.)
Hmm, I don't want a workaround. I rather want a secure static binary with ASLR by default.