Defining macros recursively like so will lead rustc to cause a stack overflow. It would be useful to improve the error message for that problem. There is currently no error message specified for that issue.
We already have a field in . We can copy it to libsyntax's and then track the recursion depth in .
I am looking into this issue. Howerver it seems like the same and are used for macro expansion, so it seems like recursion depth cannot be tracked naively.
The methods and already maintain a sort of stack of macro invocations. They can also maintain a counter so that we don't have to walk that stack on every check (it's a kind of indirect linked list).
Now that recursion depth is limited, is there anyway to configure it from the command line? The current depth setting (64?) is too aggressive for some macro magic I am working on, that recurses heavily.
I could at least increase it to 256 if that would help. Other than that someone else ( maybe) should look into it.
My patch did not include any method to customize the depth limit. I just used 64 because defaults to that as well. I am not aware of a command line interface to change session attributes, but I am not very familiar with rustc`s command line interface. Another way to customize the recursion depth for macro expansions could be using something like for macros which result in deeper recursions, but no in an infinite recursion. Anyhow, if there is a decision to do it one way or another, I'd be happy to work on a patch.
Could we at least for now bump the limit up to something much larger? The current setting of 64 is probably too low for macros that rely on reduction rules. (ie that match a portion of a statement and pass the remainder to another macro (often itself) for further expansion). I don't have a good handle on the expense of each macro expansion in terms of compiler memory/time ... but is there any reason for it not to be a number on a much larger scale, such as 1024?
I like the idea of a file/crate attribute to govern the recursion depth of macros expanded within that crate.
I will try to increase it to 2048. Someone else should maybe look into the attribute or command line argument thing.
Seems that 2048 is way to high and already causes stack overflows. If just the compiler wouldn't compile forever...
Seems surprising ... are you changing the to be 2048, or changing it at the level as well?
Just the ExpansionConfig limit, since the session limit won't go crazy way too far. I guess 1024 is still ok for macros. It is compiling and testing right now, so I can tell you more later.
Ah, I misunderstood you, I thought you meant the overflows were happening when compiling the compiler! You mean rather that an infinite recursion test will overflow before it hits the 2048 limit I think.
Yes
I got a workaround, but I guess it is not the best way. Sadly I got ill, so I won't be able to work on it further. Maybe someone else could go on? /cc ()


Currently a macro cannot create a pub fn. It can however create a regular fn. Fails with:
This is a problem with methods specifically, it works fine if is used to define a normal top-level function (i.e. not inside an ).
Dupe of ?
thanks.


Here I'm using a fully-realized type that should be FFI safe, but rustc continues to complain:
Closing until I have an example that's actually correct.


If I'm not mistaken, . It won't terminate the program. It's or unwraps the value. Also, wouldn't a call to the IoResult's  be more direct? Although the custom failure message would be lost.
I thought this was already fixed :/


(PR on top of )
seems to work. However, the syntax is awful, and requires a comma for disambiguation.
As of today nightly, that doesn't work anymore. It seems that where clauses don't work with tuple structs anymore. Any plans to support them in the future?
is this the desired syntax? I'm assuming it was chosen in order to do some kind of parsing disambiguation. I am willing to submit a small patch for this, just want clarification on the syntax.
hmm afaik they should work, and I would expect the syntax to be
I will track this one down and follow up with a PR.
You can get the current syntax to compile if the generic type bound uses the trait sugar: Nominating, since we won't be able to move the where clause to after the tuple after 1.0 without breakage.


This should say Undefinedfn foo() -Undefined {}` does.
triage: still true today
As of the error is I will add a regression test so this issue can be closed.


The following code causes an ICE: Removing the parameter or changing it to be a value instead of a reference stops the crash with an error saying I need to specify a lifetime, which makes me think this is a problem related to inferred lifetimes.
It isn't, you just have to specify a lifetime: ICE-s as well. Returning an unsized type should be a typeck error.
happens to work because it implies , i.e. would also work.


There are 3 cases of this undefined behaviour in : There is no guarantee that and have the same layout under the new rules. This needs to manually copy over the fields one by one which would compile to the same code as long as a feature like struct randomization wasn't enabled. Since vectors expose , it could be switched to make use of that. However, this is a pervasive issue with in the standard libraries.
I would like to fix this one. However, I don't understand why you would need to use . If we need to copy everything, why don't we do it directly to a ?
the fields of Vec are private, so you can't just use


On the latest nightly (previously it worked fine) Rust fails to compile this code: It emits this error message: I managed to strip it down to this example: It fails to compile with this error: If is replaced with , then it compiles fine, so the error seems to be related to matching on s.
Sorry for the breakage, fix on its way.


Right now the Int and Integer traits imply PartialOrd but not Ord. Is there a reason for this? It seems like integers do have a total order, not just partial. I asked on IRC and people seemed to think Int should imply Ord. If this is correct I can send a pull request?
Yup :)
I have two questions: May I ask what is the trait? Couldn't find any in the std doc: Did you mean  () when you wrote "the trait"? But it doesn't even inherit . Am I missing something?
The trait is in .
Ah, it was the big int code separated from the std lib! Thanks. I also overlooked implemented , implying . Sorry for the noise!


In we had the submitter change a to an as follows: We felt that better communicated the intent of "this code should never panic assuming that the implementation is correct" (as opposed to , which communicates "this code should never panic assuming that the user passes in the correct inputs" (cf. indexing, division) and is generally to be avoided in the stdlib). However, I think it's a shame that by expressing the intent more clearly in the code we're simultaneously losing information regarding which invariant was violated in order to reach the unreachable code. Note that this isn't really a huge deal, because we can just move the "Invalid SearchStack" bit over into a comment next to . It's also not really a huge deal for the theoretical bug reporter who's filing an issue upon hitting this code, since still includes a filename and line number in its output. However, given the precedent of optional messages set by , I don't think it would be a stretch to imagine that could also have an optional message. Usage for the typical case would be the same: could optionally look like this:
I'll have a go at implementing this.


Backtrace:
Well, this is interesting. It's broken all the way back to 0.10. I think it's been a bug in the type id implementation since it first landed. Here's a smaller test case:
is there a particular reason explicitly checks that all regions it encounters are ? Trans doesn't seem to go out of its way to erase late-bound regions in fn type signatures, which results in this ICE. I could add a call to in trans to fix this, but it would be cheaper to just ignore regions during hashing.
Ended up catching me
It seems we actually want to take late-bound regions into account when hashing. For example, the following should hold:


Info located at: Looking at the source code in libcollections there doesn't seem to be such a method alltogether.
This would be fixed by The new way is


I think this is fallout of , and it's somewhat unfortunate :( ! cc
Yup. Didn't think of that. So don't set the name of the main thread I suppose?
Yeah that may be the best option after all (sorry for recommending the opposite!)
Okay, no problem, I'll send PR...
Thanks!


Rust Version: rustc 1.0.0-nightly ( 2015-02-12 00:38:24 +0000) Description: When compiling the following code with rustc the output is: ERROR:rbml::reader: failed to find block with tag 7 error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'explicit panic', C:botslavenightly-dist-rustc-win-64buildsrclibrbml stack backtrace: 1: 0x69bfbbeb - sys::backtrace::write::h57b621d79849130fitB 2: 0x69c13974 - rt::unwind::register::h686925f8fa692ab9GSJ 3: 0x69b836ef - rt::unwind::beginunwindinner::hc2a974b1bdaa4639YPJ 4: 0x302da8 - reader::maybegetdoc::h2547f886a15a227erHa 5: 0x301d2f - reader::getdoc::hc198b8918d0de179nLa 6: 0x1138635 - metadata::decoder::itemtype::h7f6e008c4a79af18mck 7: 0x11480d9 - metadata::decoder::gettype::h9620389d7a7d23c0Xok 8: 0x10fb7a8 - metadata::csearch::gettype::h3af5a6a2534b2d8bCkn 9: 0x6d605059 - collect::CollectCtxt<'a, 'tcx.AstConv<'tcx::getitemtypescheme::he174d5be00f2627cMFw 10: 0x6d5f49ab - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 11: 0x6d5f64ef - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 12: 0x6d5978bd - astconv::asttytoty::h1dadfccc9ddb5e90VHv 13: 0x6d5ef523 - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 14: 0x6d5fa734 - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 15: 0x6d61330f - collect::CollectCtxt<'a, 'tcx.AstConv<'tcx::tcx::hf449f596d422460aAFw 16: 0x6d60a79a - collect::CollectCtxt<'a, 'tcx.AstConv<'tcx::getitemtypescheme::he174d5be00f2627cMFw 17: 0x6d643867 - checkcrate::h72731a5b4298723fkrB 18: 0x6d64131c - checkcrate::h72731a5b4298723fkrB 19: 0x70b1eb58 - driver::phase3runanalysispasses::hc863f28a1bd50b11SGa 20: 0x70b02618 - driver::compileinput::hd580d8c011d24ba3Eba 21: 0x70bcfc4c - runcompiler::hb48a33a057cced0e5bc 22: 0x70bcd85b - run::h3df2025cf41d43b3Ibc 23: 0x70bcc56a - run::h3df2025cf41d43b3Ibc 24: 0x69c4180c - rusttry 25: 0x69c417e9 - rusttry 26: 0x70bccbdc - run::h3df2025cf41d43b3Ibc 27: 0x69c03ae2 - sys::tcp::TcpListener::bind::h2319ec78a0f49dc2faF 28: 0x770f59ed - BaseThreadInitThunk
Same error as .


Super easy to implement for anyone interested. The implementation in the RFC is sound, although the new code should be abstracted out into a function that the macro calls for inline and macro-sanity reasons. The function needs to be marked as public/stable, but should otherwise be marked as #[doc(hidden)], as it is not intended to be called directly -- only by the macro.
Willing to mentor on details.
I'd like to give it a shot :)
By the way: The seems very sparse. If it's okay, I'd expand that a bit while I'm on it, or should that go into a seperate PR?
Yeah, that's totally reasonable to do at the same time!
Great! What would be the preferred place where to put the new function? I've it to as for now (currently compiling it)
Since it's supposed to only be used by the macro (and will be doc(hidden)), it makes sense to me to put it in Putting it in makes sense, too, though.
has a section labeled "Internal methods and functions" that seemed to fit well.


Could someone change the bad title? I am not good for english.
Seems like more of a diagnostics issue. is a private constructor, but we're erroring out on type-checking before we realize this. The fix for this specific code is to replace with
Triage: this now has a different, yet still confusing, error:
That error is correct; but either way, the other error you get today is this, which while not ideal, is possibly the best we can do. I guess we could look for a method with a single parameter? But that seems hacky.
It is, but it is a common enough pattern and such a big enhancement in end user experience that I feel it'd be worth it to add it, specially when the ctor is not public. Then, the output should be: Similar output, but not quite the same cause in .
In order to implement this there's a bit of roadblock at the moment. The verification if a struct has a given method is done in , while this error is being emitted in . I believe the error is being bubbled up, but it would have to be delayed on its entirety to the type check step in order to verify wether exists. :-/ You can look for traits that have a given method (), but when I tried it with it returned an empty . We could provide with a generic suggestion about trying out , but I would much rather prefer if we could have some certainty that the method exists instead of potentially misleading the user.
Current output:
The error message seems pretty good... let's close this?
I still think that . Definitely low priority now given the other improvements on the error.
: We still need to look for and suggest it.


is useless () so skip it.
Neither of the macro chapters have sections for "common macros". Should we add one? Presumably there would be quite a few of them.
There is for the macros in std, plus some of the built-in syntax extensions. It's not that easy to find; there used to be a module in the rustdoc output but no longer :( I'm not sure exactly what should be documented where. The built-in syntax extensions like might deserve special mention, as they give you capabilities within that you otherwise would not have. cc
I think , , and also deserve mentions.
I would like to take on the task of documenting all the common macros. I've started them and appreciate some input on how big the final list should be, and if every macro needs an example (or three). What about the most common one, prinln! ? Should that be in there too?
It's not clear to me what doing this issue actually means. Moving some docs between some places?
The original issue was to add several common macro definitions with examples in TRPL, which I agreed with. I'm not sure what's up with the edits.


On rustc 1.0.0-nightly ( 2015-02-21) (built 2015-02-21) the follow causes an ICE: Full backtrace: error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'assertion failed: != ast::LOCALCRATE', /Users/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc- stack backtrace: 1: 0x10b7aebe3 - sys::backtrace::write::hc8e3cee73e646c590nC 2: 0x10b7dcbe5 - panicking::onpanic::h00b47941f5bc8a02HOL 3: 0x10b706418 - rt::unwind::beginunwindinner::h539538ef7f909326UvL 4: 0x108472895 - rt::unwind::beginunwind::h7610573592537740396 5: 0x1087eb7dc - middle::ty::lookuptraitdef::h00103e323589b59cNla 6: 0x108812687 - middle::ty::predicatesfortraitref::h59dd4f8104908ae1Vna 7: 0x10880c125 - middle::traits::util::Elaborator<'cx, 'tcx.Iterator::next::h9dd8ee47ae7ea8d3QkV 8: 0x108811fd1 - middle::traits::util::Supertraits<'cx, 'tcx.Iterator::next::h2583ba3461accfb9rnV 9: 0x108109246 - astconv::asttytoty::closure. 10: 0x1080a36cb - astconv::asttytoty::hb64a583bfbbc7b64Ncw 11: 0x1080ff44d - astconv::asttyargtoty::h51a53c78e1218ba4sbw 12: 0x1080feff0 - vec::Vec<T.FromIterator<T::fromiter::h8575313848639105278 13: 0x1080fc2e0 - astconv::convertanglebracketedparameters::h9209f0db8109fac9biv 14: 0x108101457 - astconv::astpathtotraitref::h2a3b7b2e77e3fde5Vvv 15: 0x1080af1fb - astconv::instantiatetraitref::h65c5bb030d486323Csv 16: 0x1081007ea - astconv::instantiatepolytraitref::hb7df5c75231f22c61qv 17: 0x10813049f - collect::computebounds::h0eb0cb5207e10f2ccTy 18: 0x10811270f - collect::traitdefofitem::hb48744a94bcef339Q2x 19: 0x108110c0f - collect::CollectTraitDefVisitor<'a, '<'v::visititem::h4c7bef27b106e20cS8w 20: 0x10815d07f - checkcrate::closure. 21: 0x10815b02e - checkcrate::hbe2eb4aab434ad7cVjC 22: 0x107ac68db - driver::phase3runanalysispasses::h50728865d3ffa6b2gHa 23: 0x107aabb9d - driver::compileinput::h349b039ebe75c13eGba 24: 0x107b84857 - runcompiler::h1e4d87c6044fbf6dZbc 25: 0x107b81cd1 - thunk::F.Invoke<A, R::invoke::h2059937391804860278 26: 0x107b80930 - rt::unwind::try::tryfn::h11862807381821880905 27: 0x10b8567e9 - rusttryinner 28: 0x10b8567d6 - rusttry 29: 0x107b81095 - thunk::F.Invoke<A, R::invoke::h6573516661401600357 30: 0x10b7c5ac3 - sys::thread::threadstart::h9e3555425c6999b2e4G 31: 0x7fff8fd0d268 - pthreadbody 32: 0x7fff8fd0d1e5 - pthreadbody
This is basically . And on top of , correctly declares there's an illegal recursive type:
Tests in .
Can this be closed?


I was sloppy when I implemented and did not include a test. So, surprise, a follow-on commit a few days later broke it. As self-punishment for neglecting to include a regression test, I am assigning myself the task of reviewing our test suite to make sure that every feature-gate has a test. Here is a transcribed list of feature gates, based on , that I have annotated according to whether the feature is Accepted/Removed (and thus needs no tests), Active/Deprecated but has tests already (marked with an , or Active/Deprecated but has no tests that I saw via a cursory grep/skim. - , - , - , [x] - ("asm", "1.0.0", Active), - , [x] - ("nonasciiidents", "1.0.0", Active), [x] - ("threadlocal", "1.0.0", Active), [x] - ("linkargs", "1.0.0", Active), - , [x] - ("pluginregistrar", "1.0.0", Active), but it is not clear whether this is testing the gate or the gate. From the error message it seems like the gate is firing. [x] - ("logsyntax", "1.0.0", Active), [x] - ("tracemacros", "1.0.0", Active), [x] - ("concatidents", "1.0.0", Active), [x] - ("unsafedestructor", "1.0.0", Active), [x] - ("intrinsics", "1.0.0", Active), [x] - ("langitems", "1.0.0", Active), [x] - ("simd", "1.0.0", Active), - , [x] - ("quote", "1.0.0", Active), [x] - ("linkllvmintrinsics", "1.0.0", Active), [x] - ("linkage", "1.0.0", Active), - , - , [ ] - ("rustcdiagnosticmacros", "1.0.0", Active), [ ] - ("unboxedclosures", "1.0.0", Active), - , [ ] - ("advancedslicepatterns", "1.0.0", Active), - , - , [ ] - ("visibleprivatetypes", "1.0.0", Active), - , [x] - ("boxsyntax", "1.0.0", Active), gated-box- [ ] - ("onunimplemented", "1.0.0", Active), [x] - ("simdffi", "1.0.0", Active), gated-simd- - , - , [ ] - ("plugin", "1.0.0", Active), but it is not clear whether this is testing the gate or the gate [ ] - ("start", "1.0.0", Active), [ ] - ("main", "1.0.0", Active), - , - , [ ] - ("oldorphancheck", "1.0.0", Deprecated), [ ] - ("oldimplcheck", "1.0.0", Deprecated), [ ] - ("optinbuiltintraits", "1.0.0", Active), [x] - ("intuint", "1.0.0", Active), [x] - ("macroreexport", "1.0.0", Active), gated-macro- - , - , [x] - ("stagedapi", "1.0.0", Active), [ ] - ("unmarkedapi", "1.0.0", Active), [x] - ("nostd", "1.0.0", Active), [x] - ("boxpatterns", "1.0.0", Active), gated-box- [x] - ("unsafenodropflag", "1.0.0", Active), [x] - ("customattribute", "1.0.0", Active), [x] - ("customderive", "1.0.0", Active), single-derive- [ ] - ("rustcattrs", "1.0.0", Active), [x] - ("staticassert", "1.0.0", Active), [x] - ("allowinternal_unstable", "1.0.0", Active),
(but hey, if other people want to add such missing tests in the meantime, while I am asleep, I will not mind. :)
In case its not clear: If you want to help, just find a case above that does not have a check-mark and also does not have a pull request number attached beneath it. (And I guess write your name so that other people do not waste time adding a test for the same feature gate).
The test for is located in
I am not surprised that I "overlooked" that ... the expected error message prefix does not say anything about a feature gate. Let me just confirm that the whole message does ... Update: Okay, the help output for that test () does mention the feature gate: So I have now checked off that box, though I wonder if I should add this help message to the expected test output there.
I was wondering the same thing about the help message. It is not very clear what that test is doing, the only hint was the filename. From reading some help messages were removed, would there be any concern for adding help messages to the expected test output in this case? It could be worth adding a comment in there similar to the other gated tests: In addition, would it be worth going as far as to rename to (and doing the same for any other gated tests that do not have a prefix in their filename)?
In relation to the feature gate list above I'm going to start off by looking into the following: update: removed items that had tests, and , - - -
ah yes, is (correctly) why the help mag is missing .... hmm .... that complicates things
I've done a pass through of the unchecked feature gates and have found tests for the following: () () () () () () Could these be marked as complete?
thanks!
Ok, so I've had a look through everything, here's my findings: I have some questions below for the three outstanding feature gates (at the very bottom of this comment) and was wondering if you could help confirm the status of those feature gate tests? My previous listed feature gates that had existing tests. I've since found a few more to add to that list. Here is the full list of feature gates with existing tests. New findings are in bold: : : : : : : : : : The following feature gates were removed after this issue was initially created. Since they are no longer around they can be considered complete or crossed out of the task list above: : see : see The following feature gates appear to have duplicate tests introduced in , the initial tests were in and : - The following are not in the above task list as they have been since the issue was initially created: : see : see The following are remaining feature gates needing tests (excluding the feature gates I had questions for, see below). I'm cooking up a PR for these: - - - The following items are ones that I had trouble completing because I have questions and need some feedback: - The was introduced in , and tests for were replaced with tests for missing stability attributes: . In addition, it seems that there is no way to trigger unless there is a bug in a library or the compiler itself. Are the tests in missing- enough to consider complete? These appear to be the we're looking for relating to , could someone confirm this? This appears to be the feature gate test, but was removed in () Should we reinstate the test in this issue or let it be handled by which is in the works?
For visibleprivatetypes, i found src/test/run-pass/visible-private-types-feature- Not sure if item this should be ticked as well.
There appear to be a lot of new unstable features since this was touched. It seems hopeless to ever catch up on this issue without an automatic tidy script verifying the tests exist. do you want this issue to continue? Should we try to augment tidy to check the existence of compile-fail tests mentioning unstable features?
I agree that it seems like we'll never be able to close this without having some sort of automation (e.g. a tidy script, as you say) to verify that the tests exist. I don't have any immediate idea about the best way to write such a script. I guess it could just be based on some naming convention for the test itself; i.e. it would be just a heuristic check, not a true verification of it.
I think it could be written like so: after , search everything in for . If this makes sense I can mentor.
but requiring the test to explicitly deny the feature defeats the point, doesn't it? That is, the goal here is to catch code that makes use of a feature without explicitly opting into that feature. .. Though I suppose you might be thinking that if there is enough infrastructure present to support some kind of deny(feature) attribute, then that is a sign that the necessary gating is in place, regardless of what the default lint settings actually are?
Good point. I think yes, I was considering that just confirming that the compiler has code that correctly can deny the feature is good enough, but there is some room for error by making the deny explicit. The attribute also wouldn't actually confirm that the compile failed for the correct reason. We could also just require tests to annotate in some other way that yes, it is testing that a particular feature is denied. As an extension to my previous suggestion, the test runner could take the test case that is annotated to be a 'deny feature' test, run it once with then run it again with no feature attribute, and compare the results.
Similarly to the above, but to avoid creating another custom test runner. The featureck lint could require that and contain pairs of feature tests that are identical, one with and one without.
With fixed, maybe this issue can be closed as resolved?
Thanks


and are obsolete, but is not.
I think I spotted the problem, testing...
Fix in


compiles without any error. Notably this isn't a regression from I noticed it because has a public field that has had no stability attribute from far before . However, that PR did pick up some structs with missing stability attributes, I'm unsure of the exact circumstances when fields will get the errors or when they will not.
As points out in this isn't a bug; I didn't realise that stability propagation literally just ignores , meaning is due to the on . Closing.


Here's a minimal example which results in a runtime error: I'd expect that format string to work (precision=0, so no digits after the decimal point), but here's what I get with RUSTBACKTRACE=1: Ubuntu 14.10 / 64-bit rustc 1.0.0-nightly ( 2015-03-05) (built 2015-03-06) binary: rustc commit-hash: commit-date: 2015-03-05 build-date: 2015-03-06 host: x8664-unknown-linux-gnu release: 1.0.0-nightly
It also happens with 9.5 but not with 9.499. The formatting routine tries to round, but fails to handle the case that rounding extends the digits.
Just to clarify: this is not actually an ICE because the program is panicking, not the compiler. So, compilation is fine, but the program fails at runtime
This issue should be closed as it's now fixed.
Yay!


I suspect that we may want more experience with this syntax before freezing it, but I may also be misremembering! cc cc
triage: I-nominated
I believe you're right. I'll work on a fix for this. Here's a test case:
0 beta, P-backcompat-lang.


The references states that is a logical right shift, however it seems that it behaves like an arithmetic right shift for signed integers. For instance the following snippet prints : A logical right shift should produce (assuming 2's complement representation which I think rust guarantees?). In the same spirit the reference does not say if shifting outside the range of an integer is defined. From my quick test it doesn't appear to be: This prints garbage on my computer and on the playpen, so I assume it's UB or at least UV (it doesn't trigger the overflow check in debug builds though, maybe it should?) On a similar topic the reference also states that the following behaviours are safe: Unsigned integer overflow (well-defined as wrapping) Signed integer overflow (well-defined as two's complement representation wrapping) I believe that's not true anymore.
I see that checking for bitshift overflows is going to be implemented in so it seems to confirm that it's UB (UV?) for now.
see PR for the checks. We can go either way on the issue of whether overflow is UB or UV or neither. (That is, it is easy to adapt the PR accordingly; just a matter of deciding, and perhaps measuring the impact on code size, maybe.)
what's the process by which we decide that? I'd like to knock this issue out.
heh, I already made an "executive decision" (though admittedly it was one that was already in favor of), of making overflow panic when checks are on, and when the checks are off, we forcibly mask the RHS to ensure that we do not encounter weirdness such as that documented in and . (Though I still need to put in tests for that fallback behavior.)
That sounds very reasonable, thanks. Right shifts of signed values will remain arithmetic though, right? It's probably what most people will expect since that's how it's done in C/C++ and we'd have to simple way of doing arithmetic shifting otherwise.
right-shift of signed values are still arithmetic shifts, but that is independent of the overflow checking (which is based solely on the value of the right-hand-side compared to the bitwidth of the type of the left-hand-side)
Okay, that makes sense. I wanted to make sure that was the intended behaviour since the reference seems to say otherwise. Thank you!
oh I see; yes that part of the reference has probably been incorrect for a long time.


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


For clarity, the second call to ends up using the impl on . cc I had concerns about this kind of thing when these impls were being introduced but I thought I convinced myself that this kind of thing couldn't happen. Did something change in the way we designed these impls since then?
Possible solutions are to either remove the impl for or update to prevent it from invoking . Seems to me like the second is the better approach.
I believe the reason for the was because it was considered a good thing to require callers to explicitly pass references. I think we've actually gone back and forth on that a few times. Are we committed now to allowing callers to just say ?


See as an example, goes nowhere
Another example: The type is public in this case, but it's explicitly hidden.
Yeah, there's a lot of these.
For , it could be related to re-exported signatures. The same method in doesn't have this issue: Also, is it a bug that you can have private items in a public signature's ? Or private items in an impl for a public type? cc
I wonder if rustdoc should be resolving qualified paths that it encounters.
Is there still some unresolved issue here?
Still a thing; for example, tries to link to types in rand, but the doc link is broken. (That link goes to 1.19.0, but it's still there in today's nightly docs.) If i were to guess, it probably has to do with rustdoc seeing types that are in dependencies of std, but aren't being documented alongside it.
Wrote a fix for it. Will make the PR tomorrow or after tomorrow.
This issue was actually fixed by The issue i actually referenced in that PR was apparently a duplicate of this one.


The .exe installer tries to install to "C:Program Files (x86)Rust", even though it's the 64-bit version. It then fails to create the destination directory due to a permission error. The .msi installer correctly defaults to "C:Program FilesRust <channel<version", and has no problems with permissions, I would expect the .exe installer to have the same behaviour.
Rust should install to , just like Ant, Python, and many others. is the place for developer tools that have a known folder. is badly named (compare to ), poorly suited for command line tools, and clutters the already hideous PATH more than .
/cc
Neither Ant nor Python install to C:tools by default, and searching I can't find any reference to C:tools even being a thing? Both Python and Ant install to C:Python<Versionand C:ant, which is incredibly annoying, so please don't do that!
I might be mistaken, but installing both through stuck them in for me. I'd recommend anyone with a machine running Vista or later use chocolatey. And there's a trend in chocolatey to have packages extract to when they aren't self-contained enough for .
For an OS without much filesystem hierarchy, is a decent place for developer and command-line packages, similar to on some unices. But I'd much rather see a that actually obeyed chocolatey's conventions and extracted an archive to , with no installer/registry involvement. But Rust only and installers for windows. : And all packages that do this reduce PATH clutter, since chocolatey symlinks their executables into .
The idea was to deprecate the .exe installer once .msi is known to be working satisfactory.
Can we have a zip release too, that contains Rust and Cargo like the others? Linux and OS X have an archive release. Those are preferred in chocolatey because they don't involve the registry or any other Windows components.
We do produce tarballs for windows.
Seems like we should probably just stop producing the .exe's. That fix would go in
I don't see a cargo+rustc nightly tarball for windows, although I do see ones for linux and osx.
triage: We do not link to the .exe installer anymore, but we still produce them. I don't have access to windows at the moment to check if this bug has been resolved, but it's been a long time...
Grabbing the Windows download link from and swapping the for yields a functional link to the , which is nice. Testing on win7-x64, the MSI extracts with lessmsi, but the directory structure is somewhat unusual so there's no one-liner to get the Rust folder out. The best I came up with was: This yields a Rust install rooted at . However now that exists, multiple targets aren't really an issue anymore. Someone should make a Chocolatey package for
Can someone with access to Windows check what happens here today?
The latest version installs to instead, which works, but is a terrible default.
Triage: ! This seems... fine. I'm not sure if this should stay open or not; I'll let the relevant team (infra? compiler?) decide.


cc
Are you OK with just a PR?
Sure!
Is it worth writing tests for this? I'm not really sure how it could break, but better safe than sorry I suppose...
Yeah but just some simple tests would be fine to have
ping?
Working on it right now. , Steven Allen wrote:
Thanks. I had some free time so I thought I'd check.


This value has not changed in a long time, but to support sxs installation in a single dir it needs to. It should just be hashed from the value of .
So should we pipe the value through e.g. md5sum? That could be awkward on BSDs, where the hash programs have a . I think we can patch over the differences by adding a check to the configure script. Something like this: then in the Makefile we have: But if there's a simpler way then I'm all ears.


The failure happens in when the output of the command used in the test contains cyrillic letters. Changing the system locale to English (USA) or replacing with something like makes this error go away. cc
Hm interesting! This probably isn't so much connected to locales so much that something in the environment/output isn't valid UTF-8. Could you get a backtrace of this failure? I would be surprised if this was coming from , but the test looks pretty innocuous, so it may very well be coming from std!
The problem may actually reside in compiletest, it captures the output of the test and then can interpret it incorrectly. If the test is run as a standalone program outside of the test suite then no panic happens and the test works as expected. I'm still investigating. Here's the backtrace, but it's not very helpful:
Aha! It looks like . I suspect it would be fine for to just use


Running on the following code results in a stack overflow: With significantly fewer enum variants, it works. If I remove the use of , it works. This is breaking on one of my PRs (bjz/glfw-rs).
This seems to be fixed.
In my tests, you now need to have around 460+ enum variants in order to get the stack overflow. Can we assume nobody will ever have that many?
should a test still be written for this? Panicking is not correct, better would be that the number of variants is limited explicitly and that this is documented. Better still if there is no limit, of course.
In theory yeah if there's something that overflowed previously and no longer does, we should have a test for that :)
Triage: not aware of a test yet


The rust book currently links to, an old beta version of rust, causing some problems using the tutorial. Example: Dining philosophers will not compile.
What's your rust version?
According to the installer: 1.0.0-beta. On windows x64.
It compiles on 1.0.0-beta.2 and up. You should update your compiler.
I believe is right here, so closing, but thanks for the report!


Here's the problematic piece: On my machine usually can't delete file with "access denied" error. If I insert something like before then the test consistently passes. Supposedly we are trying to delete it too soon when it's still locked after execution.


Discussion carried over from: rust-lang/cargo Test binaries created by rustc should have a option instead of (in addition to?) controlling the thread count with . It's not a consistent user experience to have some functionality controlled via environment variables and some via command line options. CLI options should be preferred since they encourage users to keep configuration local to a single execution of a test binary and not export it globally, making it affect other test runs perhaps accidentally. It would also make the output of more uniform and compact.
Agreed.
The ability to specify this in the somehow might be nice. One of my crates I'm working on needs all the tests run like this.
It is already set table by an env var, no? Cargo just can't specify them. So still not ideal but might work in the meantime. On Apr 16, 2016, 19:05 -0400, Nathan , wrote:
Oh cool thanks, I'll set that in my project.


I got the message above,how to fix it?
Urgh. This should never have gotten through the CI bots. Some rules must be being built by the install target that aren't under the normal build.
I will try to look into this today while I'm investigating other nightly breakage.
I assume this is being introduced by the doc comment I wrote here: So the two bugs here are: the above doc comment in dropck. (Presumably just replace the indents with nested bullets.) rules do we need to change to synchronize with the CI bots (to catch this kind of case in the future) -- presumably its happening because attempts to build documentation for rust itself ... which sounds a lot like good old: ; see also
I posted a PR to stop building compiler docs. It does not fix the bug in the docs though.
Fixed.
Er, oh yeah, the underlying problem is not fixed, that the docs have broken examples.
Sigh, actually, I'll call this fixed since the title of the bug is about install failure and that works now. Broken examples in the rustc crate are nbd to me atm.
Just downloaded a fresh install from git and ran on a virgin arch linux box running on AWS and getting this error again cfg: using CC=gcc (CFGCC) cfg: disabling valgrind run-pass tests cfg: including prepare rules cfg: including dist rules cfg: including install rules cleaning destination tmp/dist/rustc-1.5.0-dev-x8664-unknown-linux-gnu-image prepare: tmp/dist/rustc-1.5.0-dev-x8664-unknown-linux-gnu-image/bin prepare: tmp/dist/rustc-1.5.0-dev-x8664-unknown-linux-gnu-image/lib prepare: tmp/dist/rustc-1.5.0-dev-x8664-unknown-linux-gnu-image/lib/rustlib/etc prepare: tmp/dist/rustc-1.5.0-dev-x8664-unknown-linux-gnu-image/share/man/man1 rustc: x8664-unknown-linux-gnu/stage0/lib/rustlib/x8664-unknown-linux-gnu/lib/librustc recipe for target 'x8664-unknown-linux-gnu/stage0/lib/rustlib/x8664-unknown-linux-' failed make[1]:  [x8664-unknown-linux-gnu/stage0/lib/rustlib/x8664-unknown-linux-] Killed make[1]: Leaving directory '/root/Downloads/rust' recipe for target 'install' failed make:  [install] Error 2 any ideas


Currently there isn't documentation explaining how the character works
Are you referring to its usage or implementation. Currently the book provides a very brief description of what _ does, however I could write up something slightly more detailed if desired. (see below):
Hmm, the conversation that starts here might be interesting


The configure script begins with: This works on machines where bash implements its own version of sh. But fails on Solaris where sh and bash are separated programs. To fix, I changed that first line into: And after that it ran.
cf. .
If the problem here is that we are using bashisms in the configure script, I would rather fix that.
works for me today. Was this issue fixed? I remember some other issues...
works, but the installer has the same issue. For this reason, doesn't work on Solaris.
According to , as one example, gen- is using bashsims or other shell extensions: But in all honesty, I don't think it's worth it. I would encourage you to either rewrite the script in Python (such that it is compatible with Python 2.x and 3.x) or simply change the scripts to use instead. On Solaris, is the traditional bourne shell, not bash, and is not even POSIX compliant. This is for backwards-compatibility reasons, among others. The posix shell is .


In it could be useful to explain the and syntax for getting a substring slice. Looking for a way to get a substring reference one is currently with the str API documentation which is quite a lot to digest and if one manages to find the unstable slice_chars(...) it says "Use slicing syntax if you want to use byte indices rather than codepoint indices", but what "slicing syntax" means will probably not be clear to someone who is new to Rust and not yet familiar with the Index trait.


From , (I assume identical to ) should report nanosecond times as or , not . This reportedly would require fixing in libtest.
I posted a PR for this yesterday. Well I chose to round & use units, but you can opine either way
nice! If you'll just tag that as fixing this then bors will take care of the rest.


A comment suggests the type should be something richer, perhaps, than just .
Blocked on or something similar
Definitely not backwards incompatible for 1.0 if this depends on Rust 2.0 features. Renominating.
Nominating for "far-future" (does that require nomination?)
FIXME is gone, bug is too vague, closing


Atomics are a language feature that the compiler (LLVM) has to have a deep understanding of in its optimization passes. Send and Sync are also opt-in-built-in-traits, which makes them a pseudo-language construct.
Does this mean Atomics should be mentioned in the Language Reference? What about Send and Sync? Currently, only Sync is mentioned, and that only in passing.


yields practically no information, and to even figure out what type of error occurred a user has to go run another rust script to use the Display implementation on an error with that os error code. It's not a good UX.
The Debug impl is used quite often, especially through unwrap.
You can look up the error code via (e.g. ). In fact on Windows the standard way to report an error is via its status.
I appreciate the tip, but still consider this is a serious UX problem since I really shouldn't need python to conveniently find out what kind of error I'm dealing with.


!.html states that the macro will return a , where in reality it returns . Example: This same problem exists for as well: Documentation at: !.html.


but The order of the fields is important, and this is something that should be clearly documented, as changing the order of the fields of a struct can change program logic.
generates a lexicographic ordering.


This causes a ICE: If the trait is defined in the same crate it compiles without error. Backtrace:


Actually what happens here is the following: The tuple you create in is moved, because it is not . When you perform the you move out of , into , leaving uninitialized. Your assignment to is basically to uninitialized memory, and doesn't have an effect. When you perform the assertion you see the old value of , because your assignment to had no effect. The whole thing is confusing because Rust does not warn when you perform useless assignments to moved variables, and it probably should. The whole thing becomes obviously when you add a statement that uses in the match arm: Edit: the labels you have assigned to this issue are incorrect.
Don't we see the new value , even though we're accessing , when performing the assertion, which causes it to fail? Doing this without a match statement passes the same assertion sucessfully:
Oops, you are correct, I am mistaken :( , mitaa wrote:
heh, I made the same mistake. Typed out most of a response and then realised that I'd mis-read the code.


This code produces "error: expected one of , , , or , found ":
That code sample probably didn't require linking to a playpen, I've made the description and title more useful.


This is a tracking issue for the unstable methods in the standard library. cc perhaps you can fill this in some more? The specific methods in question are: -
This is basically a lame version of cursors, which is what we should use instead imo. It's not 1:1 though -- this api lets you have all the elements yielded at once. Classic iterator tradeoff.
Triage: these are still unstable.
There are some ideas for a more complete API in
seems misnamed. Doesn't it do exactly what we call elsewhere?
I'm going to echo thoughts: An iterator conceptually represents a (double-ended) range of elements. The only operation that it supports is popping an element off the end of that range. A cursor on the other hand represents a position in a collection, and can be moved backwards or forwards in the collection. The cursor can be used to insert or remove an element at any given position in the collection. I strongly oppose adding insertion/deleting methods to since they do not fit at all with existing iterator usage patterns ( loops and functional-style methods). As I mentioned in the linked thread, a design based on the types in could be used.
Since we now have cursors, I think these methods should be removed.
Reopening since we only deprecated the methods instead of removing them. I'd say give it about 2 weeks then remove them.


Willing to mentor this. Fix is simple, just need to check for . We should also add a run-pass test to ensure that the above code continues to compile. Feel free to ask me if you have further questions!
I've been willing for a long time to start getting involved in some contributions to Rust, so if it's ok for you I would like to give this one a go and make it my first contribution.
Go ahead!


The linkable icon is difficult to . I'm playing with this currently. I'm toying with trying to change the icon from unicode into a svg because unicode has a weird box border shape that doesn't allow the icon to scale to the full box size. I'll put up a PR if I get it working. !


I tried this code: I expected to see this happen: "Error: invalid float literal" Instead, this happened: OK: 0 It seems the "leading +" and "leading -" is broken. Further, with i32 and i64 is emits an error but IMO an incorrect one: "cannot parse integer from empty string" I would expect: "Invalid integer literal" : rustc 1.5.0-nightly ( 2015-10-11) binary: rustc commit-hash: commit-date: 2015-10-11 host: x86_64-unknown-linux-gnu release: 1.5.0-nightly
Oh my, the float part is embarrassing. Preparing a fix right now.
Thanks for taking a look Looks like this is working as expected on stable and has leaked into beta/nightly, so tagging as such.
Yes, this is a bug (not checking for empty strings in the right places) of the dec2flt code. The bug is also in beta, so the PR (which I'll file very soon) should probably be backported to beta.


Playpen: Code like that puts a unicode character in a byte literal gets a confusing error message: A lot of people read this as if the part after the colon is in reference to "use a xHH escape", so it should show an example of that, but it really is just displaying the char that is in error, though somewhat obfuscated by using the codepoint instead of the actual char.
I agree. As someone unfamiliar with the language the error message lead me to fix the playpen code like this: fn main() { b'u{2192}' } Which leads to: error: unicode escape sequences cannot be used as a byte or in a byte string


The message for E0139 suggests replacing with . Actually performing such a replacement will result in double drops, since the version consumes but the version does not. (It presumably needs a or something.)


The first example
Thanks, these are hard to keep in sync, as they don't get automated testing :/


at the current version of error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'internal error: entered unreachable code', playpen: application terminated with error code 101
The reason this is happening is because the code thinks is an enum variant or a tuple struct. The code around this is somewhat redundant and would probably better be solved by making enum variants const evaluable and adding a function that translates s to


The macros chapter says: However the second sentence isn't true. is either nothing or a path with one and one identifier. That is, this pair of macros doesn't work, either when called from within the crate or from another one:


broke this code:
Clone is not implemented for anymore, because it now requires (previously ), which doesn't hold for arrays bigger than 32.
I'm assuming that trying to call on an would previously ICE the compiler?
In certain contexts, such as it would / will ICE yes, issue
Ah, the bound was before.
If only we had type level integers so we could just properly implement Clone for all fixed size array sizes without massive bloat.
It doesn't even requires actual numbers, most of impls act on "size-erased" arrays. Something like would be enough.
how would that work? Don't you need to loop N times to do the actual clone?
Something like: So is not used explicitly in the implementation, although it is still needed by internally. Whether it is easier to implement than type level integers or not is a separate question.


This code isn't valid Rust: We have an okay, but not great, diagnostic here: It might be nice to add a when the keyword found is that mentions that is not an expression, and so cannot be used in this way.
want to work on this? It's a similar task to the other doc comment one, but much simpler since it's a very specific situation.
I'd be happy to help someone :)
So, the parser already has its ways to differentiate keywords from identifiers. All we have to do is find the right place where that error is thrown, check whether it's a and add a note along with the error. The parser has all sorts of code, and adding a note's also around there somewhere :) Code:
I would like to try this. :)
Awesome! Feel free to ask waffles or me for help (you can find us both on IRC on #rust-internals), or ask questions here. (self-assigning since I can't assign to you -- just to mark it as "being taken")


All public types should implement Debug. Per conversation on #rust-internals, there might be some useful information that could be printed for these types -- but even just "Sender { .. }" etc. would be a start.
Was this
probably. It has been suggested that way more useful info could actually be printed instead of the opaque placeholders -- but that would be more of a wishlist item than a bug... The patch is sufficient to fix the actual problem I was running into: not being able to #[derive(Debug)] on any structure containing mpsc Senders/Receivers.
Ok, closing.


Code like the following one generates some unnecessary LLVM IR. Namely: We should skip zero-sized fields in .


As , if one of the stdio handles for a Windows process is unset (e.g. isn't present) then you won't actually be able to spawn a process by default. All handles are set, by default, to "inherit", but duplicate the existing handle, which in turn means that if the stdio handle isn't present this operation will fail. Rust currently by always opening up handles even if is specified (just pointing them to a blank stream), but Rust should also defend against this situation when it was spawned from elsewhere.
cc


I am following the Book in the Getting Started chapter, try my first rustc and get the error: The manual should at least mention the need for a C compiler (or at least a linker) as a dependency if you are using to install the binaries.


Brand new to Rust so I apologize if this is not the right place for something like this. I just finished "The Guessing Game" and noticed a small typo: We can do that with three more lines. Here’s our new program: The new three lines: It appears the book was updated at some point to only contain two lines. Similarly. in the following section. this could be a typo or possibly just confusing: If we leave off calling these two methods, our program will compile, but we’ll get a warning: The two methods could refer to .expect and panic!.
Nope, this is a typo. There used to be calls to in there, and they were removed, but the English wasn't.


The method on iterators consumes the first falsy value, instead of leaving it in the iterator. This behavior seems unintuitive to me; and I could not find any documentation of this functionality. Due to this (I think) being a breaking change, it's probably not worth changing the functionality, but documenting this is probably a good idea. I tried code: I expected to see this output: Instead, this I saw this output: : I believe this also occurs on stable (tested in ).
Not only would it be a breaking change, but it is impossible for a general iterator: the only way to tell if needs to stop or not is to get the element out of the iterator with , and there's no way to uncall /push an element back on to the end. (E.g. consider something like : once the message has been received and yielded, it is gone.)
For people reaching here and seeking a way to do this currently, provides a that will leave the last element in the iterator, but at the cost of cloning the entire iterator every iteration.
Well, maybe we can put the first falsy value to inside and add an accessor to it...
The cost of cloning an iterator is totally depedent on which iterator it is. A slice iterator is implemented using two pointers, so the cloning amounts to storing two pointers during the iteration. When the whole iteration is inlined, and llvm breaking the structs down to their members, it should be able to remove the store of the pointer that doesn't change (the end), so the overhead is down to storing and restoring one pointer.
is a nice hack, but it should be complemented by either adaptors on Peekable and/or itertools' PutBack.


For clippy's lint, I made use of a so I could stop clippy from linting the same macro multiple times while being reasonably fast. However, this unfortunately means the lint ignores .. attributes below the crate level. To solve this and other related problems, I propose any of allow a lint to check anything from anywhere in the analysis by moving up the parent chain to check the level allow a lint to opt out of calls for the duration of a specific node including its child nodes add methods to the {Early, Late}LintPass trait, so lints can decide themselves The third option is probably the easiest to implement, yet the most flexible. This would bring the trait closer to other stream parser implementations like SAX.
Seeing that we already have a few, _post methods, I think adding some more will be an acceptable solution here. I'll have a PR shortly.


The documentation of the unstable function makes a reference to , but this function does not exist (anymore?). Expressing the semantics of in terms of something that does not exist is unhelpful. The problem seems to be located . I imagine the fix would involve traveling back in time until before was removed and copying its documentation, after correcting for the differences between it and the function.
Filling drop is a temporary "feature" of rust, and in the long run this function will not be needed once the in-struct drop flags are gone. In anticipation of this improvement, it would be best to not write any code that relies on readanddrop. Edit: Well maybe that's exactly what to have in the docs..
I'm not using that function, I was merely browsing the docs and noticed the documentation was wrong. I would expect the documentation of functions to be correct even if they are unstable and scheduled for removal, unless the removal is scheduled for the immediate future.


In a few places in there are casts from to or for Windows APIs which causes breakage on 64-bit. Some examples I have found so far: () () (rust-lang-nursery/rand, ) There may be more.
Well I didn't find any more so I'll close this.


Travis-CI build failed, my local builds with a slightly older rustc nightly works just fine. This is the repository in question and the Travis-CI build log: Repo: Travis-CI Log: rustc only seems to fail when compiling my crate: Could be related to , a way older and closed issue. (rustc 0.13.0-dev) Backtrace:
cc
Related: arcnmx/cargo-clippy/issues/19


:
Triage: still an issue.
I just hit this, though the error is a bit different now: "resolving bounds after type-checking" rather than "fulfilling during trans". error: internal compiler error: Encountered errors resolving bounds after type-checking note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'Box<Any', stack backtrace: 1: 0x7f91a71b237a - std::sys::imp::backtrace::tracing::imp::write::h944c02ac40aee2d7 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 2: 0x7f91a71c122f - std::panicking::defaulthook::{{closure}}::h6875a2976258b020 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 3: 0x7f91a71c0dcd - std::panicking::defaulthook::h88ffbc5922643264 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 4: 0x7f91a71c16d7 - std::panicking::rustpanicwithhook::ha5aed1dfc0e220e3 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 5: 0x7f91a67fae4b - std::panicking::beginpanic::h264cdc75d51b518b at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 6: 0x7f91a6817d93 - rustc::session::optspanbugfmt::{{closure}}::h4a9b70c3df8b4b3a at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/<panic macros:3 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 7: 0x7f91a6817bb6 - rustc::session::spanbugfmt::h0c5d2225aa96fe42 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 8: 0x7f91a688fc77 - rustctrans::common::fulfillobligation::{{closure}}::{{closure}}::hf13a4d09f7cbb18e at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 9: 0x7f91a688c0dc - rustctrans::common::fulfillobligation::h6bfd7b7f15728b60 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 10: 0x7f91a6887278 - rustctrans::collector::dostaticdispatch::h9456c98c4201c352 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 11: 0x7f91a68868aa - <rustctrans::collector::MirNeighborCollector<'a, 'tcxas rustc::mir::visit::Visitor<'tcx::visitoperand::h7428e8287ff72240 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 12: 0x7f91a6886fe6 - <rustctrans::collector::MirNeighborCollector<'a, 'tcxas rustc::mir::visit::Visitor<'tcx::visitterminatorkind::h8233aed64e4688ea at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 13: 0x7f91a6813387 - rustc::mir::visit::Visitor::visitmir::hc23b408d887d8c09 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 14: 0x7f91a688524c - rustctrans::collector::collectitemsrec::h9535e33b3068eb29 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 15: 0x7f91a68858ff - rustctrans::collector::collectitemsrec::h9535e33b3068eb29 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 16: 0x7f91a686f200 - rustctrans::base::collectandpartitiontranslationitems::{{closure}}::h9f2b052ae16b5f0b at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 17: 0x7f91a686b59f - rustctrans::base::collectandpartitiontranslationitems::h6a325f48a6efa8c7 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 18: 0x7f91a685ddca - rustctrans::base::transcrate::h6e0b0bf1b66798ce at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 19: 0x7f91a7571401 - rustcdriver::driver::phase4translatetollvm::h48ed91c172294403 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 20: 0x7f91a7541c36 - rustcdriver::driver::compileinput::{{closure}}::hf13172fc4e5a2f4d at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 21: 0x7f91a755f503 - rustcdriver::driver::phase3runanalysispasses::{{closure}}::h97a3a12d948df547 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 22: 0x7f91a7558833 - rustcdriver::driver::phase3runanalysispasses::hb0ad9de18d423e67 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 23: 0x7f91a753fb77 - rustcdriver::driver::compileinput::h8e119234b60571d5 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 24: 0x7f91a7585cd8 - rustcdriver::runcompiler::hbdfc4f84e2e0f4b9 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 25: 0x7f91a74a1158 - std::panicking::try::docall::hf679f17bf3b43b0b at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 26: 0x7f91a71cbc1a - _rustmaybecatchpanic at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 27: 0x7f91a74c31b8 - <F as alloc::boxed::FnBox<A::callbox::h506fb5d7b8891cd4 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 28: 0x7f91a71c0094 - std::sys::imp::thread::Thread::new::threadstart::h8084b1107992ae5b at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 29: 0x7f919f3f5709 - start_thread 30: 0x7f91a6e7a82c - clone 31: 0x0 - <unknown
ping how is this unsound?
Given that has seen fit to tag this as a soundness bug I'm nominating it so that it can receive a priority assessment, though I'll second ubsan in asking for a demonstration of the unsoundness here.
In general, having trait bounds that are not checked can lead to unsoundness, since some part of the code will assume that they hold when in fact they do not (consider, e.g., what might happen if the bound were ).
I'm going to mark this as P-medium and tag it from the specialization issue (it is specific to specialization, right?)
triage: P-medium
The code in the OP compiles for me with the latest nightly Rust (1.29.0-nightly ( 2018-08-01)). However, the following still fails (and I assume it's the same issue; if not I can file a new issue): Backtrace:
So I think this is "fixed-by-chalk", but this is fixed-by-chalk in a way that breaks specialization (cc Let's have a more easy-to-understand version of the problem: The problem is the following: our impl needs to prove the where-clause, which in the environment is . holds by (by the impl we are checking), so we can prove that obligation by (which will be a ) that depends on the . Therefore, wfchecking is OK. Therefore, fun. why isn't this a problem every time we have a projection? Normally, rustc normalizes to the real associated type, and then it can't find the , so no problem. With specialization, rustc can't normalize the associated type, so it sees the bug. I can't have a proof for this working, but this seems reasonably likely to work. way that might solve this in the rustc model would be to basically say that for any given trait ref, only the most specialized impl is supposed to be checking the wf requirement (for every trait-ref, there is always a most-specialized impl, so this is OK), and when checking wf, add the associated types for our own impl explicitly to our parameter environment (e.g., add - note no quantification over - to the param env in our example). That will make things normalize and work, and I'm not even sure is particularly ugly. I don't think it is less sound than , but then I don't quite know when is sound. what's going on with Chalk? Last time I saw it, the way we made implied bounds work was to move to the environment - in rustc terms, basically only allow it if we have proven the impl using . This solves the problem, because our impl was proven in a well-formed way, so a will ensure we make progress and there will be no cycles. The reason this does not work in specialization, is that we do want users to be able to prove things like , even while they might not know what is. For that, they need to have a keyed off a . I have no idea how to do this in the Chalk model. Was Chalk changed to do something else by now? Does this have a different interaction with specialization?
A PoC to show the unsoundness of this. It's a use-after free by 'copying' a String: Link to the playground:
This is fixed now: and needs a test


We've always been unsure how much information to show about implementations, and right now, we only show signatures. someone suggested that including the summary line would be helpful, so that you can understand what these things actually do, if you haven't used that particular trait before.
Perhaps we should somehow link to the full description? With a [read more]-like link
Reducing the amount of link chasing necessary to understand what a function does sounds like a good idea, and I agree with that a "read more" link should be included. The question then is how much of the description to include. First sentence? Some arbitrary number of characters?


The following snippet: produces the following error: How is anybody supposed to extract from that one forgot the in the closure? The explanation E0369 doesn't help here. Maybe a better thing for rustc would be to "try" and see if a combination of and would have solved the issue and offer a suggestion of the form "Did you meant to make a reference here?".


Check out in mode : This succeeds (when compiled with optimizations) despite having both a and a . is safe from this because at it believes it's mutably borrowed and panics. There's a line in which would catch this with debug assertions enabled, I believe it should be an ( is unstable and likely not performance critical anyway). cc


. It's been awhile since it's been updated. Here's two changes that haven't been merged into this document yet: Anything else?


Today I learned that eight to the power of eight is zero. Who'da thunk? Incorrect: :arrowright: :x: :arrowright: :x: :arrowright: :x: Correct: :arrowright: overflow :whitecheckmark: :arrowright: overflow :whitecheckmark: :arrowright: overflow :whitecheckmark: Oddly enough, this one breaks the pattern: :arrowright: overflow :whitecheck_mark: Haven't bothered with further cases; at this point it's probably best to just look at the implementation and see what's going on.
was supposed to fix this; looks like it missed the unsigned version?
says that is on nightly.
I meant that fixed this for pow() on signed integers, but not on unsigned integers; it looks like the implementation is copy-pasted for some reason.
Could I take a stab at this?
Sure; feel free to ask if you have questions.
Is overflow checking off in the libcore tests? It'd be nice to be able to write some standard tests for overflow, but they seem to not panic even on cases that should right now.
Overflow checking in unit tests () reflects whether the whole compiler was built in debug or release mode. If you need to specify the overflow mode, you can use a separate test which explicitly specifies , like .
This has since been fixed, in , which it looks like also a test, so closing.


Some days ago, I wrote some code involving char as HashMap key. At that time, char didn't implement the IterBytes trait, so I implemented it locally myself. After updating rust, my code failed to compile with a somewhat less than obvious error. Example: Produces the following errors: Note that there is no way to know that the problem is the duplicate implementation of IterBytes.
Reproduced as of
Bumping to 0.7, though.
Not critical for 0.7. Nominating for milestone 5, production-ready.
accepted for production-ready milestone
Still reproduces: It has a bunch of other non-bug errors too, but it still exhibits this bug.
Accepted for P-high.


From: src/test/compile- Error E0164 needs a span_label, updating it from: To:


Here is a minimum example of the problem. Compilation fails with following error. Which means that the fragment qualifier is not taken into account to choose which variant of the macro is to be used.
Yeah, macros don't do backtracking. You'll need to adjust the matchers to provide some other way to disambiguate.
Yes, I obviously know that I could just put brackets or whatever around one of the patterns to make it distinct. But the whole point of having fragment qualifiers is precisely to distinguish between two otherwise identical patterns. If macros cannot do it although they have the perfect tool for it, then they are stupid and ought to be improved.
It wasn't obvious to me that you knew the workaround -- sorry for assuming! Also see .
Thanks for pointing the PR. It is blocked for now, but I suppose there is still hope. Sorry for being harsh. I have been raging for months over how annoyingly limited and stupid Rust macros are, and I finally found a case general and obvious enough to justify my complaining…
triage: Macros still don't backtrack. I can't find an issue for that, though I do suspect that one exists in some form. Labeling as A-macros, though.
here is (closed).
Closing in favor of -- macro rules do not backtrack.


Can you provide more assistance in debugging as well? For example what was at line 896 of What configuration did you provide? etc.
Relevant line is a part of At that point anything pertaining i686 in my were Replacing with does still result in the same error. For now, I just specified for 32 bit version of LLVM I have, which works.
Ah ok, thanks for the info! Right now this should be a better error (of course) but the cause is how rustbuild treats the and arrays in the configuration. No C++ compilers are found for the array, so you can't request any host-related targets (e.g. LLVM) when a triple is only mentioned in the array. You can fix this by moving the target to the array.


Inlined from Another issue. If a struct has two different custom derives on it and the second one panics, the error span will point to the first one, not the one which panicked. Reproduction Script
was "Reproduction Script" supposed to be a link? I'm spinning this off from as I don't think it's going to block stabilization and/or closing that issue.
Reproduction script there is a summary tag
<details<summaryReproduction Script</summaryIn a crate called In another crate The error will highlight even though panicked. </details
This seems to be fixed now, so this issue can be closed.
I ran this as a test, and got the following output:


Today when you compile for a target that does not exist rustc gives the standard message for failing to find a crate, for . We can and should be more explicit about what this means. Actually what is almost certainly happening is that you don't have that target installed: It could instead say: A reasonable heuristic for printing this might be if the crate is named or and the sysroot is not overridden.
When I run on I get the error:
I would like to try my hand at this if no one else has picked it up already. I am fairly new to rust, so I might need some assistance getting the pull request into a something resembling a reasonable state.


So I tried to compile core and I get this errors from assembler: the code on line 9468 looks like this: I tried both (4.6.3) and (5.3.0) and both give the same errors. Then I've renamed symbol to in assembly and it compiled successfully. I think msp430 assembler just does not like character in symbol names. So I see 2 options: MSP430 target in LLVM so it will rename symbols with  to not emit on MSP430


Vec::withcapacity(u64) panics. Error message: rustc -v error: internal compiler error: ../src/librustctypeck unexpected definition: PrimTy(TyUint(u64)) note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: thread 'rustc' panicked at 'Box<Any', note: Run with for a backtrace. Minimal program: fn main() { let vec = Vec::with_capacity(u64); }
Duplicate of and , fixed in . /cc
Closing as a duplicate, thank you!


Compiling this code: Gives me the following error The error is not limited to just the i32 type. : rustc 1.15.0-nightly ( 2016-12-05) binary: rustc commit-hash: commit-date: 2016-12-05 host: x8664-unknown-linux-gnu release: 1.15.0-nightly LLVM version: 3.9 Backtrace:
Duplicate of , fixed in
Closing as duplicate, thanks!


Test case: Compiles successfully on , causes an ICE on . Diff contains only , CC Found while trying to minimize , but filed separately since the error message is different and this one has a small test case.
Do you have a backtrace?
Yes of course. Sorry I forgot to include it: rust error: internal compiler error: attempted .defid() on invalid def: Err note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'Box<Any', stack backtrace: 1: 0x7fc35e73fdf3 - std::sys::imp::backtrace::tracing::imp::write::hdfa3e34b856f69a3 2: 0x7fc35e74e5dd - std::panicking::defaulthook::{{closure}}::h20f8c1082e0ce86e 3: 0x7fc35e74e17b - std::panicking::defaulthook::hd31552ac08c2a241 4: 0x7fc35e74ea68 - std::panicking::rustpanicwithhook::h73969d230a072c1a 5: 0x7fc357eda667 - std::panicking::beginpanic::hb89a2261f4776ce3 6: 0x7fc357eef99f - rustcerrors::Handler::bug::h13b3b29154320abd 7: 0x7fc35bab053a - rustc::session::optspanbugfmt::{{closure}}::hfea18dd68f59976d 8: 0x7fc35baafff7 - rustc::session::optspanbugfmt::h7d370a0810dbdbbd 9: 0x7fc35baafce2 - rustc::session::bugfmt::hcde5f50c54004a4f 10: 0x7fc35b984552 - rustc::hir::def::Def::defid::h728c22aafbe84efc 11: 0x7fc35c6ddb3a - rustcprivacy::ObsoleteVisiblePrivateTypesVisitor::pathisprivatetype::h24756a49a68d1da9 12: 0x7fc35c6d53db - rustc::hir::intravisit::walkty::h64b13c0c45b7a09a 13: 0x7fc35c6d49ba - rustc::hir::intravisit::Visitor::visitfn::ha8ad665c42b1d643 14: 0x7fc35c6de7cf - <rustcprivacy::ObsoleteVisiblePrivateTypesVisitor<'a, 'tcxas rustc::hir::intravisit::Visitor<'tcx::visititem::hae9f32c7942ccca1 15: 0x7fc35c6deab5 - <rustcprivacy::ObsoleteVisiblePrivateTypesVisitor<'a, 'tcxas rustc::hir::intravisit::Visitor<'tcx::visititem::hae9f32c7942ccca1 16: 0x7fc35c6e1b7a - rustcprivacy::checkcrate::h5ba75e3c4ebe0690 17: 0x7fc35eaef747 - rustcdriver::driver::phase3runanalysispasses::{{closure}}::h388b9236cf305089 18: 0x7fc35ead66d6 - rustcdriver::driver::phase3runanalysispasses::h080c1a734c4f2909 19: 0x7fc35eac5425 - rustcdriver::driver::compileinput::hab55539b85c4ceed 20: 0x7fc35eb0ea51 - rustcdriver::runcompiler::h128b89b79f649304 21: 0x7fc35ea236fb - std::panicking::try::docall::h15bca94dda232804 22: 0x7fc35e757b06 - rustmaybecatchpanic 23: 0x7fc35ea44d01 - <F as alloc::boxed::FnBox<A::callbox::h8832766c4bda585b 24: 0x7fc35e74d470 - std::sys::imp::thread::Thread::new::threadstart::h7d03d727f96da002 25: 0x7fc357684453 - startthread 26: 0x7fc35e4147de - GI__clone 27: 0x0 - <unknown
triage: P-high Seems bad. Assigning to based on bisection.
Fixed in .


While digging around for something else I have just discovered that setting the UID for a subprocess with also causes a call to in the child. This should be documented. (Related to )
re-tagging as ; would you like this to appear in the docs, or not? If so, we're happy to do it, but want to make sure to not over-specify.
This seems like something we should document, yes. It's an unusual special-case that people should be aware of. This also interacts with .
Ok, this is ready for a PR. I've labeled it accordingly.
hi! It may be a long time now but may I ask if this issue is still needed? Because I can't find the call anywhere. I looked it as follows: Did I lookup the wrong function and structs?


broke a library of mine where I had code like this: calls that used to call this trait method now call the new inherent method, but since that’s unstable the crate didn’t build until I . After that I could remove the trait since the new method has the same behavior. Anyway, this is just FYI. If we don’t want this kind of breakage we can’t add any new method to existing types ever, so that doesn’t sound viable. If the new method had had different behavior or if I wanted to keep supporting older compilers, it wouldn’t be too hard to rename my trait’s method or use UFCS.
Yeah in general we reserve the right to break downstream code with differences in method resolution because the downstream code can always be written in an "elaborated" form which works on all compilers (e.g. using ufcs). If a change to the standard library breaks an excessive amount of code in the ecosystem, though, then we'd need to take the steps much more purposefully.
Sounds good. Again, I don’t expect anything to change here and only made the previous comment to let people know this happened. I made this particular crate as an experiment, I don’t know of anyone actually using it.
Given that the core changes to the bounds on existing methods were instantly stable, it doesn't make a lot of sense to keep and as unstable. I propose we immediately stabilize these APIs. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
ping (checkbox)
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
What’s the next step here? Batch stabilization PR near the end of the release cycle?
Yep, I'm preparing one right now.


Hi, at this point, rust nightly pretty much builds out of the box (assuming you have an already built beta rustc compiler) on Solaris for x86_64. However, it doesn't (yet) build for sparcv9. I will provide a pull request shortly that adds the final, missing piece to support sparcv9 / Solaris.


is this code: yielding:
. I don't know why we do this, the "else" part of "if" or "if-let" is an arbitrary expression: This seems simpler, less error prone and it won't hit arbitrary limitations specific to guards.
The RFC states: This doesn't feel like a compelling reason, particularly since the desugaring is not otherwise user visible. I would call this a bug.
triage: P-medium
This is a great mentoring bug! I'm going to write up some very quick pointers for now. Please reach out for more details. In short, the code that needs to be changed is in the "HIR lowering", which converts from the AST (what the user wrote) to the compiler's internal HIR (also an abstract syntax tree, but somewhat desugared). The code in question is in , specifically right . There is also some more logic. You'll want to change how it is desugaring along the lines that suggested .
I'm interested in taking this bug.
Hello I'm new to open source and Rust project. I wanted to contribute to the project. May I work on this bug?
Sure thing! Let us know how far you get with We're also on IRC.
I'll yield to you -- good luck!
If IfLet expression is desugared to the one shown in desugar_test() then it works as suggested by I have also reproduced the bug after desugaring the expression.


fails on emscripten with the following error message: Thus the test is currently ignored on emscripten. Note: it may be that the failure occurs only on when the test is compiled with optimizations. Note: this happens when using LLVM 4.0 (this issue was opened now to get an issue number to reference).


hi, my code used to compile last week. I updated the compiler today and now it crashes note that you can get my code here ()
note: going back to nightly-2017-04-01; everything work again. 'nightly-2017-04-17 is not ok. so troubles started somewhere in between.
cc
not too sure what to do with this message. can I help you with something ? I can do a small dichotomy to figure out the last working nightly if this can help.
Minified:
there is a pending fix (), no action needed on your part
triage: P-high


running yields Happening on . Did not happen on the latest nightly available through rustup on 27.04.2017.
Last working nightly: First broken nightly: .
maybe it was ? cc
could be. let me try it on my big MIR refactoring branch =)
I confirm that the error occurs at but not at So it looks to me like is indeed the culprit.
Yes. I can reproduce. Will investigate.
I see the problem. PR coming soon.
Fix at
I'm still seeing this issue, on the latest nightly and on master.
can you give more details of how you are reproducing the problem? (I a test for the precise scenario reported, so I'm reasonably sure it's not that case anymore.)
Hmm, perhaps my regression test wasn't sufficient. I see I used ; I remember that the test did fail, but I guess that it passing doesn't prove all issues are resolved. =)
The earliest commit where I can reproduce this problem is


cc Maybe related to
Also affects eclectica-0.0.9 cc
Also igo-0.2.1 cc
Also isbfc-0.0.1 cc
Also cargo-update-0.8.0 () cc
Also cc
Rust commit: (looks like bug isn't here) Cargo commit: , which seems correct. is the stable/nightly issue, is the PR updating cargo submodule to fix this, which probably needs to be backported to beta. I'm uncertain, though.
cc sorry to tag you in again, but if you could help take a look at this that'd be great! If not no worries!
Hi this definitely looks related to my changes in cargo. I've investigated and this crate defines two bins ( and ). I suppose they were intended to be aliases and this was possible because of a original "bug" in cargo (falling back to ). I have mixed feelings about this. I would say that cargo should fail here instead of falling back to , but I suppose we cannot do that because of backwards compatibility. Right? fails because it defines bin targets inside directly, instead of . Seems easy and I'll try to fix this today in the evening. Could you please provide me with the cargo's output for the other crates (especially )? That would be great.
Ah yeah for now our priority is to stem the breakage, and afterwards we can evaluate warnings cycles/etc to push further towards the desired behavior here. Thanks for investigating this
I think I have fixed this, just need one more day to do some more testing and I should open a pull request tomorrow.
Added a proposed fix.
Ah we should actually leave this open to track the inclusion into beta, I'll close when all the backports are done.
Ok I've , updated our and updated our , this'll get closed when those start merging. Thanks again for fixing this
Ok, I think everything's landed here


About to submit a PR for exposing intrinsics::needs_drop under mem. Needs a tracking issue. Here it is!
The PR is
fcp merge Seems like this may be good to stabilize!
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.


Test case: Compiling this stuck forever in the "expansion" pass. cc ( tracking issue). Since can match "nothing", the macro should error with "repetition matches empty token tree".


Trying to natively build powerpc64 as of , I get an ICE in stage 1:
FWIW beta () builds fine. I'll see if I can bisect it.
I seem to be hitting unrelated issues when bisecting, so it may be regressing in and out lately... It still ICEs on powerpc64 as of . I found that powerpc64le builds fine though, so this could be a general big-endian issue. If I get time I'll try s390x. Also, the reported region sometimes changes, though still the same location. Most often I get: error: internal compiler error: Region parameter out of range when substituting in region 'b (root type=Some((&&'b str,))) (index=1) But a few times I've seen: error: internal compiler error: Region parameter out of range when substituting in region 'a (root type=Some((str::pattern::StrSearcher<'a, 'b,))) (index=0) And the backtraces are still useless...
Could you post the results of ?
That's doing a rebuild from the working dir of my prior attempts, so the only interesting piece is the stage1 libcore that ICEs. If you want the log of a complete build from scratch, I can get that too.
I'm seeing a different error: Could you compile with debuginfo to get a backtrace? That's the setting in
Fresh build directory, debuginfo enabled: error: internal compiler error: Type parameter (T/0) out of range when substituting (root type=Some((&mut [T], _))) substs=[] Same dir just building again: error: internal compiler error: Region parameter out of range when substituting in region 'a (root type=Some((str::pattern::StrSearcher<'a, 'b,))) (index=0)
Very odd. rustc compiled on x86-64 (both a rustc I hand-compiled and the official nightlies) works without any problems, but rustc compiled on powerpc64 crashes with all sorts of random errors. I wonder whether there is some sort of LLVM bug - the next beta uses LLVM 4.0.1, so I should check whether that fixes things. Also, there shouldn't be any LLVM IR differences between a rustc compiled on powerpc and a rustc compiled on x86, so maybe I could do a diff
We've seen weird differences between cross- and native-compiled rustc before for big-endian machines, which seems confirmed by powerpc64le working fine here. I'm still trying to get s390x access... cc who has found a few of these.
The usual problem is that cross-compiled and native-compiled metadata end up being incompatible, so an x86-built ppc64 libcore is incompatible with a ppc-built ppc64 libcore. Through maybe we've ended up in a case where ppc can't decode its own metadata.
Yes, my first suspect would be endianness issue. It could be fairly plausible that the metadata decoder is correct, but the encoder is not, hence the bug showing up on ppc-built stuff only.
I got an s390x build, and it fared even worse. Tons of move errors on types like this: before it finally ICEd: thread 'rustc' panicked at 'assertion failed: (Qualif::MUTABLEINTERIOR)', I'm guessing that these particular errors and ICEs are not significant in themselves, only as signs of some more general corruption.
Oddly enough, if I use an x86 stage0 to compile a powerpc stage1, or an powerpc stage0 to compile an x86 stage1, everything works fine, but if I use a powerpc stage0 to compile a powerpc stage1, the powerpc stage1 created is broken.
I can't figure out a good way to debug this without a powerpc computer. So I'm gotta leave this alone unless anyone's going to help me track it down (e.g., ssh access to a fast(!) powerpc computer).
I don't know if I can provide any machine access -- I'll check -- but I will keep working on this myself. Any tips for how to approach this? I tried valgrind, but I got so many errors that I think either I'm using it wrong or that build is just hopelessly broken.
Bisecting took me to 's merge commit . The parent commit builds fine. I didn't drill down into the individual commits for that PR, as it just seems to be iterating different ideas. If you look on master, also moved that code to to use in more places. I don't know what that code would have to do with endianness or cross-compiling weirdness per se, but I do worry about the memory alignment of these: Later the temp block gets cast to , as do the input pointers in the first place, which would seem to imply that alignment won't matter. But if is still having an effect as stated, then I worry that perhaps the extra alignment constraints are just being assumed in the code generated to move between , , and . The input could have a smaller alignment than .
I replaced with a naive byte-byte swap on master, and it works! Now to figure out the right fix...
Just removing that gets a working build! Regarding endianness and cross-compiling, could there be a bug in the way the simd type is translated to LLVM? Especially since it's being seen through a pointer. I'm going to do some comparisons of the builds with and without that . if it would help, I could share those builds somewhere for you to grab.
cc since I'm blaming your PRs...
Affects both powerpc64le and powerpc64 in Debian now: Correction, the latest upload for ppc64 builds fine:
The Debian bug is little-endian not big-endian. This bug is the other way around, and is very old.
Right, the failure on big-endian was a different one for the previous 1.30 upload to experimental.
Er for the record, no the previous beta-7 was also problematic for little-endian but OK for big-endian - the big-endian one , otherwise it would be fine (20 test failures). Anyway we have some clues on the other bug, more comments there.
Isn't this bug fixed by ? - i.e., what is the Rust situation on powerpc?
This is likely fixed. Rust 1.32.0 succeeded on ppc64el, see
This bug is on big-endian, the link you pasted is little-endian, but if you remove the "el" at the end of the URL you get to the big-endian results which are also OK. We do things slightly differently from Fedora though.
do you know what the status on Fedora is?
It was "fixed" by by disabling SIMD in that function -- not really a satisfactory solution IMO. So in that sense, we don't have any issue on Fedora any more. But perhaps we should see what happens to codegen these days if we revert that and try allowing SIMD there again. edit: to be clear -- I will try changing that back myself to see what happens.


The fix is shown in , but I couldn't complete it because the line length linter doesn't like the long lines and didn't have enough time to adjust the tidy checker