Uh oh!
There was an error while loading. Please reload this page.
Rebase to 1.37 - #8
Merged
Merged
Conversation
Co-Authored-By: Taiki Endo <te316e89@gmail.com> Co-Authored-By: Jonas Schievink <jonasschievink@gmail.com> Co-Authored-By: Torbjørn Birch Moltu <t.b.moltu@lyse.net>
Rollup of 7 pull requests Successful merges: - rust-lang#61814 (Fix an ICE with uninhabited consts) - rust-lang#61987 (rustc: produce AST instead of HIR from `hir::lowering::Resolver` methods.) - rust-lang#62055 (Fix error counting) - rust-lang#62078 (Remove built-in derive macros `Send` and `Sync`) - rust-lang#62085 (Add test for issue-38591) - rust-lang#62091 (HirIdification: almost there) - rust-lang#62096 (Implement From<Local> for Place and PlaceBase) Failed merges: r? @ghost
Lexer uses Symbols for a lot of stuff, not only for identifiers, so the "name" terminology is just confusing.
This avoids reserving storage in generators for locals that are moved out of (and not re-initialized) prior to yield points.
rustc: correctly transform memory_index mappings for generators. Fixesrust-lang#61793, closesrust-lang#62011 (previous attempt at fixing rust-lang#61793). During rust-lang#60187, I made the mistake of suggesting that the (re-)computation of `memory_index` in `ty::layout`, after generator-specific logic split/recombined fields, be done off of the `offsets` of those fields (which needed to be computed anyway), as opposed to the `memory_index`. `memory_index` maps each field to its in-memory order index, which ranges over the same `0..n` values as the fields themselves, making it a bijective mapping, and more specifically a permutation (indeed, it's the permutation resulting from field reordering optimizations). Each field has an unique "memory index", meaning a sort based on them, even an unstable one, will not put them in the wrong order. But offsets don't have that property, because of ZSTs (which do not increase the offset), so sorting based on the offset of fields alone can (and did) result in wrong orders. Instead of going back to sorting based on (slices/subsets of) `memory_index`, or special-casing ZSTs to make sorting based on offsets produce the right results (presumably), as rust-lang#62011 does, I opted to drop sorting altogether and focus on `O(n)` operations involving *permutations*: * a permutation is easily inverted (see the `invert_mapping` `fn`) * an `inverse_memory_index` was already employed in other parts of the `ty::layout` code (that is, a mapping from memory order to field indices) * inverting twice produces the original permutation, so you can invert, modify, and invert again, if it's easier to modify the inverse mapping than the direct one * you can modify/remove elements in a permutation, as long as the result remains dense (i.e. using every integer in `0..len`, without gaps) * for splitting a `0..n` permutation into disjoint `0..x` and `x..n` ranges, you can pick the elements based on a `i < x` / `i >= x` predicate, and for the latter, also subtract `x` to compact the range to `0..n-x` * in the general case, for taking an arbitrary subset of the permutation, you need a renumbering from that subset to a dense `0..subset.len()` - but notably, this is still `O(n)`! * you can merge permutations, as long as the result remains disjoint (i.e. each element is unique) * for concatenating two `0..n` and `0..m` permutations, you can renumber the elements in the latter to `n..n+m` * some of these operations can be combined, and an inverse mapping (be it a permutation or not) can still be used instead of a forward one by changing the "domain" of the loop performing the operation I wish I had a nicer / more mathematical description of the recombinations involved, but my focus was to fix the bug (in a way which preserves information more directly than sorting would), so I may have missed potential changes in the surrounding generator layout code, that would make this all more straight-forward. r? @tmandry
…r=nikomatsakis Clean up MIR drop generation * Don't assign twice to the destination of a `while` loop containing a `break` expression * Use `as_temp` to evaluate statement expression * Avoid consecutive `StorageLive`s for the condition of a `while` loop * Unify `return`, `break` and `continue` handling, and move it to `scopes.rs` * Make some of the `scopes.rs` internals private * Don't use `Place`s that are always `Local`s in MIR drop generation Closesrust-lang#42371Closesrust-lang#61579Closesrust-lang#61731Closesrust-lang#61834Closesrust-lang#61910Closesrust-lang#62115
This commit turns off PR builds happening on Travis, instead entirely relying on Azure for PR builds to succeed.
The PR builder on Azure currently takes 2.5h which is a bit long, so this commit disables debug assertions and llvm assertions in an attempt to speed up that builder and have PR builds come back a bit more quickly. Other builders continue to enable debug assertions and test the compiler there.
This commit switches the `try` builers to officially happen on Azure Pipelines instead of Travis where they're currently run. This also cuts back the number of builders to just the two we run on Travis, leaving expansion as a possible future extension.
This commit moves toolstate publishing from Travis to Azure. We've been testing on azure for some time now and this works by deleting the Travis config and updating the credentials used on Azure.
Manually make sure that we do the same thing across all the services, uncovering one spot where we needed to pass one more configure flag on Azure but otherwise we're good to go!
…roalbini ci: Turn off PR builds on Travis This commit turns off PR builds happening on Travis, instead entirely relying on Azure for PR builds to succeed.
…troalbini ci: Disable assertions in PR builds The PR builder on Azure currently takes 2.5h which is a bit long, so this commit disables debug assertions and llvm assertions in an attempt to speed up that builder and have PR builds come back a bit more quickly. Other builders continue to enable debug assertions and test the compiler there.
ci: Switch official `try` builds to happen on Azure This commit switches the `try` builers to officially happen on Azure Pipelines instead of Travis where they're currently run. This also cuts back the number of builders to just the two we run on Travis, leaving expansion as a possible future extension.
ci: Publish toolstate changes from Azure This commit moves toolstate publishing from Travis to Azure. We've been testing on azure for some time now and this works by deleting the Travis config and updating the credentials used on Azure.
…bini ci: Sync AppVeyor/Travis with Azure configuration Manually make sure that we do the same thing across all the services, uncovering one spot where we needed to pass one more configure flag on Azure but otherwise we're good to go!
Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>
…me-elision-2-beta, r=Centril
[beta] Rollup backports Cherry picked: * Updated RELEASES.md for 1.37.0 rust-lang#63147 * Require a value for configure --debuginfo-level rust-lang#62906 * Make the parser TokenStream more resilient after mismatched delimiter recovery rust-lang#62887 * ci: move .azure-pipelines to src/ci/azure-pipelines rust-lang#63242 Rolled up: * [BETA] Update cargo rust-lang#62911 * [beta] Backport rust-lang#61207rust-lang#63254 r? @ghost
…imulacrum 1.37.0 stable This promotes beta to stable and backports a few PRs: - Avoid ICE when referencing desugared local binding in borrow error (rust-lang#63051) - Don't access a static just for its size and alignment (rust-lang#62982) via 331e09b143aebfcf82dc1f9b69b31ee0083cbf0b
lexxvir
commented
Sep 18, 2019
Hi @MabezDev, I've built rust compiler from your Also I notice that there is no need to patch rustc to "cut off" global allocator stuff (see lexxvir@7b2dbe6 and MabezDev/xtensa-rust-quickstart#2). |
bjoernQ
commented
Sep 18, 2019
Hi @MabezDev , great to see you continue working on this. Unfortunately I'm on Windows and the latest version of llvm-xtensa crashes on my machine - so I first have to solve that problem - maybe I'll go for Linux for now but that might take time. But since @lexxvir already extensively tested it I think this PR is fine. I hope to get a running xtensa-rust based on 1.37 soon again |
MabezDev
commented
Sep 18, 2019
MemberAuthor
My rust projects all still work with this pr so I will merge this now, thanks for the feedback! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Addresses #7
Before I merge, I'd like to get some feedback on anything that breaks for their workflow.
cc: @lexxvir@bjoernQ