jiebi/CodeConvo huggingface dataset:
This looks unintentional, and has been broken in all cases, until a few releases ago, AFAICT. Should this be covered by WF rules? cc Unsized constants cause an ICE, in both old trans and MIR trans: Unsized statics appear to work, but only in old trans: I believe this is possible because a constant DST lvalue in old trans is merely the fat pointer. It seems useful to allow an unsized , but IMO it should require a sized RHS instead, i.e.: And, of course, this should all go through the RFC process, to figure out all the finer details.
Should it be ? I don't think A needs to be an lvalue.
It makes more sense for constants, but I gave the example with because that's the only one that works today (although by accident).
Hmm? I mean the static is desugared into a const. works today.
The idea being that a static and a const reference both give access to one lvalue.
No, has different semantics: it allows an somewhere within and is guaranteed not to be duplicated.
Hmm? Both of these gives me a "error: cannot borrow a constant which contains interior mutability, create a static instead". This is what I'd suspect as the lvalue from the promoted has nothing to do with being a or a .
Let me rewrite my desugaring to account for that, oops.
Oh and my confusion really just stemmed from forgetting about the constants referring to statics rule. [Kind of a funny rule when works, but this is an orthogonal issue.]
I think in the meantime unsized statics should probably error, perhaps dependent on a crater run, though I doubt there's many people relying on said bug. It's much easier to relax restrictions than tighten them.
Will prepare a patch to turn this into an error, hopefully nobody has been abusing it.
This is a fuzzed test case, found with and minimized with . I wasn't able to find any similar issues: : <details<summary<strongBacktrace</strong</summary<p</p</details
This is related to , do we need to keep this ICE or we cover it at here:
The assert was in If you have a reproducer, then it can be to and the assert can be removed.
label +S-bug-has-mcve
suggested this is because when we lower the async function, we add `), whereas it should be parented as something outside of the impl trait context (as that is how such an expression would be parented, if it actually existing in the AST). I have a bit of code where I'd like to use a reference with a lifetime in an "async" function, which panics the compiler. I tried this code: I expected to see this happen: My understanding was that async functions are allowed to take references as parameters. helped to debug this a little bit and there is a suspicion that named lifetimes are somehow not properly propagated. I stumbled into this because I wanted to have 2 args with references, but if the lifetimes are elided the compiler asks for them to be . Adding them ICEs the compiler. Instead, this happened: I got a compiler panic. Backtrace:
suggested might be related
It would appear one can workaround this by using async blocks manually: I still need to test this does what I expect.
why do you need the immediately invoked closure there,
Yeah, just noticed. I think I also had some other issue / ICE, but I don't remember exactly what it was. Gonna have to check it again. Also, I don't think I knew that on blocks was a thing.
I didn't quite understand why I needed the move. I am trying to fix the original ICE, I think I got some time today tomorrow, hopefully, will make some progress. But compiler newbie, so might not work out.
You need to move to avoid the closure borrowing the references locally. It's the same situation as with I just removed all immeditaly invoked functions from eval :wink:
I am playing around with similar types of borrowing patterns, namely using StreamObj to carry a stream around inside of a struct. I can't seem to use the posted work-arounds: I am taking this working code and I'm refactoring it. Starts as: this works, compiles and runs. Then I try my hand at refactoring to move the stream out of the same scope as the await code pulling out values.
Now I can get the same ICE as this ticket: ICE: full backtrace: Then I try some of your posted workarounds and they don't do the trick, here's my best try: but this fails to compile due to an ownership issue I can't figure out:
your final borrow error is because Fahrenheit while your contains a local stack borrow. You could try using  instead of Fahrenheit.
Alternatively to what suggested, you could move the code in to an async fn:
The crater run for merged doctests () detected a large number of regressions due to tests examining the process arguments. (I don't have an exact number, but let's say ~50 projects.) Previously, there were no arguments, but now it gets arguments like which the user's CLI parsing code isn't expecting. For example, using something like  will now fail. It seems to be fairly common to have objects whose default constructor will parse the arguments from the command line. I'm not sure if or how we should resolve that. One idea is to use a different mechanism for passing in the test information (like via an environment variable).
I vaguely remember that using environment variables was discussed but can't find anything except mentioning it . Maybe it'd be a better approach indeed. Let me send a PR so we can make a crater run on it.
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: param types with same index differ in name'', 'thread 'rustc' panicked at 'assertion failed: param types with same index differ in name'' File: --auto-reduced (treereduce-rust): original: Version information ` Command:
thanks for the stack trace for this class of ICEs, it's just the right thing that I need. Minimal:
When using this branch of bitflags: through a patch in a local directory rls crashes with the following errors:
i had enabled dev overrides for dependencies in using: removing that out the output from rls is now the normal debug flags but still the same errors:
This is now causing widespread ICEs in the RLS. Nominating to get this fixed (maybe has an idea?). See for a simpler reproducer.
I encountered this issue trying out which causes rustc to crash on when invoked by RLS. I can confirm it's the exact same backtrace as
I ran into this trying out on Windows 10. RLS inside vscode ends up panicking with this backtrace: (note for repro: I had changed the default feature in tui-rs to be "crossterm" because the default feature "termion" doesn't compile on windows - but after the termion compile errors, rustc was giving me a similar panic anyway)
JFYI I could work around this problem by adding to my
I tried that with the tui-rs (it had ) but same panic. [Edit] you're right, I had missed the inside the version.
Thanks !
Running into the same issue when trying to build Clap
Same issue in vscode on linuxmint and rust 1.34.1 when trying to build glib (dependency of gtk).
There is no need to list every crate which depends on , it only clutters the thread and makes less visible.
Here's a small repro, extracted from what is doing: I'm struggling to get a repro without the compile error, though.
Thank you for such a small repro! I’ll take a closer look tomorrow and see what may be causing that. On Tue, 7 May 2019 at 22:32, Sean Gillespie <:
Looks like isn't written back for a resolution error? That still repros without , right?
Correct, it does. Further minimized repro:
Interesting. I managed to reduce it to: with: Any other combination is okay, it has to be under under and it has to be combined with a field access (bare unknown identifier doesn't ICE). I'm only guessing but it seems that it tries to emplace def 'path' under a which seems to skip a def path segment?
I think this is confirmed by A, what I believe is, more accurate guess is that we somehow don't correctly nest appropriate typeck tables when visiting .
Oh, you need to have one table per body: look in HIR for fields and map all of those cases back to the AST. This makes a lot more sense now: so is not wrong, but is looking in the wrong place.
What about this: Seems like we need to before walking the expression of the associated const?
Hm, probably! I imagined the problem is we don't nest it before visiting trait items (hence missing segment) but you may be right! Let's see :sweat_smile:
With the fix applied this still ICEs on (this time for type) which means we should nest tables for as well
I know that having huge literal in source is a bad idea, but it should not cause ICE :( It looks like something overflowed. Version: Command, output and backtrace: Here is the generator of the source:
cc
Took a quick look. We certainly have a restriction that any file can't be that large, because we use u32 for indexing. And looks like we never try to enforce it anywhere. I think the place to do that would be . Do we have any way to panic without this being marked as ICE? I don't want to thread to each , and this seems like a marginal error where it's totally OK to panic. This is even OK in the IDE context I think: IDE should enforce reasonable max size of the file (something like 10mb, not 4gb) at the virtual file system layer. The "just panic" fix is here:
Do we have any way to panic without this being marked as ICE? or if the context is available.
I tried to compile the same thing in gcc and clang: With gcc: With clang: EDIT: Opened
<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilization. Make sure to include the relevant RFC for the feature if it has one. If the new feature is small, it may be fine to skip the RFC process. In that case, you can use use in your initial implementation PR. The reviewer will ask you to open a tracking issue if they agree your feature can be without an RFC. --Feature gate: This is a tracking issue for the convenience method . [x] Implementation: [x] Final commenting period (FCP) [x] Stabilization PR: <!-- Once the feature has gone through a few release cycles and there are no unresolved questions left, the feature might be ready for stabilization. If this feature didn't go through the RFC process, a final commenting period (FCP) is always needed before stabilization. This works as follows: A library team member can kick off the stabilization process, at which point the rfcbot will ask all the team members to verify they agree with stabilization. Once enough members agree and there are no concerns, the final commenting period begins: this issue will be marked as such and will be listed in the next This Week in Rust newsletter. If no blocking concerns are raised in that period of 10 days, a stabilzation PR can be opened by anyone. --<!-- Include any open questions that need to be answered before the feature can be stabilised. If multiple (unrelated) big questions come up, it can be a good idea to open a separate issue for each, to make it easier to keep track of the discussions. It's useful to link any relevant discussions and conclusions (whether on GitHub, Zulip, or the internals forum) here. --- None yet.
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 .
I run cp ans then build && install and I get: $ build && install downloading extracting G:rust-1.59.0rust-1.59.0buildcache2022-01-13rust-std-1.58.0-x8664-pc-windows- downloading extracting G:rust-1.59.0rust-1.59.0buildcache2022-01-13rustc-1.58.0-x8664-pc-windows- downloading extracting G:rust-1.59.0rust-1.59.0buildcache2022-01-13cargo-1.58.0-x8664-pc-windows- Building rustbuild error: failed to load manifest for workspace member Caused by: failed to read Caused by: The system cannot find the file specified. (os error 2) failed to run: G:rust-1.59.0rust-1.59.0buildx86_64-pc-windows-gnustage0bin build --manifest-path G:rust-1.59.0rust-1.59.0 Build completed unsuccessfully in 0:08:36
Can you say more about how you obtained and extracted the rust source? If you downloaded and extracted from , the directory should be there.
I downloaded the source from here: and the src/tools/rust-installer is there and is empty.
Ah, the tagged GitHub releases shouldn't be used. They do not include the git submodules. The link above is the one that should be used. Unfortunately we don't have the ability to disable GitHub releases, but we can probably add an error message to x.py if it can detect this scenario.
I did build && install and got $ build && install Building rustbuild Finished dev [unoptimized] target(s) in 1m 06s warning: creating symbolic link to failed with Incorrect function. (os error 1) Building stage0 std artifacts (x8664-pc-windows-gnu -x8664-pc-windows-gnu) Finished release [optimized] target(s) in 39.
65s Copying stage0 std from stage0 (x8664-pc-windows-gnu -x8664-pc-windows-gnu / x8664-pc-windows-gnu) Building LLVM for x8664-pc-windows-gnu running: "cmake" "G:rustc-1.59.0-srcrustc-1.59.0-srcsrc/llvm-project/llvm" "-G" "Ninja" "-DLLVMENABLEASSERTIONS=OFF" "-DLLVMENABLEPLUGINS=OFF" "-DLLVMTARGETSTOBUILD=AArch64;ARM;BPF;Hexagon;MSP430;Mips;NVPTX;PowerPC;RISCV;Sparc;SystemZ;WebAssembly;X86" "-DLLVMEXPERIMENTALTARGETSTOBUILD=AVR;M68k" "-DLLVMINCLUDEEXAMPLES=OFF" "-DLLVMINCLUDEDOCS=OFF" "-DLLVMINCLUDEBENCHMARKS=OFF" "-DLLVMINCLUDETESTS=OFF" "-DLLVMENABLETERMINFO=OFF" "-DLLVMENABLELIBEDIT=OFF" "-DLLVMENABLEBINDINGS=OFF" "-DLLVMENABLEZ3SOLVER=OFF" "-DLLVMPARALLELCOMPILEJOBS=4" "-DLLVMTARGETARCH=x8664" "-DLLVMDEFAULTTARGETTRIPLE=x8664-pc-windows-gnu" "-DLLVMINSTALLUTILS=ON" "-DLLVMENABLEZLIB=OFF" "-DLLVMENABLELIBXML2=OFF" "-DLLVMVERSIONSUFFIX=-rust-dev" "-DCMAKEINSTALLMESSAGE=LAZY" "-" "-" "-" "-DCMAKECFLAGS=-ffunction-sections -fdata-sections -m64" "-DCMAKECXXFLAGS=-ffunction-sections -fdata-sections -m64" "-DCMAKEINSTALLPREFIX=G:rustc-1.59.0-srcrustc-1.59.0-srcbuildx8664-pc-windows-gnullvm" "-DCMAKEASMFLAGS= -ffunction-sections -fdata-sections -m64" "-DCMAKEBUILDTYPE=Release" -- Could NOT find Backtrace (missing: BacktraceLIBRARY BacktraceINCLUDEDIR) -- Native target architecture is X86 -- Threads enabled. -- Doxygen disabled. -- Go bindings disabled.
-- Ninja version: 1.10.2 -- Could NOT find OCaml (missing: OCAMLFIND OCAMLVERSION OCAMLSTDLIBPATH) -- OCaml bindings disabled. -- LLVM host triple: x8664-w64-windows-gnu -- LLVM default target triple: x8664-pc-windows-gnu -- LLVMHello ignored -- Loadable modules not supported on this platform. -- Targeting AArch64 -- Targeting ARM -- Targeting BPF -- Targeting Hexagon -- Targeting MSP430 -- Targeting Mips -- Targeting NVPTX -- Targeting PowerPC -- Targeting RISCV -- Targeting Sparc -- Targeting SystemZ -- Targeting WebAssembly -- Targeting X86 -- Targeting AVR -- Targeting M68k -- BugpointPasses ignored -- Loadable modules not supported on this platform. -- Configuring done -- Generating done -- Build files have been written to: G:/rustc-1.59.0-src/rustc-1.59.0-src/build/x8664-pc-windows-gnu/llvm/build running: "cmake" "--build" "." "--target" "install" "--config" "Release" "--" "-j" "4" [1/2594] Building FAILED: G:/rustc-1.59.0-src/rustc-1.59.0-src/build/x8664-pc-windows- /C "cd /D G:rustc-1.59.0-srcrustc-1.59.0-srcbuildx8664-pc-windows-gnullvmbuild && G:rustc-1.59.0-srcrustc-1.59.0-srcbuildx8664-pc-windows-gnullvmbuildbinllvm- -gen-attrs -I G:/rustc-1.59.0-src/rustc-1.59.0-src/src/llvm-project/llvm/include/llvm/IR -IG:/rustc-1.59.0-src/rustc-1.59.0-src/build/x8664-pc-windows-gnu/llvm/build/include -IG:/rustc-1.59.0-src/rustc-1.59.0-src/src/llvm-project/llvm/include G:/rustc-1.59.0-src/rustc-1.59.
0-src/src/llvm- --write-if-changed -o -d " [2/2594] Building FAILED: G:/rustc-1.59.0-src/rustc-1.59.0-src/build/x8664-pc-windows- /C "cd /D G:rustc-1.59.0-srcrustc-1.59.0-srcbuildx8664-pc-windows-gnullvmbuild && G:rustc-1.59.0-srcrustc-1.59.0-srcbuildx8664-pc-windows-gnullvmbuildbinllvm- -gen-intrinsic-impl -I G:/rustc-1.59.0-src/rustc-1.59.0-src/src/llvm-project/llvm/include/llvm/IR -IG:/rustc-1.59.0-src/rustc-1.59.0-src/build/x8664-pc-windows-gnu/llvm/build/include -IG:/rustc-1.59.0-src/rustc-1.59.0-src/src/llvm-project/llvm/include G:/rustc-1.59.0-src/rustc-1.59.0-src/src/llvm- --write-if-changed -o -d " [3/2594] Building IntrinsicsARM.h. FAILED: include/llvm/IR/IntrinsicsARM.h G:/rustc-1.59.0-src/rustc-1.59.0-src/build/x8664-pc-windows-gnu/llvm/build/include/llvm/IR/IntrinsicsARM.h /C "cd /D G:rustc-1.59.0-srcrustc-1.59.0-srcbuildx8664-pc-windows-gnullvmbuild && G:rustc-1.59.0-srcrustc-1.59.0-srcbuildx8664-pc-windows-gnullvmbuildbinllvm- -gen-intrinsic-enums -intrinsic-prefix=arm -I G:/rustc-1.59.0-src/rustc-1.59.0-src/src/llvm-project/llvm/include/llvm/IR -IG:/rustc-1.59.0-src/rustc-1.59.
0-src/build/x8664-pc-windows-gnu/llvm/build/include -IG:/rustc-1.59.0-src/rustc-1.59.0-src/src/llvm-project/llvm/include G:/rustc-1.59.0-src/rustc-1.59.0-src/src/llvm- --write-if-changed -o include/llvm/IR/IntrinsicsARM.h -d include/llvm/IR/IntrinsicsARM.h.d" [4/2594] Building IntrinsicsHexagon.h. FAILED: include/llvm/IR/IntrinsicsHexagon.h G:/rustc-1.59.0-src/rustc-1.59.0-src/build/x8664-pc-windows-gnu/llvm/build/include/llvm/IR/IntrinsicsHexagon.h /C "cd /D G:rustc-1.59.0-srcrustc-1.59.0-srcbuildx8664-pc-windows-gnullvmbuild && G:rustc-1.59.0-srcrustc-1.59.0-srcbuildx8664-pc-windows-gnullvmbuildbinllvm- -gen-intrinsic-enums -intrinsic-prefix=hexagon -I G:/rustc-1.59.0-src/rustc-1.59.0-src/src/llvm-project/llvm/include/llvm/IR -IG:/rustc-1.59.0-src/rustc-1.59.0-src/build/x8664-pc-windows-gnu/llvm/build/include -IG:/rustc-1.59.0-src/rustc-1.59.0-src/src/llvm-project/llvm/include G:/rustc-1.59.0-src/rustc-1.59.0-src/src/llvm- --write-if-changed -o include/llvm/IR/IntrinsicsHexagon.h -d include/llvm/IR/IntrinsicsHexagon.h.d" ninja: build stopped: subcommand failed.
From: src/test/compile- Error E0061 needs a span_label, updating it from: To: Bonus: the types could be incorporated into the label rather than a note (though we may want to avoid types with long names in the label)
Planning on tackling the bonus here. Is there a prefered max length for output on the console. In the case it would exceed this should i truncate the typename or just not include?
- great point. If you want to work on truncation, feel free to add it, too. I'm not sure if the term crate will tell you the current terminal size, but it may.
I'm fixing and I noticed that it and this issue currently share the same code for generating this error, and adding code to add a to the message in would fix both.
Did you do the bonus as well? I can tackle that if you haven't.
I haven't yet - I can fix the issue (currently testing/fixing unit tests) and you can take on the bonus part of the issue.
Sounds great to me! Thanks.
- I opened up issue to track the bonus portion of the work for you.
Error code: Metadata:
What is the issue you are reporting here ?
Well, I thought that compiler can understand that is related to the block of code, but it fails.
Can you post a minimal reproducible example that demonstrates your issue? Or at least mention exactly what you'd expect to happen and why. Even code that is cfged out is still required to parse successfully.
Let's show you what exactly problem I have. Full code: And I get this error:
You seem to already have posted this a month ago. What you're asking seems a rather big change to me, I'm not that familiar with how the compiler parser works but I believe it currently requires your program syntax to be correct before macros are expanded, which is not true for your example, so some fundamental changes would be needed.
Oh, damn, sorry. I totally forgot that I made a post. Well, if it's not a bug and parser works like this it is bad, anyway, exists alternative way to write like this. But for me my issue is a candidate to feature request or a bug. Anyway, I'm not a lang dev, so I don't know what scales of this defect (?).
The workaround for this is to wrap the expressions in a block:
I solved this issue exactly as you did.
Another way to do this is using the macro and . I personally thinks it is more clear, and should optimize the same.
Work is not the same, due to compile-time evaluating an expression that we pass in it and evaluates only it, but at the same time everything compiles what is inside of .
In the in the section it is stated that (emphasis mine) But the example shows a type parameter on , which requires parenthesis-enclosed type parameters rather than angle-brackets. mentioned on IRC that this might be some special case to open the possibility to easier change the traits at a later time (if I understood correctly), but I found it confusing to see a specialization using parenthesis without ever having heard they existed.
Isn't the text referring to Those angle brackets? "following the function name"
Yeah, I suspect the real confusion here is that the syntax with parens has not yet been introduced (nor is it explained anywhere, apparently), so it's the wrong example at this point in the document, and it's not clear to a first-time reader what is being referred to. It seems like there should be a sufficient example here that doesn't use closures, maybe one simple one with and , and one using traits over collections or iterators or something, to demonstrate that parameterized types can appear in the bounds, to make it easier to understand. That said, the reference is explicitly not intended to be pedagogical, and implicitly not yet expected to be complete.
Want to fix this bug? There are . This github repository does not contain a trademark file, and I am curious if still applies, as it would seem. Debian and some other distributions are applying patches against the Rust language and Cargo package. I assume this qualifies as something which requires explicit approval? If so, removing or restricting packages from Cargo would also be considered a modification. e.g. some distributions may wish to block access to Cargo downloads that are not in compliance with license standards. Just wanted to get some clarification on this as it is not mentioned here in the repo and some folks seems to think that because there is no trademark "here" that rust-lang can be distributed with modifications without approval. I believe the only way such modifications would be allowed unrestricted, is if "rust" was not used at all in the package and it was clearly defined as a rebranded fork that is not affiliated with the official package - Otherwise the trademark policy is still enforced.
This question should be asked at the linked on the Legal page rather than here.
Just received a response. It seems a may be useful to direct people to the appropriate from github. This issue can be closed once trademark notification is included or mentioned on Thank you.
I've tagged this issue as and . To close this bug, we should add a new section to that mentions that there are trademarks on the rust name and logo, and link to If you want to fix this bug and need any help, please let me know, and I'm happy to assist!
Hi I'd like to work on this and opened to add a section about trademarks. But I'm not sure whether I made appropriate wording. Could you please help to review? Thanks a lot.
Any news regarding this ^ Cheers