jiebi/CodeConvo huggingface dataset:
This code will fail to link because is merged into . Since global asms in LLVM can't reference symbols natively, we currently will add the mangled name to the string and pass it to LLVM. To prevent the file being optimized away, we add it to . A few issues exist: does not handle these functions specially, and therefore above is considered as internal function and have attribute attached. LLVM believes that it is allowed to merge internal functions into an exported function despite present in . I think LLVM should be allowed to this because we emit the internal linkage, and from my understanding renaming a local symbol should probably be allowed. argues otherwise and says that shouldn't touch the symbol. The symbols are , but it wouldn't show up as used in the exported symbol list, so it can still be stripped while doing LTO. We should do the following: [ ] Ensure that these functions are not emitted with internal linkage [ ] Ensrue that the functions used will be marked as used in and thus reach the linker/LTO. [ ] Ask LLVM to clarify the behaviour of combining + . cc label: +A-inline-assembly +F-asm This will block
I think should be enough to ensure that the symbol reaches the linker even through LTO. So really the only thing to do is change the symbol visibility. This isn't ideal though since we don't need this symbol to be exported outside the current compilation unit, it's just that LLVM is unable to see the use of the symbol.
It could be argued that this is actually an LLVM bug since linkage is supposed to preserve the symbol name in the object file:
I had to have to prevent from being thrown away.
Anyway, the biggest issue is the linkage, which is wrong anyway if the global asm and the referenced symbol are not in the same CGU. Given that currently both and the linkage computation comes from the same source of truth , a potential fix should be able to address all issues simultaneously.
This is fixed by . The proper behavior for LLVM is still unclear, but at least fixes the immediate issue since those symbols now have external linkage. This is a separate issue, but I think the proper way to fix this is to ensure that the itself reaches the linker. The problem here is that if there are no symbols to pull in the object file containing a from an archive then that will not be linked into the final binary.
I think we can fix this by inserting a dummy symbol in the and then including that symbol in the synthetic object file from .
It's of a different cause, but will have the same effect. I prefer to have it tracked in the same issue (but different work items). The problem is two fold. For the normal non-LTO linking, what you described is sufficient. The major issue is LTO. Because LTO works on IR but not binary, it doesn't know if a symbol is being used in . We need to pass a list of symbols to LLVM to ensure they are kept. Currently this includes all exported and symbols, but it also needs to include all symbols referenced by .
Do you have an example demonstrating the LTO related issue? Optimizations during LTO cannot remove symbols from yet, since as you describe the references to those symbols from the inline assembly are still opaque to it. For example, the internalize pass in LLVM comments:
That comment suggests that even with internal visibility, LLVM isn't supposed to delete a symbol that is used by . So perhaps the issue really is in the MergeFunctions pass which should be fixed to preserve a symbol alias if that symbol is used by .
Here's my attempt at a fix in LLVM, but I'm not too happy about the code. It could use some review by someone more familiar with LLVM.
The following code snippet demonstrating or-patterns crashes the nightly compiler on the Playground as of 2-2-2020. () I understand that or-patterns are incomplete feature, thus errors are expected. But I was told to anyway (cc: It's not convenient for me to test locally right now; is it possible to get a backtrace on the Playground?
You might want to throw this into your PR () as a test case.
Would appreciate clarification here: I don't believe pattern binding with or-patterns within function arguments () is semantically different from a pattern consisting of only the variable name (). However, it's semantically valid code, and can be used as a contrived example to demonstrate exhaustive pattern matching. Which is how I found this ICE in the first place.
It's semantically equivalent, but it results in different code-paths in the compiler. I'm quite sure that will fix this though as it seems more or less like a dupe of (but different enough that a test case should maybe be ). The MIR parts of or-patterns have simply not been implemented yet, but we're pretty close.
<!-- 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: <!-- 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<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It doesn't seem to be related to GAT, only influenced by TAIT.
seems like another version of
claim
Updated to via rustup. I have a and additional which specify additional rustc arguments. Now if I run The build will succeed but then fail to run qemu because Instead, there's a file named in the directory where xargo was run from. To fix this I had to change the target json file with these options: I'm afraid this could subtly break my builds elsewhere, as the linker is, in fact, GNU ld. I believe this is related to the latest -pie/-no-pie patches which somehow interfere with custom cargo linker arguments specifications (where ends up landing instead of output file name).
Seems like is likely to be related?
That's my suspicion
hmm my change shouldn't have impacted when the -pie flag was sent, only the -no-pie flag. what version were you using before?
Could you please build with and post the output related to the link step (after the line)
triage: P-high Not assigning this to anyone immediately, since seems to be on it -- if you could take a shot at supplying that debug output it would be very helpful, thanks. =)
does that contain the info you needed?
It does look weird as I don't see any standalone in the command line.
Yes, that helps. I think this is what is happening: Even though you have set in your target file to produce position-independent-executables (pass the "-pie" flag), the code overrides this because it sees "-static" on the linker's command line and decides not to generate PIE. My PR made it pass "-no-pie" in this case, and fall back to removing -no-pie if the link fails For some reason this seems to be confusing ld instead of causing it to generate an error Can you confirm this by manually running: (same command line without -no-pie) to see if it works correctly, and also a ? I need to look more into ld to see if -no-pie is even necessary for it, I think maybe the default pie stuff might only be applicable with the gcc front-end. If so, I think the fix would be to change the code not to generate -no-pie if linking with ld.
nm, I think I was able to reproduce this. I don't see -no-pie documented for ld so I think that is the problem. I'll work on a fix.
Thanks, I will test this asap!
Works! Thank you!
As noted in which tracks the diagnostic issue, the standard library previously accepted code (with differing behavior) on a number of intrinsics with "intended to be const" arguments. Since , though, this code is rejected at compile-time. For example, this compiles on stable but not 1.54 (nightly as of this writing). I think at minimum we need to identify the set of code that changed behaviors and document that in release notes.
cc -- on the point about documenting this change in behavior in the release notes, would you be up for either identifying the set of intrinsics which changed behavior or documenting how to do so?
Looking back at the crater run, we only ran it in mode, which doesn't perform monomorphization. This is the reason why this wasn't caught earlier. The full crater run for beta is currently running, so we should be able to get a clearer picture of the breakage once it is done. Documenting this is difficult: the new behavior affects all intrinsics which use const arguments. A quick grep of stdarch shows 1741 intrinsics, of which about ~150 are stable.
This is in 1.54, not 1.53, so the currently running beta run won't catch anything, right? It may make sense to run a crater on the PR itself, though. It is worrying that so many intrinsics are affected towards a compile-error, vs. e.g. having a warning - perhaps deny-by-default - like clippy's on the atomic Ordering params...
run mode=build-only end= start= name=issue-
:okhand: Experiment created and queued. :mag: You can check out and . :informationsource: Crater is a tool to run experiments across parts of the Rust ecosystem.
The mechanism used to validate the immediates using const generics is: offering the validation feature: a post-monomorphization error while evaluating a forcing the evaluation of the const for the const generic parameters of a given intrinsic: e.g. the above is as and the body of the intrinsic will start with a static assertion ensuring is indeed a 4-bit value. Note that I've linked to the more common macros, but this mechanism is applied throughout including arch-specific intrinsics and validations: e.g. , or .
Any intrinsic using these macros can cause an error like in the OP with an argument that doesn't pass the checks, but this set of functions should be equivalent to: all the intrinsics which have been ported to . This means this mechanism is very well centralized and could be deactivated depending on the new crater run results, however that'd mean that we would return to the current situation of, depending on the intrinsics, having assertions or crashes in LLVM instead.
And the move to 'proper' const generics and the new validation are coupled because we would otherwise have undefined behavior (or be unable to codegen? -- what would happen)? Or can we decouple them?
We get LLVM assertion failures if invalid values reach codegen. I'm not sure if decoupling is even possible. For example, these don't work in debug builds:
It might be possible to do something involving specialization on const arguments... that seems rather fragile though. An alternative might be to change the LLVM IR generated by rustc, but it seems like currently rustc has no idea about the structure of these LLVM intrinsics so that probably won't be easy either. How is it then possible that the example in the OP here compiles and runs on stable?
Previously stdarch had massive statements to convert the value to a constant argument for the intrinsic.
:construction: Experiment is now running :information_source: Crater is a tool to run experiments across parts of the Rust ecosystem.
:rotatinglight: Experiment has encountered an error: command failed: exit code: 1 :hammerandwrench: If the error is fixed use the command. :sos: Can someone from the infra team check in on this? :informationsource: Crater is a tool to run experiments across parts of the Rust ecosystem.
retry
:hammerandwrench: Experiment queued again. :information_source: Crater is a tool to run experiments across parts of the Rust ecosystem.
:construction: Experiment is now running :information_source: Crater is a tool to run experiments across parts of the Rust ecosystem.
:rotatinglight: Experiment has encountered an error: command failed: exit code: 1 :hammerandwrench: If the error is fixed use the command. :sos: Can someone from the infra team check in on this? :informationsource: Crater is a tool to run experiments across parts of the Rust ecosystem.
edit end=masterc1ac408d93bb7adaa3a51dabab9266e82eee8 start=master# name=issue-
:rotatinglight: Error: failed to parse the command :sos: If you have any trouble with Crater please ping ! :informationsource: Crater is a tool to run experiments across parts of the Rust ecosystem.
name=issue- end=masterc1ac408d93bb7adaa3a51dabab9266e82eee8 start=master#
:rotatinglight: Error: it's only possible to edit queued experiments :sos: If you have any trouble with Crater please ping ! :informationsource: Crater is a tool to run experiments across parts of the Rust ecosystem.
retry
:hammerandwrench: Experiment queued again. :information_source: Crater is a tool to run experiments across parts of the Rust ecosystem.
name=issue- end=masterc1ac408d93bb7adaa3a51dabab9266e82eee8 start=master#
:memo: Configuration of the experiment changed. :information_source: Crater is a tool to run experiments across parts of the Rust ecosystem.
:construction: Experiment is now running :information_source: Crater is a tool to run experiments across parts of the Rust ecosystem.
:tada: Experiment is completed! :barchart: 56 regressed and 14 fixed ( total) :newspaper: . :warning: If you notice any spurious failure ! :informationsource: Crater is a tool to run experiments across parts of the Rust ecosystem.
All of the new failures that weren't in the previous report seem to come from , which is already fixed.
And it seems it's only 2 new crates that depend on this version of . So while post-monomorphization errors are tough errors to trigger and find consistently, the results are at least encouraging. It can also be noted that the rough "evaluation of constant failed" error in the OP, has since improved on nightly, to somewhat acceptable levels. <details<summaryHere's how it looks now</summary</detailsAnd could be improved still if we, for example, specialized in the handful of actually used widths.
This is a common typo I make when hoisting an inconditional let binding into the let chain to merge two let-chains that could be one. The parser only needs to do look-ahead 1 and 2 to detect the case and recover. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
The following code fails to compile, because using function pointers as const generics is forbidden: However, if the function pointer is inside an array, it suddenly compiles: Is this intentional, or should it also be forbidden? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The first is definitely intentional. have an unstable notion of equality, in particular if they point to instances of generic functions: two entirely independent functions might have "equal" function pointers if they happen to compile to the same assembly code, and two identical instances of the same generic function in different crates (or even just different codegen units) might compare "inequal".
The second is a bug, good catch! I misread the issue description at first. This should not work in arrays -- I assume this would be fixed by properly moving to valtrees. Cc
still compiles, the issue is that function pointers are currently considered to be structural match. I intend to work on structural equality in the near (not that near) future, going to assign this to myself. claim
Same issue with raw pointers (both and ):
This no longer works: Looks like the issue got fixed? We should make sure we have a test though.
this happens as const generics now relies on instead of simply using structural match.
Compiler crashes while compiling using Cargo. Cargo version: cargo 0.6.0-nightly ( 2015-10-17) rustc version: 1.3.0
It looks like this comes from the linker producing output (normal or error) that is not valid UTF-8. Fixing this in any other way than just using a lossy conversion is going to be really painful because it goes through the error logging infrastructure, which all works with s. That's certainly not ideal, because it would be best to relay other programs' messages to the user unchanged, but it's probably the only realistic way to handle this in the near future.
Just dump the bytes as hexadecimal? I am not sure what is going on here.
My first thought was that the path was probably not UTF-8, but because of the way cargo invokes it that crashes rustc long before it tries to link anything, so that can't be it. I'm not sure why else the message would be non-UTF-8. (I can't reproduce the ICE on that crate (I just get a normal link error), but I can reproduce the ICE by constructing a situation where the linker prints non-UTF-8 messages.) But yeah, some kind of lossy conversion with hex escapes is probably the way to go. I'm not aware of an existing function to do that.
Actually, mapping with is probably good enough.
foo'ncollect2: error: ld returned 1 exit statusn` Not great, but not an ICE and probably good enough until we have a dedicated function to do this sort of thing since this should be a very rare error.
We expect everyone to rebase instead of merge and we also try to have fixup commits squashed into previous related commits. I think we should document this policy, since it keeps suprising newcomers.
I can take care of this one as it's quite a fresh experience :).
I think we should only rebase when resolving merge conflict, or the review process has completed and reviewer request a rebasing. Otherwise I prefer adding new commits for easier reviewing.
I agree with that this policy is sound for actually merging the PR, but it might cause confusion for reviews. I've had a PR lying around for awhile, and when there is merge conflicts the 'waiting-on-author' label gets so noone reviews it, but when I do the rebasing to get back my 'waiting-on-review' it seems as if Github sometimes loses context of previous reviews, which can be quite confusing...
for the record: I personally want no rebasing and just merging, I'm just stating what the policy is.
Before we close this issue. Could we talk a bit about ? I think we should encourage contributors close issues by keywords in PR descriptions only. Because otherwise the commit could be rebased many times, and each time it creates a reference to the want-to-close issue. Also in the referenced issue, the commit number of the new commit that could close that issue is not really informative. The PR number itself appeared in the issue is more informative and concise. In short, we create another policy for closing issue.
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at ' has escaping bound vars, so it cannot be wrapped in a dummy binder.'', 'thread 'rustc' panicked at ' has escaping bound vars, so it cannot be wrapped in a dummy binder.'' 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: [issizedraw] computing whether is [layoutof] computing layout of -- label +F-impltraitinassoctype +F-inherentassociated_types
ah lol this regressed in cc
A while ago we merged the first backend pr to enable automatic differentiation in Rust: This was good enough to add and enable the config in and run . We would now like to improve the integration to also successfully run (to use Rust in our autodiff compiler explorer). and I looked into it for a while and while it seems like a simple linker issue, we didn't fully understood where it comes from and what's the best way to fix it. This commit has a few more changes (not yet upstreamed) that might help for understanding how enzyme is used We also have documentation here: Back to the issue. We first build Enzyme (a git submodule) and then try to link it. To copy Jed's observations: The code to add is in inside fn cargo. Note that linking works correctly when building normal crates. Also, I find it odd that this one line of code yields so many repeat arguments (as in, Is there a better way to link Enzyme? Should we prefer to elide Enzyme linking when it isn't needed or be more explicit with paths so it is always found? A potentially related linking error only happens under MacOS: Related Zulip issue: https://rust- Tracking:
It's not just about dist builds; this happens on any build that triggers tool builds (e.g., running would fail too). This happens because enzyme linking flags are set in the general-purpose cargo function and used in every build even when they aren't needed. changes this so that the flags are set only for the rustc build as they aren't required for other builds.
Thank you for the quick fix!
<!-- 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. --This bug popped up in CI on a project of ours. This does not reproduce on stable, but does reproduce on nightly and the latest beta (). Bisection shows that was the first build with the regression. Further bisection points to being the commit that introduced the regression. If I had to guess from the PRs in the rollup I'd say seems the most likely, since it touched the code around the error source. <!-- 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
label: +regression-from-stable-to-beta
Reduced:
This assertion is indeed introduced in . The two captures have the same place but different CaptureInfo. cc
Interesting. It's a bit hard to imagine how could have introduced this, since that just sorts a list. Fascinating! Maybe somebody from has a clue?
Actually, it's not at all hard to imagine, because introduced the following: The projections are actually the same, but the types differ in regions, which probably means that this comment is wrong:
Yeah, I just checked and the region of the match is an inferenced variable and gives an concrete ReFree instead.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
Did some analysis: We cannot just replace the with . This will create two mutable references in edition 2021 and fail borrowck. Pre-2018 the places do get merged later so the issue isn't exposed. None of the upvar code makes use of the region info, and writeback will erase it anyway. So I think the fix should just be have the region erased when inserting/looking up from capture_information. I can submit a PR if you haven't started
I just started looking at it but if you have a solution, go for it!
Happy to review your PR
I'm not sure about region code that much but regionchk uses the regions created: I think at one point mentioned getting rid of the region field entirely in UpvarBorrow, but since it wasn't required the discussion didn't proceed. Also it's more like this is a bug of the capture analysis than the sorting. We should never have two same places going into min capture in the list.
I was thinking about erasing the region from s (i.e. the key of captureinformation). But it turns out that's used later to create upvar tuple... So I switched captureinformation from HashMap to a linear vec looked up with custom eq fn instead.