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.


It would allow mentioning the range bounds in the error message (or we could do some of the const fn string formatting hacks here of course).
Closing as working as intended. The error message has been improved, and a description of the potential breakage will be included in the 1.54 release notes ().


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.


<!-- ICE: 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.


This effectively means you can't compile for these targets.
This may have been caused by the i128 PR ( ). No LLVM assertion is raised if I compile with , which removes the i128 stuff. We could try to fix this or we could cfg away the i128 stuff for the nvptx targets in the meantine. The LLVM assertions render the NVPTX backend unusable in the nightlies. cc Have you seen any LLVM assertion like the ones above while working on implementing i128? cc cfg?
no, I can't remember seeing such an assertion. It seems to be in PTX related code. but its very likely that i128 broke some of the non tier1 platforms. You can only tell whether they break once they actually do :/ Can you try to generate a minimum reproducible example? Then we might know more...
Seems like the msp430 target broke too: with Using works fine. cc
Examples
msp430 EABI doesn't specify how to return 128 bit values, and LLVM does not support them on msp430, so I don't see an easy fix for this.
These are tier 3 platforms, so basically anything goes IMO in terms of language guarantees. If they don't support i128 at a fundamental level then it seems like if we want them to compile we'll have to cfg out support.
I'm trying to understand this better: If the ABI does not specify how 128-bit values are passed/returned, does that mean that the architecture doesn't support 128-bit values at the fundamental level?Do all the ABIs of the all the other platform 2 targets (x86, ARM, MIPS, PowerPC, SystemZ) specify how 128-bit values are returned?(What about wasm and Do those even have an ABI? How does the 128-bit stuff even works there?) I'm wondering if we should: Add a field to target specifications. For targets that don't support i128 at the fundamental level.Or, maybe add Cargo feature to to cfg away the i128 stuff.Or unilateraly cfg away i128 in core for nvptx and msp430. I personally don't like either option. To me this seems like a limitation in what LLVM can do today but that can be fixed in the future.


Also, if we had pure MIR rlibs this wouldn't be a problem at all because the i128 stuff would never be passed to LLVM if it wasn't being used by the final application. To sum it up, I'm not sure what to do here ...
Right now on MSP430 values from the functions are returned using 4 16bit registers r12-r15. So in total you can return only 64 bits of data. There is an exception though, for returning large structs, the data is placed on the stack and reference is placed in the registers. So I guess it will be possible to bodge some hack that will treat i128 like a struct, but I don't know if anyone tried to implement 128 bit values on 16bit cpu, so it will be a new territory and potentially a lot of work for a feature that may not be useful at all on a small MCU.
yeah, but if LLVM can generate code for a function that returns then it should be able to use the same trick to return an . It's just that noboby has taught it how to do that. (i128 ops are totally different though but at least LLVM should emit intrinsics instead of raising assertions) How about on 8-bit AVR?
AFAIK, if Rust code calls Rust code, the ABI is totally irrelevant. We can do whatever we want. However, it starts getting a problem once we start talking to non Rust places, e.g. for FFI, or when LLVM emits a call to i128 intrinsics. For FFI we might want to end up forbidding fn's and structs that have i128 for targets where i128 is not specified by the convention or buggy in LLVM. With intrinsics, there has been major pain on Windows with because LLVM assumed a different ABI than what Rust provided with . It was "fixed" by introducing the "unadjusted" ABI, and it might work for nvptx64/msp430 as well, but it can just as well still cause an assertion failure. Real need for is only for platforms that want to cryptographic libraries, or maybe even std, as those two places might want to use . The higher stages of the compiler itself require i128 support as well, so if your platform wants to be a host platform for rustc, you'll need to support i128.


I'm okay with any of the three options (flag in , feature for , only setting it for those two platforms) for these platforms.
No. No. Namely the x64 windows ABI is kinda fuzzy about how i128 values are handled so carefully reading it we arrived at a conclusion that they ought to be handled the same way as regular 16-byte structs on 64 bit window platforms. A target cannot not support i128 at a fundamental level the same way a target cannot not support writing turing complete software. IMO what we should do here is to fudge the ABIs somewhat to take and return arguments via pointers (or the same way would be handled) on these targets. C ABI will be more complex; as already said there will always be at least one user of the C ABI with i128 arguments and stuff – LLVM with their intrinsics. The question here is how does LLVM lower to the intrinsics on these targets. If the backend does not lower and asserts for whatever reason, the targets have what’s essentially a broken backend implementation. Which seems to be broken for at least NVPTX () in exactly the place where I’d expect it to be broken if it was broken: That being said, since the C compilers do not support i128 for those targets, the actual interoperation does not matter whatsoever. All that’s really needs to be fixed is LLVM’s lowering of instructions to intrinsics using whatever ABI that works, even if its passing in arguments and taking return value via pointers. I, myself, am very strongly against splitting the language feature sets depending on the target.
How do we break the stalemate? If we submitted changes upstream for each of the smaller targets w/o support for i128 (providing indirection like large structs) it seems like it would meet resistance. As says, it's likely not considered useful since there's many targets without any native registers or support for such large values. But we also also have reluctance to limit this type to only appropriate targets. Does the "vision for 2017 cycle" provide any guidance? Does "provide a more seamless FFI story" help push us in one direction or the other?
regardless whether useful or not, we do need to support i128 on all targets, otherwise people will start using libraries that provide it across platforms.


Even if it needs to be "virtualized" in some way, and not wholly put into registers. In the worst case we'd have to provide some translation before passing things to LLVM, but it will affect things like alignment and generally looks like an ugly workaround. About FFI, I guess we can't really provide any FFI for i128 on targets where there is no C support for it, as generally the calling conventions only specify things that are part of C.
None of the targets Rust supports have native support for 128-bit integers, other than the fact that some can implement unchecked division and multiplication involving 128-bit integer operand with a single insn. Why? All that needs to be done here is to have the backends fixed. LLVM is supposed to be agnostic over bitwidth of integer, however useful or not somebody on the internet perceives such functionality to be. In other words, its a backend bug. So, its probably pretty clear that all it takes is to write a patch to fix bugs in these backends wrt operations on large values. I have no knowledge of these targets, am not familiar with the backends and haven’t the hardware to test any fixes on, so these patches will have to be written by somebody else. Late answer, but I’ve noticed this only now. This observation is wrong in multiple places. Firstly, (a.k.a. returning via pointer) is not a hack. Neither is it an exception. That’s what pretty much every single ABI¹ out there does for values that do not fit into register(s). It is most likely true that MSP430 ABI does not specify what to do with PODs this large, so it falls on us to pick whatever. ¹: For a less obscure example, x64 ABI used by code targetting Windows mandates to be used for any non-vector values over 64 bit in size, even though they could be fit it into registers. SysV ABI starts returning stuff via after some size threshold as well.
The MSP430 ABI specifies that aggregates larger than 32 bits are passed and returned via pointer. The backend just doesn't implement sret correctly yet (and in fact is implemented targeting an old and outdated ABI in any case). I'm working on fixing this in LLVM.


I'd bet that similar problems explain the NVPTX problems but I know nothing about that platform so I can't say that for sure.
I also agree that fixing backend is the right thing to do. I just think that it is not that easy as you say it is. MSP430 is the only 16bit architecture in LLVM, and this creates some trouble by itself. Good to know that someone is working on this.
does that LLVM patch really fix NVPTX as well?
No, it doesn't. this should be reopened for NVPTX.
BTW, thanks to for fixing this in LLVM upstream.
Triage: MSP430 has been fixed. No change in the NVPTX backend.
What needs to be done to get NVPTX working again?
You can see the patch I did for the MSP430 above - if it's the same problem you basically just have to add sret (structure return) support to the LLVM backend. I don't know anything about NVPTX but I'd bet it's pretty much the same procedure as what I did for the MSP.
Note that you can use the NVPTX backend today with the nightly compiler if you use a fork of the libcore crate that doesn't include 128 bit integers. Instructions .
I have some progress on the issue. First, I tried a hacky workaround with replacing with in arguments and return values with a custom FunctionPass. Can be transformed to: And compiled to PTX with vanilla LLVM (): Then, I made less hacky workaround patching LLVM NVPTX backend so it became possible to compile the code with without additional passes. Is compiled with patched to pretty much valid and working PTX assembly ;) But another related problems appears. When instead of: I write: I receive an error: And similar error when I try to compile : Does anybody have any suggestions about the problems? Looks like PTX doesn't have an instructions for the functions, and LLVM can't expand them.
Looks like the expansion from i128 to i64 is going OK but the i64 sdiv/mulo instructions aren't properly implemented. Not sure why that might be... it kind of looks like it's trying to assign the address of a library call and that's not working. Possibly the way you implemented the i128 expansion prevented a subsequent i64 expansion from running but I can't tell without seeing the code.


Run llc with -print-before-all and/or -print-machineinstrs to see where things diverge from what you expect. Look up in your platform ABI what the right action to take for 64-bit divides actually is. Post a link to your changes and someone may be able to take a look at them and see the problem.
Traditionally, in LLVM, is implemented by the library. However, its disabled on most platforms. Not sure why, but is written in C so they probably only can support i128 on platforms where they also provide C support, and clang's C support for i128 is right now very limited. Rust however the function, inside the crate (that is a wrapper for compiler-rt). There are good chances it works already!
It has pretty expected output before and after each pass. I think more interesting would be output with , but I don't really understand it. of the next commands: I tried to make changes over LLVM as minimal as possible: . I'm quite confused about and . Should they be compiled for target or host? If we can build at least for NVPTX, then can we just link against it? It still require some more changes for LLVM to be able to threat libcalls as normal calls. But then, all we would need is to link against . This blocked by but might be solved with my experimental .
For the target. At least its that way on other platforms. What is LLVM doing on 32 bit NVPTX when it encounters a 64 bit operation? On normal targets, this is one of the places compiler-rt gets used. Or idk, to cast a float to an int and back.
by the way, I didn't congratulate you yet for your progress. Really great work, loving it!
I'd like to see this move forward, so I'll summarize the above. Please correct me if I'm wrong: This issue was fixed for the MSP430 backend by submitting a patch to LLVM. worked on a patch to do the same for NVPTX, but it was not submitted to LLVM. I imagine that since that was a year ago, the patch will need some work to bring it up to date. Is this problem still happening with more recent builds? Perhaps it's been fixed by upstream in the meantime.


If it is still a problem, what would have to be done to fix it?
Well, my patch related to landed in LLVM about year ago. Now we can compile simple examples without any problems: with which produces the PTX assembly: And as for me, the issue can be closed. I was able to compile a kernel from  with latest nightly. So the hack with custom is obsolete now.


LLVM's MergeFunctions introduces aliases which can trigger a bug in macOS's linker when compiling with ThinLTO: For this reason Firefox has to be built with a patched version of when compiling with xLTO. Since the bug in question is pretty nasty (the above example shows a program just returning a different value with no indication that anything is wrong), we should probably try to not trigger it. Right now, however, it seems that one cannot even turn the MergeFunctions pass off in stable Rust. (I wonder if the pass should even be disabled by default on macOS?) cc & (this seems related to )
Is it a mergefunc bug or a ThinLTO bug? Can it be triggered without ThinLTO? If not, I would rather not blindly disable it on macOS, at least not when ThinLTO isn't enabled.
It's not a bug in mergefunc. It might not even be a bug in ThinLTO. It's just that mergefunc is the only thing in that generates symbol aliases in LLVM IR, and these are what can lead to "miscompilations" when using the macOS linker.
Has the ld64 bug been reported somewhere?
We could use to prevent the pass from emitting aliases on macOS, AFAIK.
This is already supported via either or in the target spec.
Do you mean that the test case also fails with enabled, or that we already have a knob to disable them?
Answering my own question, we already have a knob for that.
Which was because .
As and point to there is the unstable option which I've only tested on nightly. I guess there could be a stabilized option, but maybe what you really want to do is to patch the x8664 macos target definition (I believe this is the correct one: ).
Yes, I've been told that it has been reported to Apple. On nightly, one can already control the mergefunc pass. On stable, however, one is stuck with the default behavior. That's what this issue is mostly about.
just want to double-check my understanding: I would have thought one could use the options and to override the set of passes, even on the stable channel. Am I incorrect about this? (If I am correct, I nonetheless will admit that this is an ugly (and very fragile) method to opt out of the MergeFunctions pass)
I think that is correct, yes.


It would be rather hard, however, to re-create the set of passes meaningfully, I suspect. Even the compiler delegates this to methods within LLVM, iirc.
I think using might work on stable.
So did that help,
Unfortunately not. Specifying this gives me:


Test case: With rustc 1.20.0-nightly ( 2017-07-06), output when compiling with : correctly stops the dead code / unused type alias warning from being shown, but the trait bounds not enforced warning is shown anyway. Per and , this might be on purpose. I think this is the wrong decision. The point of is to allow Cargo to inhibit warnings in external dependencies. When building Servo it is not useful to spam the console with many warnings, future-proofing or not, about code that Servo has not direct control over. CC
Nominating for discussion. Not sure if compiler team or lang team is best, though, so tagging both...
From the lang team's point of view: definitely a bug.
Couple of bugs here: First off, we should not be ignoring the bounds in types. And sometimes they are needed. I'd like to fix this by not ignoring them, but I worry about the backcompat issues. Unknown risk there. Second, if we must warn, we should be emitting a regular lint that can be silenced. Plausibly, we should just remove the warning (eliminating the immediate problem), and prioritize trying to do a proper fix here.
Somewhat related to not ignoring bounds (but in the other direction): .
After some discussion in compiler team, decided to move this to a "future compatibility" lint, one that we will hopefully make more precise over time. Right now the check is not very good. At least this means you won't have to see it. We need some mentoring instructions though!
Some tips here:
triage: P-medium
I've hit this recently. It seems like it is possible to write code that requires exactly this bound. So it is quite bad that we cannot suppress this warning. Example code:
Agreed, this is poor. There just hasn't been a lot of energy to try and improve the situation.
Fixed in , probably by We should add a regression test for this particular case before we close this issue however, since I don't think the test in the PR detects a regression for the problem described in this issue. The problem in this issue is output on stderr, not that compilation fails ( exit code is 0 both with and without the fix in the PR). label E-needs-test


<!-- 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
I suspect this is related to cc
tests/ui/suggestions/unnamable-
Very likely. I'll take a look soon.
For the record: it was that caused this.


Rust PR: This feature adds the following methods to : -
Anything in particular holding up the stabilization here? The implementation is trivial and docs lgtm.
I would like to add methods that return an exact , but that can wait.
These methods are a little odd, but seem reasonable to me following the example given:
Given how straightforward these methods are, I don't think there's any problem stabilising them?
They're straightforward in implementation, but conceptually tricky at a glance. I think the docs will need some fleshing out before stabilizing but I don't have any other concerns if somebody wants to write a PR!
This needs more testing with various interesting values that could produce interesting floating point numbers, and should not be stabilized without such.
tests were in this PR


It should work a bit like IDE's feature that finds everything that implements a given interface.
This should be a fairly small change (the most annoying part has already been done) so i'll open this up as a mentored issue. The bit that writes out the "Implementors" section is in . This is where the known implementors for a given trait are pulled out of the global context and listed out onto the rendered page. The bit that's responsible for creating links is , implemented on a local type. This kind of Item is easily made from the kind of Item that's otherwise worked on in , but there's a catch: The entries in the Implementors list aren't s. They're s, which are only a subset of the things you get on an Item. This is the "most annoying part" i mentioned earlier. Fortunately, i ran into this when creating the "Implementations on Foreign Types" section, so if you scroll up a little in , you can see so i could render the full impl block for them. The task for anyone who wants to take this on is to pull that up a little so that it's used for all the implementors, not just the foreign ones. With a in hand, combine it with the Context to create a and call to generate the link. ( This also helpfully includes the extra HTML bits that will flush the link to the right edge, which is really the final step.) And... that's it! The link should probably go between the and the where clause underneath it, so that it's aligned with the impl line and not the where clause. You may need to also close/open the that's wrapping the whole line to make sure the link itself isn't monospace. If you have any questions, let me know! Either comment here, or hop onto IRC in , or the impl period Gitter under .


On nightly (and beta I believe) the compiler will currently fail when cross compiling from x86_64 to x86 (after ensuring the standard library is in the right location) with the message: I believe this is a regression from and , which were backported, so I believe this is a stable regression. That being said I doubt anyone other than Cargo CI is doing this, so it may not be that big. I also believe that is working on a patch, but this should help track this issue.
I have been doing this with ring and ring-based projects for many months.


This issue is a proposal for the deprecation of error code . I opened a PR () as part of an effort to add long error explanations for error codes that didn't have one (). I chose and for my erroneous code example, I used the example from . I quickly realized, through running the example and other code that would also raise and through the CI failure message, that was not being raised. I went back to consult the issue I received the original code example from and noticed comments about not occurring anymore with . The issue was eventually labeled with . But, looking at the current contents of the file, can still be emitted even while it isn't: also doesn't have any UI tests as it is part of the error codes in . Since , is no longer actually emitted (although it is in code that it could) thanks to , I believe it should be deprecated. I would be happy to help deprecate the error code, if it is decided that it should happen. I would just need to know the proper steps to take to deprecate an error code. If there are reasons for why it is still an error code, I would love to be enlightened. claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
If is not emitted anymore then it can be removed immediately. A crater run can also be done to ensure that this is the case. I'm also happy to do this if you want.
Sure, that sounds good.
Sorry just for clarification, do you want me to do the PR or you?


The following program compiles, and prints :
As pointed out by on discord , this also works on stable:
Regression introduced in 1.40.0, specifically this line:
I have a fix in


<!-- 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: I expected to see this happen: Compiling with , after the emsdk is activated and emcc works, to compile properly Instead, this happened: Prints this error: I've tried adding to no avail <!-- 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
runs successfully
Also is broken on ubuntu with the same error message (at least windows subsystem for linux)
rustc 1.53.0-nightly ( 2021-04-24) emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 2.0.12 () Here's some info I gathered: Rust tries to . I think Rust is assuming that this symbol comes from emscripten. emscripten has a : libc++abi.a: emscripten exceptions: this is what rustc is trying to use; libc++abi-noexcept.a: no exceptions: does not compile libc++abi-except.a: wasm exceptions: experimental; in emscripten's repo shows that was never compiled into libc++abi.a by This commit looks suspicious: Prior to emscripten SDK version 2.0.10, I think has been and never did anything. Rust probably shouldn't be calling a stubbed function. seems untested if you ask me because I don't know how it could ever have worked. I successfully compiled hello world with emscripten SDK version 2.0.9. That version still has the stub.
label I-prioritize T-compiler O-wasm
thanks for the analysis. Assigning priority as discussed in the of the Prioritization Working Group. Let's find someone who can have a look at this. label -I-prioritize +P-high +I-nominated
I recall with the LLVM 11 upgrade, the compat notes mentioned which version of Emscripten to use when compiling with the target.


Once this bug is resolved, can we add a similar note for the releases that upgrade Rust to LLVM 12?
As mentioned the panic=unwind strategy is broken on wasm32-unknown-emscripten. I recommend to switch default to panic=abort. Note that also rust std lib has to be rebuilt with panic=abort to fix the undefined symbol errors. Testing on my side showed that the problem could be fixed by changing TargetOptions on line 38 to "panicstrategy: PanicStrategy::Abort," in file. Unfortunatelly I do not have experience in preparing pull request and have no capacity to get into it now.
This issue can be solved by setting the env var which will override any flags passed to emcc. See this comment - Passing these flags using the won't work, as they are not passed to the linker. I received this error in two places, one for symbol and one for , hence the flag.
Reported this on Emscripten:


<!-- 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
probably Regression in searched nightlies: from nightly-2023-02-15 to nightly-2023-03-16 regressed nightly: nightly-2023-02-20 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
It's actually
Or at least, the logic broke because of , so the ICE message probably changed in that PR from some other message, to this one in the title.
label +S-bug-has-mcve


Some people were of the opinion that this shouldn't work, but it currently does. : cc
cc
it's just super scary. EDIT: it should not and does not work. If we allowed this, various surprising things can happen, especially around implicit promotion. If you want to store pointers and integers, you can use a raw pointer.
For my own education, can you elaborate on why function pointers are ok? I'd thought that the runtime addresses of things -- including functions -- shouldn't be accessible at const-time since we don't know where they'll live at runtime. Could I make a const array that usize long?
When compiling to LLVM, the real function handle or pointer address is obtained. If you try doing anything weird with pointers at compile time, you will quickly notice that you are not at runtime. For example, you cannot divide such a usize by anything. You can add or subtract integers, because that's just pointer offsetting, but you can't inspect the address in any way. This also means that no, you cannot use this usize for array lengths or enum discriminants. This is due to the fact that miri pointers are not just addresses, but abstract pointers that are in a separate layer from the bytes of normal memory like the one of integers.
Thanks for the explanation. I guess that means that such a couldn't be passed to a const generic either?
The thing is const generics don't know where the usize comes from, so they could try to do something with it that is not allowed if it is just a pointer address. Until monomorphization we can't know if there is an issue. Note that converting a pointer to an usize and back just to be able to put it in const, statics, or use it with const generics, is a real pain. We would be better off in this case with an type, such that I can write and avoid the conversion to usize. For const generics, C++ accepts function pointers at the type level and that works just fine with clang, so I expect to work fine as well.
How would work? is disallowed but and work? that seems very weird and special cased (especially for fn types that involve higher rank lifetimes, as in my example) or is ~= ?


then is a double indirection and to use it you need to worry about managing the memory it points to (which contains the )
I haven't thought this through beyond having used the atomic pointers in the C++ standard library: One way to implement this could be where we provide blanket impls for , , , , , , , ... or use some compiler magic to achieve a similar effect...
This is a bit offtopic, but regarding , mentioned at least once the possibility of introducing some new type, to make sugar for . I guess it can't entirely be "sugar", because of existing impls, but at least both could work the same.
Hehe, this is cute. :) And I agree it is working as intended. (Nice that the translation to LLVM actually gets this right, should there be a testcase to make sure it stays that way? :D )
So... other than testing this, all we need is a PR that adds -casts in constants under a feature gate (and makes those casts unsafe in constants and )
I've opened to brainstorm how to either add an type or retrofit to support items.
These kind of operations are now unsafe in contexts (impl PR: )
So do we have a test that you cannot use such usize as array length? :D
hmm... apparently not... Test-instructions: (via the feature gate) to turn various kinds of references and function pointers into these expressions in array length, repeat lengths and enum discriminant initializers (e.g. ) Note: Do not use items, everything needs to be inline in the use site to be properly tested
this is no longer allowed by any means:
Yes that is intended. This issue is for adding a regression test testing what happens when you use a pointer casted to a usize in an array length.


The following panics: The following works: Apologies in advance if this is intended behavior.
I have found that it also works when using:
This will be fixed by


<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed'', 'thread 'rustc' panicked at 'assertion failed'' File: --auto-reduced (treereduce-rust): <details<summary<strongoriginal code</strong</summary<poriginal: </p</detailsVersion 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 nightly-2022-02-02 found 9 bors merge commits in the specified range commit[0] 2022-01-31: Auto merge of - spastorino:fix-perf-overlap-mode2, r=nikomatsakis commit[1] 2022-01-31: Auto merge of - tmiasko:is-self-recursive, r=ecstatic-morse commit[2] 2022-02-01: Auto merge of - WaffleLapkin:rustcmustimplementoneofchecktarget, r=nagisa commit[3] 2022-02-01: Auto merge of - eddyb:diagbld-scalar-pair, r=jackh726 commit[4] 2022-02-01: Auto merge of - ehuss:rollup-9ecozo9, r=ehuss commit[5] 2022-02-01: Auto merge of - thomcc:chunky-splitz-says-no-checking, r=the8472 commit[6] 2022-02-01: Auto merge of - eholk:disable-drop-range-analysis, r=pnkfelix commit[7] 2022-02-01: Auto merge of - matthiaskrgr:rollup-f7dkn3p, r=matthiaskrgr commit[8] 2022-02-01: Auto merge of - yaahc:Termination-abstraction, r=Mark-Simulacrum ERROR: no CI builds available between and within last 167 days
Actually reduced
Might have been caused by
Ah yes, the assert was there ping :)


<!-- 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. --Explicitly giving lifetimes to with and doing the same on does not fix the ICE either. Version
label +S-bug-has-mcve
Triage: Fixed on the latest nightly, labels: +E-needs-test


and all interfaces directly with the file-system should probably use rather than trying to coerce to handle these cases. (Similar issue to .)
nominating feature-complete
Accepted for backwards-compatible
My last referenced commit is a month old, but I'm still working on this issue (currently finishing up the support for Windows paths).
The issues here of dealing with filesystems that are not utf8 seem related to , at least tangentially.


was re-stabilized in 1.53 after being backed out of 1.51 due to breakage, primarily in the lexical-core crate. This breakage has not been fixed, as far as I can tell, in a vast majority of crates: we're still seeing ~1300 regressions, majority of which are lexical-core in the . There was no discussion on the re-stabilization PR as to whether this level of breakage is acceptable. Comments on the original breakage issue suggest that 0.7.5 was published with a fix, but older versions (0.4, 0.5, 0.6) did not receive similar treatment. The majority of the breakage is in crates locked at 0.7.4; the other versions do share ~400 different crates amongst them, so I think it'd be good to try and help get those series patches as well.
cc Even with 0.7.5 out, it does look like it'll be some time before crates actually update lockfiles (if ever). We don't have a firm policy on whether cargo update being sufficient is "enough" that breakage is OK -- it's a new decision each time pretty much -- but this level of breakage is pretty bad. I guess there may not be much we can do -- IIRC a prelude trait for example adding BITS wouldn't help here, right? Those still introduce conflicts IIRC.
There’s no way around the symbol collision. I think it’s important that stabilize and I’d like us to get out of the way on that. I can take the list of broken crates and start walking it. I can also work on a backport on the older minor series; the reason I did not do so last time is that I was unfamiliar with ’s dependents and didn’t know whether the older series were still in use. What is the most complete course of action we can take to clear for stabilization? Should I yank the conflicting versions in each minor series? Alternatively, would it make sense, and is it even possible, to stabilize only in ?
I wouldn't worry about filing pull requests with 1300+ crates bumping lock files (in part because those are unlikely to get merged quickly). I do think getting patch releases out for each series would already be a significant step forward.


I think yanking is likely not the right step to take at this time. In terms of stabilizing only with - no, that's not really possible. In theory we could stabilize with a different name to avoid all the breakage, but I doubt there's a great name...
The constant would have to be available everywhere, and stable everywhere, but one could think about adding a syntactic hack to interpret the syntax differently depending on the edition, similarly to how it was done for . That would have the desired effect of avoiding breakage on editions 2018 and before, but I'm not sure it's a good idea to double down on adding such hacks.
Attaching it to an edition would not only require compiler changes, but also a lint, a suggestion for rustfix, documentation, etc.
Indeed. Such a policy would be useful. If the decision is that that's fine, we might want to make crater update the lock files when something fails before it considers a crate broken. As another data point: also ignores the lock files and picks the latest matching version of everything.
I assumed the edition route was an infeasible idea but hey might as well get a “no” in writing. I’ll start cutting fixes for the minor series listed in the regression report this weekend.
Thank you! Let me know if I can help.
I'm wondering if we should have a in (just like ) that will make Rustc consider everything that was stabilized in a later version as still unstable. could add it to the uploaded crate if it's not explicitly set, and it makes it easier for crates to track an explicit MSRV.
did you get a chance to release new patch releases on each of the channels to avoid this breakage for the lexical crates, at least? I believe that was the plan but I haven't seen updates on this issue at least :)
Hi; I am so sorry for the radio silence; I have had quite the month since then. Fortunately, Alex Huszagh already did the patch-release issuance back in April. versions , , , and all appear to have the necessary disambiguation in place. These versions also do not appear in the regression report from Bors. I've also run on each of these releases with and passed, so these tips ought to be correct when the constants stabilize. I hope day-before isn't too late and I apologize again for the delay.


If you're comfortable with a "run to un-break your project", then is ready.
No worries. We are planning to move ahead with a compat note indicating cargo update.
Just an FYI: this was fixed ~2 months ago, with , , and . It means that any branch used in the wild should be able to be updated to a compatible version now.


I have this crate layout: src/ parent/ where is an empty file and is: This compiles successfully and we end up with a module at backed by the file But if goes anywhere near a proc macro, it no longer works. where is this macro: The error is: so it is looking for a file corresponding to as though the were not contained inside of . I hit this while working on The same problem does not occur if is defined as a macro_rules macro. Mentioning who may know what is going wrong or whether there is a simple rustc fix.
I never audited the module search code and don't know how it fits into the larger macro story. Even without macros it's , so I'd expect issues in macros as well. I'll investigate.
Still the same behavior as of rustc 1.40.0-nightly ( 2019-10-01).
It's still in my queue, just not with a high enough priority :(
This was fixed by , I'll add a test.


Unicode is released on a yearly basis, so we update the data files we used accordingly after each Unicode release in the Rust project. (Keep in mind that new dependencies might be over time.) Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label. Goal: Unicode 15.0 (year 2022) [x] Updating : [x] Verify whether each crate is Unicode version dependent and add support for the new Unicode version in compiler dependency libraries [x] Bump dependencies and ensure updated version is used in [x] [x] [x] (Decide whether it's a valid identifier) Current: 0.2.2 (Unicode 13) Goal: 0.2.4 (Unicode 15) [x] (Preprocess identifiers for equality) Current: 0.1.13 (Unicode 9) Goal: 0.1.22 (Unicode 15) [x] (Decide whether lints against unwanted usages should be triggered) Current: 0.0.5 (Unicode 13) Goal: 0.1.0 (Unicode 15) [x] (Used by for script detection) Current: 0.5.3 (Unicode 13) Goal: 0.5.5 (Unicode 15) [x] (used by , and many others) Current: 0.1.8 (Unicode 13) Goal: 0.1.10 (Unicode 15) [x] (used by ) Current: 0.1.0 (Unicode 15) Goal: 0.1.0 (Unicode 15) [x] Removed: [x] Removed: [x] Removed: [x] Removed: [x] Removed:[x] Verify whether each crate is Unicode version dependent and advocate support for the new Unicode version in dependency libraries [x] Bump dependencies and ensure updated version is used in [x] [x] [x] [x] (used by then then [, , , , , , , ]) Previously: 0.3.4 (Unicode 10) Goal: =0.3.


10 (Unicode 15) [x] (used by ) Previously: 1.9.0 (Unicode 14) Goal: =1.10.0 (Unicode 15) [x] (used by ) Mentioned above in compiler diagnostics section [x] Removed: [x] (used by , then [, , ]) Current: 2.6.0 (Unclear, No release in 3 years) Goal: =2.7.0 (Unicode 15) [x] (in-tree maintainence tool): Unicode version independent [x] : Unicode version independent (used by tool) [x] : Unicode version independent (used by , then ) [x] , , , : Not really Unicode version independent but we only use Unicode version independent part. They're outdated, current: 0.9.1 (CLDR 37, Spring 2020, ~= Unicode 13), would be nice if a new release is used.
is , which is updated with the libcore update (or more specifically, this year it needed no update). is handled by
I happened to notice this in the UCD spec It seems that as of 15.0.0 have to start parsing some of the comments to look for decls now. This is pretty annoying and will likely lead to some bugs (likely minor). I'm certain I've written code that would be buggy under this. (Hell, I'm not sure I've ever seen code that handled these, and I've read a good number of UCD wrangler scripts -- usually it's just to say "assign the obvious default value to anything that doesn't get specified", as in the line above) It looks like the only files in UCD that take advantage of this (e.g. use it several times to define a full range as having the obvious default case) are , , and (note: this is just the UCD, and I haven't checked stuff like the UTS39 security data, though). This doesn't include anything we ship in the stdlib AFAIK, but almost certainly impacts some stuff in the compiler (in probably minor ways, if it's limited to the above). I suspect the argument is folks we were always doing this wrong if they ignored it though? Oof.


CC (since I suspect you know more details here, and even if not, I believe is yours), (since I noticed it while adding something to ucd-generate, presumably there are a few things in that might be impacted if you update its tables)
This seems like another reason for us to potentially switch over to ICU4X (maintained by Unicode), potentially with unicode-rs (or somewhere) maintaining crates of data output. Unfortunately it's unlikely will move to something heavier than the unicode-rs crates which have always stayed zero-dep sicne they're at the bottom of many deptrees. I don't have time to fixup unicode-width but would be happy to accept a patch.
I think rustc doing that is probably very good. It's hard for me to imagine anybody fighting you on it. For the tables... presumably you mean inside the table generator (definitely we couldn't add a dep to libcore on icu4x). We could use it to query the data we build the tables with, instead of ucd-parse. That doesn't sound like a problem eventually. (I'll look into it soonish since I'm messing around with Unicode table generation again). For the ecosystem at large, I dunno. I suspect it will be a tough sell, due to compile time, binary size, and overall heavyweight dependency trees already being in the most common complaints.
Yeah for the core unicode stuff it'd probably be best done as a table generation. Worth noting though: you could still use the efficient code point trie impl that ICU4X uses for this, and not take on too many dependencies. Note that ICU4X's model also involves running a data generation tool; so it might not be an improvement over ucd-parse for us. Eventually, ICU4X will have a copy of various slices of data on a CDN, and then it would be an improvement over ucd-parse. The only difference right now would be that ICU4X is much more likely to update quickly to the latest unicode stuff over ucdparse, but that may not be a huge deal since ucdparse doesn't need much work. I wasn't really thinking about the ecosystem at large. I'm fine continuing to maintain unicode-rs, I just don't have that much time to devote to it.


Overall rustc and other users tend to make PRs when they need them and that works out fine. FWIW, ICU4X is very much optimized for binary size.. Perhaps not compile times, but it does tend to produce small binary sizes (and it's shipping on embedded devices already). I'm not really pushing on us moving to ICU4X yet (I think is investigating a bit though!), I think the status quo is manageable, but it's definitely an option on the table!
I don't think I have any strong opinions. It seems like could be updated to handle these declarations without too much trouble though? And then things would be fine? Or is there something else I'm missing? Also worth pointing out that the whole stuff is something I built for lack of a better alternative at the time. My goal was to get rid of an ever increasing pile of bespoke Python scripts. But I don't have much vision beyond that, other than keeping it "simplistic" and framing it as a "kitchen sink" of sorts. I've also updated 's README to link to ICU4X (wording changes very welcome):
Oh yeah to be clear, no shade on ucd-parse and ucd-generate! They're great tools and I don't necessarily mean to say ICU4X is much better or anything. Rustc already needs ICU4X for list formatting and was investigating using it for more things like the XID and security properties (which rely on those manual python scripts).
I can't make heads or tails of the declarations. From what I can tell, they're mainly being used to apply property values to... unassigned codepoints? Just looking at the diff between Unicode 14 and 15 for , this text was removed from 14 and replaced with declarations in 15: So it seems to me like parsers of UCD that ignore in Unicode 15 are probably still just as wrong as they were with Unicode 14? The Unicode docs do a really terrible job of even explaining what is supposed to mean and why it even exists at all. The only explanation of what they actually are seems to be the first sentence of the section you linked: Most of the rest of that section is documenting the format. The key thing that's missing from the docs is what actually is and why it exists.


Like... why does there need tobe a mechanism for defining default values for ranges of codepoints when the files themselves are already defining values for ranges of codepoints? Something is missing from my conceptual understanding because I don't understand why the declarations aren't just converted into normal lines in the data files.
I have some guesses as to what the answer is but I don't want to say something incorrect, so I've just asked these questions to the Unicode people.
I'd like to hear back from contacts in case I'm mistaken (or missing some detail), but I'm confident I know what they're for, and have thoughts on them in the context of a low level library like . These exist because several of the UCD files do already require special handling for missing values, but it's not usable in a programmatic manner and needs hard-coding. I believe the goal is that for properties that have lines, you can now determine the property values for all codepoints using just the data programmatically readable from the UCD, without reading the documentation of that property. Here are most of the interesting cases I've found for this (some of which are more useful than others), which should give you a good idea of why it exists and why with very complex defaults, like . I believe this is intended to replace things like . Presumably this list in 's source should have have been getting updated to synchronize with the comments in 's header on each Unicode version update, but that comment didn't really indicate that it was going to change, so that was not happening. Now, these are in lines, which allows that to happen without manual work. I don't know if it changed before now (some documentation hints that it did), but I'd weakly recommend to the Unicode folks that when it changes, the and files are also changed to contain tests that fail if the updates have not happened. That may already happen, but that's really the only many people know if their parsing code is wrong for something like this. with a single default value. In most of these, the default is listed in that property's documentation (or prose in comments in the file) and is kind of the "obvious fallback" (often , if that's a value for that property). Now you can read line to determine that the default for is , that defaults to , or that defaults to , and so on.


An odd case here is that the empty string is spelled , but given that that's only used for a property whose value is a codepoint (and not an enumeration), it's unsurprising that it has a special case. , boolean properties which default to and only contain UCD lines when they're . There are a few of these in the normalization properties, and it is probably only useful for code that wants to handle things super generically, but that's something. that default to the codepoint itself, such as is the codepoint itself. Previously, you just had to know this (it's kind of obvious if you think about it, though), but now a line can be used. that default to the value of another property. For example, the has . This codifies that the default value for the property is the value that codepoint has for the property. There are some annoying things about this: a user of a library like (but definitely not for something high level like ), I might want to distinguish between "this is a value explicitly from the file" and "this is the default from ". This is generally true for several of these, but especially true for a few cases like , where I may want to be handling values entirely separately. Obviously a high-level library for Unicode properties would absolutely not expose this distinction, but for something which is explicitly for parsing the UCD files, I suspect including values should be optional (even if it's done by default). now, the property value will often use a different property alias than is used elsewhere in the file. For example, a line for EAW uses , whereas the file uses . Similarly, uses / in but and in the file. Most of these use the "long" form of the property value in the line, and the "short" version in the file itself. I can see the logic here, but it's annoying, as to handle this fully programmatically, you need to read . 's incomplete and completing it feel like it might be a bit annoying. For example, still has "All code points not explicitly listed for Case_Folding have the value C for the status field, and the code point itself for the mapping field" which is not reflected in a line. Given that this is not a single property, it will probably require a special case for the lines.


's also not clear which of these are "stable" values you can rely on, but I presume the answer is "technically none of them, but in practice it's probably safe to assume something like on a derived property is unlikely to change". That said, overall it's probably a good thing, but the release notes for this definitely ignores many of the reasons why this might be a bit of a pain in the ass to handle.
TLDR: they make the files more maintainable and easier to read comments for
Some more background from Asmus, including some explicit steps on how to handle them. They brought up an interesting point that the order of parsing them matters a lot.


<!-- ICE: Rustc '' 'error: internal compiler error: no resolution for an import', 'error: internal compiler error: no resolution for an import' File: --auto-reduced (treereduce-rust): <details<summary<strongoriginal code</strong</summary<poriginal: </p</detailsVersion 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: --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
regression in cc
I believe the root cause of this issue stems from the changes I made, so claim


Example: CC: ,
The error is emitted from . Adding does enable the example above. Interestingly, no terminator appears in the MIR for that function. This suggests that we are running const checks before a cleanup pass that removes terminators for exhaustive expressions. We have a few choices here. I am leaning towards just removing from the checks. What do you think? cc
Let's gate the removal on for now to make sure we don't accidentally allow anything on stable.
Oh yea, I just left it in there so we don't accidentally allow something. I couldn't figure out how to trigger it, so I preferred to deny it.


No response No response No response
(for compiler people:) We could fix this by merging the impl WF and coherence checks into one compiler stage. I'll put up a PR and see what T-types thinks.
labels +AsyncAwait-Triaged We discussed this in a WG-async meeting and are deferring to the resolution suggested above. He noted that this is a fix to the diagnostics only. That fact that this is an error is correct.


More information on
To be clear, I'm not actually sure that's a private link, I didn't look at it in detail. It might just be doc(hidden) or something.
I didn't either. Just that most of weird things happening are in .


I forget if there's already a bug on this, but it would be nice if, when you wrote and doesn't have a field named , but does have a nullary method named , the compiler gave a hint like "did you mean to write ?" It could also do vice versa (if you write A.B()ABA.B?) I ran into this in trans, where I have frequently written instead of .
Test: The error message is better now than it was: in that it suggests there is a method named . But it could still be improved. (The intention may not have been to take the method's value; it seems more likely that the programmer thought it wasn't a method at all.)
My previous comment still holds. It would be great if you would see the "try writing an anonymous function" hint for something like and instead see a "did you mean to write ?" in situations like this one.
I'd also like to see one when trying to call a function-typed struct field: emits Foof. It'd be nice if it tried to see if it could auto-deref to a struct field, and if so, say (f.f)().
A nice idea. Assigning P-low.
Currently gives which is pretty close to the proposed behavior. Replacing the wih yields the same as before (i.e. does not suggest removing the ):
Updated the example gives: which now prints It's nice that the note is there, but the text is suboptimal: isn't a function.
I'm working on a fix for this, but I'm struggling with the final portion. With this code: I get the output: My current changes are . I'm not sure if it's possible to have the output say "" and "kitty.x" with the input to the function. Any ideas? Or should I just keep the message in the same format as it is now and output "s.func" and "did you mean to write ?"? Edit: Ideally, I would like to output: I'm wondering if that's at all possible, especially because instead of , there might be an expression.
I got around that error message. Now I'm making sure the previous message is displayed under the proper circumstances.


Uninhabited variants should ideally be irrelevant to the representation, just like in enums. As a test, this prints out 0 instead of 8: This happens because rustc considers unions more like structs than enums, and the sees a single variant with two fields, one of which is uninhabited. I have a fix for this, but it's slightly easier to bundle it with some other changes I'm working on.
This becomes a problem when making an array of unions: The above code represents a regression (prints 42 on stable, garbage on beta/nightly).
I didn't realize it was a regression to beta - in that case I'll put up an independent fix so that it can be backported if desired.
Although I can't trigger it on the playground, you code is actually triggering an ICE for me: EDIT: I bisected the ICE to somewhere between "rust 1.23.0-nightly ( 2017-11-25)" and "rust 1.23.0-nightly ( 2017-11-26)".
cc
I put up a PR to fix this, but I'm still confused about the ICE (which I moved to ).


<!-- 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<strongSample Backtrace</strong</summary<p</p</detailsThe original code () is already fixed by , however some other mutations of the original code still ICEs with the same backtrace and error. Thanks. <brCC <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
If the parsing error is not needed to manifest the issue, can that be fixed () in the MCVE you provided? since more error messages just obscures the underlying ICE that needs to be fixed here.
(also this could probably use a more descriptive title that reflects the ICE, and doesn't just point to another issue, but that's just my opinion)
Is that better?
claim


Currently, the beta binaries are only present in ; has only the standard library, not any binaries. That causes two issues: doesn't work with stage0-sysroot, meaning there's no way to change the standard library and use those changes at runtime without doing a full stage 1 build doesn't work. This is very rare to want to do, but can be useful when modifying the process itself, to avoid long compile times. Copying the binaries into stage0-sysroot is an easy way to fix both problems at once. Mentoring instructions: Add a call in which copies the whole directory from . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
We should also consider renaming to something else; the name is very confusing.
claim
The name is correct though. It is a directory you can pass in as argument to rustc.
so is . I'm not saying the name is wrong, just that it's ambiguous and not intuitive. Honestly I would rather rename all the directories to and change to or something.
is confusing too as already has a libstd. Just one from the bootstrap compiler rather than compiled from the current source.
Ok, then maybe :shrug: nearly anything would be less confusing than just appending IMO
Maybe rename stage0 to bootstrap and stage0-sysroot to stage0, matching stage1-...?
is confusing with the artifacts for , but maybe would work, keeping stage0-sysroot as is and renaming stage1 to stage1-sysroot
Reverted in
I actually wanted to recommend something like this as an alternative std benchmarking workflow. Currently I have to suggest a stage1 build.
I meant is very rare. I agree wanting to use a stage 0 toolchain with just the libstd changes is common :)
do you know when you'll have a chance to follow up here? If you're not planning to follow up, can you please release your assignment on the issue?
Sorry, I didn't follow this item recently. Ok, release it now.
claim I would like to take this issue up [with a bit of mentoring :)] if that's alright. It's my first time contributing!


thanks for looking at it :) the first step is to cherry-pick the changes in to the latest master commit. Then you'll need to fix the bug Mark mentioned in , which I believe has some more details in https://rust- I think it's enough to copy the user-provided over to . Feel free to ask questions here or in https://rust-
It was mentioned that reverted this so I am reopening this unless someone can point me to the, er, revert of the revert?
Useful Links and Points for anyone who wants to work on this: Initial PR : Revert of the Initial PR : Attempt 2 : Revert of attempt 2 : If I am to understand correctly, the revert of the revert was rejected mainly because rust perf () broke. For anyone working on this issue again, here's a point to note: Just copying the entire parent to will not work as pointed out by in zulip as, suppose the rustc is installed in and you try and copy the underlying parent dir which would be . That time, will get all the binaries in . This will however work when the installation is in something like :
My suggestion would be to re-land almost as-is, except with this feature disabled when a custom is set.
claim I'll give this another shot then


The problem is that the configure script assumes that all keys are in a section and there are no top-level keys. This forces people to use instead: We should make it possible to set top-level keys through , both and . We should also update the line in the readme linked above to suggest instead of printf. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Mentoring instructions: look around I think the fix would be something like .
In the , from where exactly do we get the top-level keys? from the set function?
I'm not sure off the top of my head. How could you find out that information?
Hi are you still working on this?
do you think it's okay to unassign ? This issue is blocking as well.
Since there's no response from the assignee, I think you can take the issue. Are you still keen on working on this issue?
Yup I am interested! claim
Hi and thanks for mentoring! Assuming I run , I think will be 2. So I am not sure if this path would work. It seems like the first blocker is that does not contain or as keys. Should the approach be to expand with those keys? Or should we just allow / as special cases? I am guessing it's closer to the latter, since that might affect the definition of which searches for . Finally, I am a little confused what top-level keys mean - do they exclusively refer to [, ] ? Are there more?
I am able to expand when parsing to include and but I realise I may either have to make changes to or write a new method. Before I do that, I would like to understand how the configure script is commonly used. Could you give me some sample commands, say if I want to modify the field of llvm?
Shall we refactor the 2 top level keys under a section? this makes the parsing logic more consistent and unwieldy lol
you can take a look at for a complete example of what a configuration could look like. I think that would resolve most, if not all of your queries(: Hope this helps!
try running
Got it, thanks I put up a PR. This is kinda my first PR so would appreciate all the tips and advice!


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.


This should not compile, since is for some non- and thus will contain as well. It compiles fine however and results in the varying output depending on the optimization level (which shows that this is an UB out of the "safe" code). Tested with and playpen.
A more self-contained example that shouldn't type-check:
It seems that this has been possible since generalized lifetime bounds went in.
Huh. This was supposed to be fixed. I'll take a look.
P-backcompat-lang, 1.0
OK, simple oversight. PR coming soon. Amazing we have no test for this. It occurs only with coercions. (In general, this code path could be cleaned up, and will be as part of implementing generalized where clauses, making these kinds of oversights harder to do.)


These two errors, which I believe are related, have started happening with rustbuild recently. I think the second is sometimes caused by the first after trying to avoid cleaning out everything; but since this is all nondeterministic from what I can tell I've included it in case it helps diagnose the problem. cc
A few more lines of potentially helpful information:


Before the recent changes to rustbuild, when changing , it has rebuilt the entire stage0 artifacts and thus the entire compiler. Now its only doing: Later on, you are getting an error like "found possibly newer version of crate which depends on".
cc note, I'm not using any --keep-stage stuff or anything.
workaround is to do manually
I think this is the same as (or that's the same as this), haven't had a chance to investigate yet. My guess is that this is a regression from
yes I think its the same issue. If you are closing dupes, then please close the one that was filed later :)


Take any page in the Rust docs, for example . When you press the or keyboard shortcuts on your keyboard, they are supposed to either collapse or expand all items on the page, but not both (according to the instructions that you can find by clicking on your keyboard (or on the screen). Please make the + and - keyboard shortcuts idempotent, otherwise it would be redundant to have two buttons that do the same thing.
What do you think about this ?
Yeah we should do this.
I'll send a patch in the next days then.


Users should use the cargo-ified Deprecate for a release or two then delete. cc
:+1:
Related:
I tried this: Hoping to deprecate the whole crate, but then building this program does not emit any warning: I expected a deprecation warning on the line. Is there another way to achieve this, or do I need to annotate individual items in the crate?
That should have worked, but you may need to remove the annotation above (they may be conflicting). I would also personally find it very helpful to annotate methods in particular what the path forward is (or just a general post about how to migrate).
Removing worked, thanks. Should this deprecation go through the RFC process, or can I assume that the team wants it since filed this issue? The documentation at explains how to use rust-url, and in particular the concept of relative v.s. non-relative URL schemes (e.g. vs ) which is a bit unusual. I believe this sufficient to make migration straightforward, but I’m obviously biased. Any feedback on the documentation is welcome. (I’ll make the deprecation message include the documentation’s URL, it seems more useful landing page than the github repo.)
Having an issue is sometimes considered a "todo item" rather than "everyone has approved this", you'll find both styles of issues on the issue tracker. We don't have much precedent for deprecating an in-tree crate, so we're forging new territory here. I'd like to start moving crates out of the repo, however, so I hope to have some more on this topic soon.


<!-- 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. --code from requires debug assertions <!-- 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 --
lol, nightly emits this:D : another one from
any updates? :upsidedownface:
claim I think I got a fix :slightlysmilingface:
Error: Parsing assign command in failed: ...' claim' ' I think I'... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
claim


When writing the current error is "expected one of these tokens", without any attempt to recover the parse. It should instead be closer to: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
What do you expect the suggestion from this code? here is a valid identifier, "expected one of these tokens" comes when the second identifier comes.
I think this case should remain as is. in particular is a shame because it is a valid type for the parser, but not a valid trait, and newcomers might not yet have a mental model for the distinction. I would say, when parsing a trait, if it can't be parsed, then try to parse a type in a snapshot (like we do in other parts of the parser), and if successful, emit a targeted error (trait expected but found type).
claim


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 compiler team prioritization.


The following code should pass regardless of the declaration order of lifetimes: This is related to but it's different in that we do have a lower bound region, , but we fail to recognize that because , which is responsible for calculating from , assumes that the outlive relation is a total order, which is not true. Here is the graph of : ! So we need an efficient algorithm that works for partial order relations, but the one that comes to mind is . The perf may not be really important here but I'm curious to see the alternatives. label C-bug T-compiler A-borrow-checker E-mentor E-help-wanted <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Here is the code of concern The code should calculate the from a set of universal regions (). The relations are encoded in and are guaranteed to be transitive and reflexive. The relation graph may have cycles and can be sparse. The goal here is to find a unique minimum choice that is known to be outlived by all other regions. If none can be found, the function returns . Regions that have cycles between them are considered equivalent so we can pick either one of them as a unique choice. e.g. , we can pick either one of as a minimum choice.


Compilation backtrace Version Seems to be very similar to and , but the difference is trying to send the value over a channel (removing this gives a "cannot move a value of type [u8]: the size of [u8] cannot be statically determined)
Just to update after the 0.12 release. I tried compiling the above example and am getting the same result (so this issue is still relevant).
Reduced test case: Something about the closure lets it get past type checking when it shouldn't.
This looks simple, I'll hopefully have a PR shortly.
Closed by


In , it was uncovered that is making some rather strong assumptions: two s with different address but the same type must not overlap. Not only is this a scarily non-local safety invariant, it is also fundamentally incomaptible with some APIs that ought to be correct, as demonstrated by this snippet (thanks to and for help with working out the example): to see the issue: will duplicate parts of the memory range when there is overlap, which leads to double-drop (other parts of the memory range are just lost, leading to memory leaks, but that is not the main issue here). This is not itself a soundness issue as it requires unsafe code to trigger UB. But this likely reflects an unintended consequence of . This got stabilized in as part of That commit references and an RFC, but is not mentioned in either of them. was in Accept that is unsound and document "non-overlap" as part of the safety invariant. This seems very fragile. Make not misbehave on overlap, either by panicking or by only swapping the non-overlapping parts. Cc
was in , which was authored by a "Charlie Fan". This is probably
Cc
This makes the method sound, but it seems like there could be other seems-like-they-should-be-ok cell projections that break under this behavior.
I don't think so. This makes the function behave "strangely", but since no data is duplicated nor discarded, I think it is sound.
I share this hunch, although the code, out of nowhere, may look very contrived. Consider: So it seems like -king (at least for non- types) is the only option that would allow us too keep the structural property of s, which, imho, is a very intuitive programmer mindset (and thus, a mistake that many would do should they not know about this caveat), and so a quite important thing to preserve .
That is an example of the "strange" behavior not being the right thing for this code, but it is not an unsoundness of per se. Your unsafe code is simply making wrong assumptions about the functional behavior of . Current favors the first operand in case of overlap (according to documentation); unsafe code that incorrectly assumes it would favor the second operand would be equally wrong. I don't see a bug in either way. IMO it seems rather strange to only panic for non- types.


Btw, also exists. does not have array/slice projection functions though and they would be wrong due to the counts, so overlapping probably truly are not a thing.
At the very least, an argument that aren't allowed to overlap is easier to defend than that aren't allowed to overlap. Plus also, doesn't have guaranteed layout in the first place, so any example using tuples is (currently) implementation-detail-tied even before hitting . You could still construct an example using only types, of course; just replace the tuple with an actual type. You could even make it . As I understand it, there's three main cases here. ping two nonoverlapping is fine. ping two partially overlapping without any bound on has a sound, if surprising, definition, where the nonoverlapping part of the arrays are swapped. ping two partially overlapping unknown is unsound in any definition, unless both has no safety invariants and the overlapping portion is . The third case is obviously the most restricting one, and is defined on . To expound on first of the two subissues: Consider a type with the extra safety invariant that the second must be double the first . could even be . It would be valid to create two from , as you'd have and . There is no possible definition of (other than a no-op) which preserves the safety invariant. And of course the impl doesn't even know about the safety invariant. I could probably create an even worse example using underaligned types and relying on a specific endianness, perhaps even accidentally breaking validity invariants (think around partially overlapping ). The only two resolutions I'm confident in are making always panic for overlapping cells (because there could be safety invariants being broken) or forbidding overlapping s to -compatible types (optionally: that would be broken by ). And I don't like the subtle implications of the latter (e.g. being unsound for unbound ).
I don't think would be immediately unsound, you would still need a way to create overlapping s.
In particular, they certainly can only overlap in restricted ways -- if they overlap such that one's sits on the other's , I can already cause UB without just by storing into that and then reading it as a . Oh I see... to only swap the non-overlapping parts we have to make an argument that these parts have the same type (safety+validity invariant).


Which... seems utterly bogus now that I think about it. Worse, the invariant could correlate the overlapping with the non-overlapping part, as in your example. (Removed a whole bunch of nonsense where I try to find some special cases that work.) Yeah we should make it panic.^^ It is unsound to create an to these though, even without I can already violate the safety invariant here by setting the second reference to . Ergo this is not a problem for , we can already assume such references do not exist. I am confused, is there a negation missing somewhere in this sentence?
Fair. I'm fairly confident that it'd be possible to come up with some safety invariant that a partial swap would break, though, with more data-dependent qualities. The parenthetical is an optional relaxation of the potential requirement (but at the cost of a lot of complexity).
But shouldn't it be forbidding overlapping s to -incompatible types? Not that I know what either of these things mean, but forbidding incompatible seems to make more sense than forbidding compatible.^^
Yeah, poor verbage. I meant roughly "forbidding overlapping s of types that can be used in (i.e. sized types)", with the optional extension of "only for those actually broken by " (however that would be defined).
that partially overlapping s through an enum is problematic even without :
Enums isn't really the same thing. That enum projections are unsound , but as also discussed in that article, struct projections are typically ok, and the array projection discussed here is essentially a struct projection, not an enum projection.
I would like to bring up my crate  which allows projecting through using a macro. example usage: Note: doesn't allow projecting through enums for exactly the reasons that explained. I'm not sure how could interact with to produce bad behavior, because you can only project to fields, which can't be swapped with their parent, but just in case someone else finds something interesting. i.e. This isn't possible, so it's not possible to project through to a field that's the same type as the parent. Alongside the fact that all fields are disjoint means that cell-project should only produce overlapping if they are also .
I agree with here. Sum types and product types are different, and really should commute around product types, i.e., ought to be sound.


You can use , which led me to this issue (it'd be good if we could support field projection inside of and ).
While you could use to check that the tuple layout conforms to the C-like layout needed to do such projection, I don't see how your specific use of would lead to two partially overlapping though. Note that the problem is not with projecting to a single field, but to a group/subset containing multiple fields (or like in the array/slice example, to a subarray/subslice with length ).
Oh I see, you're right. False alarm.


While reviewing I noticed for the first time that the improperctypes lint normalizes with the "revealall" mode. I don't have a nuanced understanding of what that means exactly but based on the general description in the rustc docs and experimentation (see below) I think that's probably the wrong choice for this lint, because it exposes details to the user that are normally hidden during type checking. For example, using existential types, the lint pierces through otherwise-opaque existentials to look at the underlying (hidden) type, thus it both accepts code that is only FFI-safe because of the particular type underlying the existential, which users of that type shouldn't know or rely on leaks the underlying type to the user in error messages when (correctly) rejecting uses of an existential type as FFI-unsafe I can't quickly find an equivalent using only stable , because we don't have , but if there's a way to write "Option of the return type of this function" in stable Rust, then that would presumably have the same issue. cc for fact-checking my understanding that this is because of reveal_all
User-facing diagnostics should avoid the mode, yeah. In fact, the other variant of is literally - also the doc comments are pretty explicit about this: cc
I've been using 's over in recent PRs that modify the lint (see , , and ). In each recent PR, I've ensured that opaque types are prohibited (in the spirit of "FFI-safety of a type not relying on particular type behind an opaque type being FFI-safe") - with the exception of when a opaque type is used in a projection (). Unless there are specific examples of behavior that still need to be changed as a result of this issue - should this issue be closed?
My litmus test for closing this would be "all the normalizing done in improper_ctypes uses ", which is hard to audit for while there's multiple PRs in flight that address parts of the problem. After those PRs are all merged, we can see if there's any remaining and if so, their location should tell us how to exercise any remaining questionable behavior.
I've opened to fix the remaining two places that is used now that the other PRs have landed.


<!-- 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
Another regression of cc
Before I create a fix: is an expected/reasonable value in this ? I.e. is the right fix here just to allow ?
I don't think so. Actually just looked, think it's because we're not erasing properly. Let me put up a quick fix.


It would be more helpful to suggest the method for the typo rather than a nightly-only symbol which isn't actually available. the suggestion doesn't work. method is actually available on a . method has been stable since 1.0.0. had trouble noticing the difference between and and could have used the compiler's help. No response Reproduced with 1.68.0 stable and 1.70 nightly. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim


Error: Reproduces with:
cc
I just now noticed that does not actually yet allow unsized . Might be related.
This doesn't compile, but it doesn't ICE.
It looks like no longer exists. Did it get replaced by something else? I imagine there's not much value in adding a regression test with a broken import
from


When running on of the crate, panics: Platform: macos
FYI, this appears to be a macOS-specific bug:
Minimal repro:


The title already says it, but as an illustrating example you can have a look at Since &mut T can be implicitly converted to *mut T, I wondered whether there's a reason that it doesn't work for &mut &mut T (besides "no one has implemented it" :smile: ). pointed out that this might be (in IRC). The example code also illustrates a somewhat unexpected failure of type inference, which might be worth filing as a separate issue.
Hmm... take the following: Rust will currently complain about mismatched types for the second coercion. It's not clear such a coercion should exist: it's like converting a to a .
Note that first coercing to instead of seems to work ().
Your testcase is constructing a , not a .
Ah, thanks for pointing that out.
In don't know if I understand your point, but if you argue that such a coercion should not exist because it might be unsafe, the line in my original example shows that this conversion is already possible in safe code.
Heh, C++ has special rules for multi-level pointer conversions exactly to prevent these kinds of type unsafeties: "More qualified" relations can be translated to Rust's // relations.
isn't doing the same thing: the outer is actually constructing a temporary, so you end up with an (as opposed to a ). Also, safety isn't really relevant; we allow arbitrary explicit pointer casts anyway.
Oh, wait, I see, you expect the original to interpreted as , and then converted from there to . That makes sense.
I think this would work if borrow expressions would take into account that they might get coerced later and pass down the from (where here), instead of only working for .
Triage: this still reproduces.
Closing this as the bug is fixed and playground link above works for all editions.
The playground link had the problematic line commented out: It still gives a compile error:
oops my bad then
This idea has been suggested. A T-compiler member has pointed out that other languages apply rules to restrain pointer coercion, specifically because multi-level pointer coercion is prone to being a bit of a footgun. Not quite "this is a bad idea", but despite the simplicity of the proposal, it deserves being treated with caution. There is no strong argument that this is a bug because it is consistent, if annoying.


Legalizing this behavior with narrow cases seems permissible, but amounts to a new language feature design request. Transitive coercions, as part of the revised coercion rules, are . Accordingly, I think this should also be closed... but not before documenting the current behavior in the form of a regression test.


In 1.12, figures out which libraries it needs for external LLVM using which breaks if you have LLVM with and (which is needed for clang 3.9 these days), since then there is a dynamic and lots of , but the code sees the and decides it has to link statically, which fails. The code should decide whether to link static or dynamic first, and then call resp , to get the correct library name.
Thanks for the report! Sounds like it should be a relatively easy bug to tackle as well!
In Void, we work around it by just adding , I guess for a general fix you need some policy how to link it.
Oh we basically always want to link LLVM statically, so we can probably just always pass it.
We emphatically don't want that in distro builds. Would you accept a patch to make this conditional?
certainly!