jiebi/CodeConvo huggingface dataset:
As for me, I'd rather have the feature stabilized (I'm often aiming at devices with chronic lack of storage space), no matter the actual values used. Or is it blocked on anything else beside choosing the right name?
Side note: the crash in only reproduces with -Os (probably an LLVM bug)
Since the lastest LLVM upgrade rustc / LLVM does more agressive ~inlining~ loop unrolling. This results in increased binary size of embedded / no_std programs: a hundreds of bytes increase, or about a 7x increase, in the case of the smallest Cortex-M binary cf. . As we are shooting for embedded Rust on stable it would be great to also provide a way to optimize for size (which is pretty important for embedded applications that target resource constrained devices) on stable. What can we do to move this forward. Can we at least stabilize "s" on rustc? Cargo already allows in the but requires a nightly toolchain. is this (opt-level) being discussed as part of the Cargo profile revamp?
I think those optimizations have baked long enough that it should be fine to stabilize now personally!
The following code : run under miri reports UB:
cc
The underlying issue is in : this has the same error.
This is actually tricky, I think -- an unexpected consequence of the Stacked Borrows rules. When is being passed to , it gets reborrowed and then "protected", meaning the mutable reference passed to must outlive that function call. But then it goes ahead and reads the old reference from directly via the raw pointer, which reborrows that reference, therefore invalidating the earlier other reborrow. There is a sense in which the reborrow of passed to is truly invalidated here -- and in fact it is not possible to access that value later: I am surprised by this error, since usually mutable references are reborrowed, not moved. But it seems here it somehow knows not to reborrow?
cc -- could be related? Fully-qualifying the call with yields a different error (where reborrowed rather than moved), so it seems at least partially related:
Ah, yes that's it. Not that the exact error makes such a big difference, but now at least it is more clear that the reborrow makes later uses of fail.
Type inference will prevent reborrowing from happening.
Could we say that a mutable reference that comes from a type parameter shouldn't be protected?
That seems a bit strange, to have a particular instance of a generic function behave differently than if that same instance had been written monomorphically.
Well, generic function is different from an monomorphic function. In a monomorphic function you can dereference the reference, but (if there're no bounds) then in generic function you just have and would need to treat it "just as data" and the fact it's monomorphized to be a reference shouldn't be special. I.e. I would expect a to behave more closely to or than a dedicated, say type. It is strange to me that two monomorphized versions of the same function should behave differently.
Sure, a monomorphic function can be changed to do more things. But when a generic and monomorphic function are the same in the source code, they also should behave the same. They use completely different types, so them behaving the same does not even make sense? Like, e.g., will literally return different values. In general, two monomorphized versions of the same function have no choice but to behave differently.
STR: run with on a program with a name resolution error. Result: cc (bug manifests in the RLS)
I can take this. I already dug into some time ago, I encountered the same bug when I was trying to write a refactoring tool. To fix the issue, I have to remove all the around there, right ?
great, thanks for digging in. There's likely to be some s that don't need to be there, but it won't be quite as simple as just ripping them out. There will be some error condition that needs to be dealt with.
Note: The regression is valid/"allowed" (there's a hole in the typesystem being patched), I'm just filing this issue now so we can make sure that this regression is tracked in case it got "fixed" by accident. Feel free to close if it's a known quantity; I'm just worried that this got "accidentally" fixed in some other change. My crate is being fixed to not face this problem, but in general there's a chance other crates are falling afoul of this as well; we should perhaps assess the impact and start off with it being a future incompatibility warning if necessary. I tried this code: () I expected to see this happen: It compiles, like it does on stable, or at least throws a future incompatibility warning. Instead, this happened: It errors: It most recently worked on: Rust 1.56.0
This regressed in , which was a rollup. Further testing shows this resulted from . It's marked as being a partial revert, so I'm not entirely sure what the chronology is here. CC Note that we think this "regression" probably isn't actually a problem, per the note at the top.
What the....
Okay so reverting fully also errors. Stable 1.55.0 fails. Checking (a couple commits before ) now, but I'm assuming it's going to error. So, this was actually a bug in 1.56.0 - prior to that, this didn't compile, rightfully. My guess is because of treating unnormalized function args & output as WF, we saw , replaced it with , assumed that was WF, so we didn't actually check that . I'm going to go ahead and make a PR to add a test that closes this issue. This was a bug in 1.56.0, not a regression since.
Good to know, thanks! (And good that this was just a one-version regression; less chance of there being in-the-wild breakage)
I should figure out an excuse to make yoke a dependency of rustc, it seems really good at finding typesystem corner cases and maybe we should just have it be a test
Isn't it failing on the wrong line?
I would have expected it to fail on the because is the thing that needs to match
Haha yeah, it's a thorn in my side So, it's interesting. The check is , which is true. What I might expect here is it to fail because you haven't written (which is required for to be well-formed. But I think this is implied bounds, since this is fine:
In my experience WFness of has always been a bit variable where sometimes you can assume it and sometimes it requires you to spell it out, so maybe this is another instance of that.
Thanks!
We currently emit vec growth glue, but it is called using the push/pop mechanism (e.g. of transcallglue). In reality, the only call site for this glue is generated when translating vec append statements, so it really is user-level glue and need not adhere to the "worst-case glue-call args" max argument count. The fact that we don't do this costs us one extra word of worst-case glue-call args at the moment (7 words instead of the 6 we'd need otherwise). This is a relatively minor issue, but now noted.
WONTFIX (not required for bootstrapping)
This error occurred when running . Should I remove these unused attributes?
What's your ? These should only warn, not error.
This is a part of my which is not commented out.
If you run and check again, these warnings should go away. It would be nice if this wasn't necessary, though.
Thank you for your advice! clean and then build completed successfully!
This happens to me every time I try to do an incremental build after making a change. Is there any other way to resolve this than ?
Let's keep this issue open, because we'd rather not have to clean even single time.
I'm running into the same problem with incremental builds, which makes incremental kind of useless...
I think I am also running into this. I'm going to tag this T-compiler to try to increase visibility
I am also running into this
This is super painful, can this gets prioritized, or could we disable incremental builds until its fixed?
FYI, the following command seems like a pretty reliable way to reproduce this problem:
(assigning to self to investigate)
Strange; part of the problem I have had in investigating this is that it seemed like my manual attempts to run the "same" commands that were being issued by bootstrap would all complete successfully. I think part of the issue there is that the mode for is sometimes hiding information about the commands it runs. To get something that actually reproduced the problem, I had to drop into the "more verbose" mode by passing twice to , like so: and an interesting part about that output is that I saw these two lines right next to each other in the output: The first command listed won't reproduce the problem. The second will. (I suspect its because the first is lacking that that is present in the second.)
Also, setting this to may provide an easier workaround for this speciifc bug than a full clean:
(The aforementioned setting was moved into rustbuild in )
I am getting an increasing feeling that we need to document and simplify the bootstrapping process better...
My hope is that once PR gets into the beta-channel, then we should not see this particular problem arise. I would like to know if anyone is seeing other warnings that are not covered by the cases I handled in PR .
This is fixed now, right?
I haven't encountered it since
Same here. Seems to be working. Thanks
closing as fixed.
Fixed on my end as well, thank you all!
Seeing this one here: ie. I attempted some kind of whitelisting just as you did in PR , but I'm thinking it will only work if I attempt recompilation with a rustc that has that whitelisted already?(which would explain why it keeps failing as if whitelisting it had no effect, ok definitely placing garbage instead of the below patch(which should compile fail) does have no effect which says that it doesn't get compiled before the above fail) Either way, I'm not sure where to Whitelist it, since it appears as too: (notice how the filename moved: is now ) Something extra: If I put in (which overrides the stage0 rust / / ) then it compiles ok the first time(as expected) then if I interrupt it and then attempt (re)compile, I get now:
This keeps happening to me with this:
I'm reopening and nominating for compiler team since it seems like it may be worth discussing to see if there's some principled solution for bugs like this. I think we've seen the last 2-3 releases all introduce at least one case of unused attribute errors in libcore/libstd during incremental, which is not great. Maybe there's some way we can stop tracking the rustc-perma-unstable attributes as 'green' in incremental? That may be too big a hammer though (or maybe too small). At least, it seems worth bringing this up at pre-triage.
This keeps happening to me when switching from to . Very annoying to have to . :(
triage: P-high, leaving nominated in hopes of discussion in a near term meeting.
There is a way of dealing with side-effects in the incremental system. We use such a solution for diagnostics. It could probably be expanded to unused-attributes if there is no cleaner approach.
removing nomination label; I'll follow-up with directly on ways to resolve this. (And/or discuss removing lint with )
Should we just demote to warn-only at stage0? It's getting pretty boring to nuke every time I rebase and something has changed in libstd (looks even more frequent nowadays), and I've heard people say they don't set in because of these "unused attribute" errors, which is a shame.
The compiler seems unable to determine that two types are equal. I tried this code: I expected the program to compile and run without issue, because is , so the call should be fine. Instead, I got this error message: The problem exists on stable 1.42 and nightly 1.44
It somehow compiles if you replace the associated type with a type parameter:
cc /
Possibly relevant rustc log entries: Seems like the will resolve the inference variable to yield , but for some reason is unable to normalize that further.
It seems like the opaque type has a substs with only in it; on first glance I'd have expected the projection there, but the docs on do explain this: So it seems like the is what was inserted for the type parameter, making . I'm not sure why this is represented like it is, but it seems like we need more info to be able to look at the real substs of the opaque type.
Duh, I forgot how opaque types work. Not sure where would be stored (? It's empty at this point according to log), but it's definitely not in the type, so this output makes sense.
This is fixed on nightly.
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. 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! And nominating for compiler team prioritization.
Miri fix:
This appears to be fixed
We fixed it in the Miri repo but have not yet updated the rustc repo for that. Let's keep the issue open until that happened.
Apologies! Where should I check in the future to be sure it's fixed?
No worries. :) You can check the toolstate page: https://rust-lang- (Or you can skip these miri issues if that's easier for you; I think I am taking care of them quite well -- though more eyes and more help are of course always appreciated.)
Thanks, gonna bookmark that. I was going through unlabeled issues which is how I stumbled here.
Hm, we could maybe have the bot that creates them also automatically apply "A-miri C-bug" or so... Cc