jiebi/CodeConvo huggingface dataset:
The following does not error locally / on the playground If I copy paste the macro into the same file, it errors as expected Checking other macros, error as expected.
This feels like it's related to a similar issue () I created a while back.
cc
This is probably because the "error" is just a lint. And we appear to silence it in external macros. We shouldn't do that. IIRC this is just a flag that needs to be set for the lint macro
Yes, we need to set reportinexternal_macro param on the lint I believe
Ah, that makes sense! Building locally with the parameter set to confirm. it does ^^ will check the samples in there too.
time: 58.110 LLVM passes vs time: 785.935 LLVM passes running on hyper Full output at
cc (There's a slight suspicion that this may be caused by , since that's touching trans/codegen.)
ran with , got
cc
Could you provide files for before and after? Hopefully should work now.
Looks like this is caused by -- the assume intrinsics no longer get simplified into nonnull metadata on load instructions and cause massive slowdowns.
<!-- 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. --(reduced) <details<summary<strongOriginal Code</strong</summary<p</p</details- Above original code is mutated from I guess at the top causes ICE <!-- 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- ICE occurred at
label regression-from-stable-to-beta
searched nightlies: from nightly-2024-02-01 to nightly-2024-04-10 regressed nightly: nightly-2024-02-09 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: aarch64-unknown-linux-gnu Reproduce with: </detailscc
WG-prioritization assigning priority (). label -I-prioritize +P-medium
<!-- 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. --I tried to call default trait implementation from overriden method. Googling was not so useful as wanted so I started playing with "super" keyword and found this bug. Bug appears both on stable and nightly <!-- 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 --
Bisected:
Relevant code: In case it helps, the merges in nightly-2020-06-05 were , , , , , and . Playground:
Error from just before the regression was introduced (run with ):
Assigning and removing as ) in the prioritization working group.
claim
<!-- 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. --Another case from : The md5 of is: <!-- 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. --It is test with nightly, beta, and stable versions. : The output is from nightly. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Because we already emit some correct errors a potential fix would be to just remove the problematic and return an empty function body. However there's another problem; call in generates non-existing tokens outside of the file to close all unmatched brackets. That's why we see column 11 in the error message even though column of the last token is 9 in the source file. called by (called by to recover from the invlid argument when seeing which is invalid in pattern context) first generates at column 9 (which is actually the location of ), which I guess (didn't check) shifts to column 10, which is somehow skipped and some other function inserts (couldn't figure out which function) at column 11. As a result we get this error that points to outside of the file
Is there an expected buffer overrun here or is it guarded?
Assigning as discussed as part of the and removing .
I ran  and some finer-grained manual bisection. The regression happened in cc
I'm guessing is because of this code branch: I haven't checked to see how it could even get to it, as looking at the code it should be unreachable.
Actually, this is caused by a different problem (), because if you try the same code without a trailing newline, this behavior doesn't occur (the error message then points to column 10, which is correct, as it is the location of the EOF token). The spurious ]` is an unrelated issue, which I have filed separately ().
Fixed by but there's no regression test for this case, marking as E-needs-test.
I'm running the example from the section in Rust Book. I noticed that when I embed the code into Python and execute it, the execution time does not depend on the counter size (initially set to 5 million in the book). Although the text suggests it should (we are comparing execution time in different languages after all). However, if I modify the code to return, say, the count in the spawned thread (and later do , the execution time starts depending on the number of iterations. This seems not to depend on the number of iterations: This seems to get slower with more iterations (as it should): Why is this so? Is this some sort of compiler optimisation that removes the loop execution altogether? Should the code in the book be updated?
I thought that was enough to kill the optimization, but I guess not. Yes, it should be updated. (I think you can get rid of the `` too...)
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri 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 prioritization.
I need to port parts of from miri to rustc and only keep the actual miri-parts in miri. I'll try to get it done by tomorrow night.
check-in from compiler triage: Go go!
do you have the component installed? That adds a bunch more crates to the sysroot.
I believe these are required in rustc-dev as part of the need for (). I'll admit, I still don't fully understand the need for that, as it is quite mind-bending.
They are included in both rustc component and rustc-dev component. The latter are definitely used for example to build clippy, but I don't see reason for inclusion in rustc.
Tracking issue for making on stable: ,
FYI, in Rust issue tracker, "tracking issue" is a jargon for stabilizing features already in nightly. As I understand, is not yet in nightly?
A tracking issue has to be opened before a feature can land in nightly, because the attribute needs an issue number to refer to. has also been approved already, so it'll land in one of the next nightlies.
How about moving this to stable?
What's left to do to stabilize this feature? Any ETA?
Can this be stablised for 1.37?
Another reminder -- can we kick off FCP for stabilization?
any updates?
fcp merge
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.
whether pointer arithmetic is allowed to - temporarily - leave the bounds of an object, then go back into bounds and afterwards dereference the pointer. The question is if code like this: is sound or unsound. The current documentation says: So it specifies that the resulting pointer “remains attached to the same allocated object that points to”, which suggests that after going back into bounds, dereferencing should be safe again. It also says “this method basically delays the requirement of staying within the same allocated object; ” which sounds like, staying within the same allocated object is still a requirement, which could be interpreted as that whenever any intermediate value did not stay within bounds, that intermediate value has some delayed violation of requirements attached to it that triggers UB once the final (back in bounds) pointer is dereferenced. The following comparison, “ / / is immediate Undefined Behavior when crossing object boundaries; / / produces a pointer but still leads to Undefined Behavior if that pointer is dereferenced” can easily be interpreted as confirming this interpretation, since object boundaries are crossed (twice, first going out of the object, then going back in) and the pointer is dereference afterwards (right after the second crossing of object boundaries). After I was addressing this , gave the answer modify labels: T-doc, T-libs, T-lang, C-enhancement Feel free to remove a label if this doesn’t seem relevant for that team.
Ah I see... yeah that is a misunderstanding. The delayed check means that when the (derived) ptr is dereferenced, that ptr needs to be in-bounds, but the intermediate ptrs do not have to be.
<!-- 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: App P: App C: Build this in Windows. Since has "windows" subsystem, it will create no console window (i.e. no process). Since is a console app, when the process is created, I expect to see one console window that prints "Hello World" infinitely. App creates its console window but no text is printed. In Windows, spawn() eventually calls to with a , whose  is hard coded to . Additionally, it also with , and set them to the . Since app uses "windows" subsystem, it does not have console. stdout is always . Combining with in causes the unexpected behavior. If I make a call to with same parameters except a "zeroed" , it exhibits the correct behavior. spawn() should only conditionally set the flag if it can obtain those device handles, and never set any of those handles . Like this (pseudo code): <!-- 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 think this will need a T-libs-api decision as the current documentation for  (and stdin/stderr) is: I would guess that this "inherit by default" is why it's implemented the way it is. But perhaps there's some wiggle room with what it means to inherit handles that don't exist so we can change it. In either case it would be good to have some way to use platform default behaviour here. label -T-libs +T-libs-api
That's exactly my point. If there is nothing to inherit in the first place, just inherit nothing. The current behavior () is simply wrong. I believe fixing it doesn't violate the current specification.
Basically, currently there are only two options when handling the stdout/stderr: inherit or pipe. I think there should be a third option: isolated - make the child handle its console by itself. For example, if user calls and , he basically says "the parent process doesn't care about the child's output". It is the same as the "windows" subsystem case above. In this case, the flag should never be set, regardless if or is called.
More importantly, this is de facto the default way of how a process is created in Windows. Defaulting to really makes me confused before reading the internal source code.
Not always. Parent process can still set those handles to something other than . For example, if you launch App P from IntelliJ it actually prints "Hello World!" in a loop but not in the spawned console which is empty, but in IntelliJ internal terminal. returns non invalid handle. This solution would make behaviour different depending on how you launch your app. Also, you can explicitly ask to create new console with even if your app already uses console subsystem. In this case you also likely want to avoid inheriting handles because you want output of the spawned process to be displayed in the new console, not in the existing one. This solution doesn't help with this.
I can't verify your statements since I don't have IntelliJ atm, but even it's true, isn't it IntelliJ setting up the console with maybe some special debugging API? How to you modify the code of P to achieve the same? And realistically speaking, do people actually do that with GUI apps? I think in this case, it's impossible to be 100% sure where the user wants the output at. New option might be the way to go.
Your prediction was dead-on, as it came true in While we can do this, as is proposing, it seems best here that we create a function, or set of functions, that explicitly handle this kind of situation rather than guessing.
Even with new APIs, we still need reasonable default behaviour. And the Command API is documented as inheriting handles by default. However, currently the API neglects the "no handle set" case entirely as that's not really a thing in POSIX or ISO C (well, you can close stdio but that's usually considered a Bad Thing unless you're being very very careful).
Spawned off of When passing to rustc I would expect all paths that start with to be replaced with , instead a is still present. Note that this happens even in release mode, because rustc always tells the msvc linker to generate files. This can be "fixed" by passing either , or to rustc, but doing so will break backtraces with ( already prints almost nothing in release mode). As a sidenote, do we really need backtraces in release mode, and by consequence files? They will break anyway if only the is distributed or the directory is deleted. Moreover this shouldn't be needed in the first place since promises to "remap source names in all output (compiler messages and output files)" (from the output of ), "including ). Also note that neither nor the rustc book mention the need to pass one of those arguments to rustc to remap/remove the path to the file, which makes it harder for non-experts to know how to remove them. :
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Perhaps this should be amended to say compiler output but not linker outputs. PDB files are generated at the linking step, which is probably why sees non-determinism for --crate-type=bin (linked) and not for --crate-type=rlib (not linked). Passing to the linker to put a relative path to the PDB files is probably the best choice, as it is the least destructive, and the debugger will look for PDB files next to the executables, so it will be able to find it. Chromium uses this for its Windows linking step as well: ;drc=;l=2358 Doing this with could work if you can figure out which "to-be-remapped" path is going to be the path being written by the linker, and then pass the resulting path to . I must confess I am not sure how linking is being done, but I assume the binary is being linked by a dedicated linker, not by rustc itself? If so that is not too reliable. rustc could provide a switch to remove the absolute path to PDB files, which would just map to . The value proposition there seems low, since you can pass that as the user anyway.
Determinism is important for both release and debug builds, so I don't believe there is anything release-mode specific here or that a solution should be chosen that doesn't deal with debug mode? Could you say what is breaking about backtraces with ?
Without that flag I get something like: <details<summaryBacktrace</summary<p</p</detailsBut with it it just prints: <details<summaryBacktrace</summary<p</p</detailsThis seems to happen because the pdb file is searched relative to the current working directory, and when running that's often not the directory with the executable and pdb files. appears to work, but only as long as you execute it from the crate root, which is definitely not ideal.
Can move to the crate root before executing the target executable? Then cargo could pass (or debug) while other build systems pass or whatever works for them?
Wouldn't that break any workflow that relies on the current working directory always being where is executed from?
I think this meant the crate root instead of the cwd? I had no idea that would be a common thing, but you're right. It would change any use of . I would expect to be more commonly used for relative paths, as it doesn't depend on running from a cargo source tree, but maybe I am wrong. Regardless, I can see why changing behaviour isn't ideal. The MSVC linker doesn't present a whole lot of options though, as the path relative to where you plan to run the binary has to be encoded into the pdb files if you want a deterministic output. It seems the options are: -determinisic output, backtraces always work, debuggers work: PDB absolute paths. This is the default behaviour. output, , and backtraces work from the exe's directory: output, backtraces work from the crate root, but debuggers won't work: Have I missed an option? There's no option that I can see with both deterministic output and backtraces working from arbitrary working directories. AIUI, this github issue is about --remap-path-prefix not adding a flag, essentially. It would be nice if deterministic builds were easier to get!
But based on all of the above, it seems to me that is better solved through Cargo than through rustc's , perhaps behind a Cargo flag in As a convenience, maybe could provide an option to move to the exe's directory to run it, instead of users doing , which would let option 2 be more ergonomic while also supporting debuggers.
Would it be possible to have create a symbolic link to the file or the directory when it's not already present in the current working directory? This would partially solve the ergonomic problems of approaches 2 and 3
It'd probably be easier to have set , which effect the default search path for the used for
Any update on this? :)
I've just opened which solves the problem by making always pass to the linker. This seems like the best solution to me. The PR is currently blocked on backtrace-rs not handling this properly, but I've opened , which will hopefully fix that.
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
Regression in cc :sweat_smile:
I knew this was a source of ICEs Most of these should already be reachable if they are in the body of a constant used in an array length. If you want to try fuzzing by sticking code into a const body...
<!-- 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. --This code compiles correctly: However, this code does not: The only change was effectively replacing with . My understanding is that these are supposed to be equivalent as it is . The exact compile error is as follows: The error also occurs on the Nightly compiler.
We currently do not normalize projections if they contain unbound variables (stuff which is introduced using a qualifier, in your example). This means that we never actually see that is equal to . cc but I don't think we can do much about cases like this for now.
Is this the same underlying issue as and possibly
I think has a similar cause. is caused by something different, probably related to
Using trait objects instead of has the same issue
Came up with another interesting version. This will fail to typecheck: Replacing the header of foo with this will successfully typecheck: Might be useful for diffing.
Fixed by . Not going to close this because this is a simple example that didn't ICE, but still failed to compile.
I believe this should successfully compile, but it currently fails claiming that vec's iterator isn't ExactSizeIterator: Things compile correctly if the bounds are changed to rather than .
It does seem like it should compile... cc
Another instance of this from : fails with
do you know of a workaround for this bug? It's currently blocking me and I'm not entirely sure how else to structure my code.
The only workaround I know of is to remove the lifetime parameter Steven Fackler
I believe this issue I ran in to might be related - . I was trying to put a bound on an associated type from two different types and require them to be , but Rust always just wanted to assume the types must be the same. By creating a separate trait that is implemented without relying on an HRTB, and then using the HRTB around that trait, it did compile. I'm fairly sure this is a bug. rustc ought to still be able to resolve what the associated type actually is and then evaluate traits on that. It seems like it's trying to look for implementations on a hypothetical associated type black box rather than the real type it points to.
Another example, when trying to bind :
Ran into this in one of my own projects, and used this odd workaround (suggested on satck overflow):
Another variation of this issue (as far as I can tell): Fails with:
I just ran into this (): I get the following error on latest stable (1.52.1): The workaround in my case was to pull out the associated type into a type parameter, and require that it be invariant w.r.t. the universally quantified lifetime parameter ():
Fixed by , marking as needs-test because wasn't an ICE and a simple enough example I'd like to have a test for.
This bug might not be completely fixed. Here is another test case that still fails on nightly and beta: EDIT: Made the case a bit smaller:
is the smallest example I can find: This below works: While this doesn't: Can you confirm that the second case works in your PR as well?
is still not fixed on latest nightly. cc EDIT: I suspect that this example is some form of .
Another bug of this kind: