Update to rust master (LLVM 8.0) #115
Conversation
This script invokes the gdbgui graphical GDB front-end with the Rust pretty printers loaded. The script does not install gdbgui, that must be done manually.
Add some more wording to module documentation regarding how
`Arc::clone()` works, as some users have assumed cloning Arc's
to work via dereferencing to inner value as follows:
use std::sync::Arc;
let myarc = Arc::new(1);
let myarcref = myarc.clone();
assert!(1 == myarcref);
Instead of the actual mechanic of referencing the existing
Arc value:
use std::sync::Arg;
let myarc = Arc::new(1);
let myarcref = myarc.clone();
assert!(myarcref == &myarc); // not sure if assert could assert this
in the real world
Make it clearer that `Arc::clone()` in fact creates a whole new Arc with the internal pointer pointing to the same location as the source Arc.
…th the feature gate active
Rollup of 9 pull requests Successful merges: - rust-lang#53076 (set cfg(rustdoc) when rustdoc is running on a crate) - rust-lang#53622 (cleanup: Add main functions to some UI tests) - rust-lang#53769 (Also link Clippy repo in the CONTRIBUTING.md file) - rust-lang#53774 (Add rust-gdbgui script.) - rust-lang#53781 (bench: libcore: fix build failure of any.rs benchmark (use "dyn Any")) - rust-lang#53782 (Make Arc cloning mechanics clearer in module docs) - rust-lang#53790 (Add regression test for issue rust-lang#52060) - rust-lang#53801 (Prevent duplicated impl on foreign types) - rust-lang#53850 (Nuke the `const_to_allocation` query)
…oats Add Error::source method per RFC 2504. This implements part of RFC 2504. * Adds `Error::source`, a replacement for `Error::cause` with the "right" signature, which will be instantly stable. * Deprecates `Error::cause` in 1.33 (this choice was based on the precedent in rust-lang#52994, which we haven't finalized). * Redefines `Error::cause` to delegate to `Error::source` (the delegation can only go in this direction, not the other). @rfcbot fcp merge
refactor match guard This is the first step to implement RFC 2294: if-let-guard. Tracking issue: rust-lang#51114 The second step should be introducing another variant `IfLet` in the Guard enum. I separated them into 2 PRs for the convenience of reviewers. r? @petrochenkov
Various small diagnostic and code clean up - Point at def span on incorrect `panic` or `oom` function - Use structured suggestion instead of note for `+=` that can be performed on a dereference of the left binding - Small code formatting cleanup
Fix of bug introduced by rust-lang#53762 (tool_lints) Before implementing backwards compat for tool lints, the `Tool` case when parsing cmdline lints was unreachable. This changed with rust-lang#53762. This fix is needed for rls test-pass. (@nrc) r? @Manishearth
|
I fixed the issue introduced while rebasing (see #92 (comment)) and can now indeed compile stock |
|
Note that we are unlikely to actually merge this — we tend to just rebase and force-push master since the project as a whole is in such an unstable state. This helps keep the master branch closer to the final PR(s) that we will eventually make. |
|
I see there's some LLVM submodule updates — have all of those changes been isolated into some state to be submitted into LLVM master? @dylanmckay can push directly to LLVM, as I understand it, so once we have PRs and tests they can start being upstreamed. |
Sure, that's fine.
There are currently five independent patches in separate commits, each to fix one issue reported in this repo. Some are published on reviews.llvm.org. Which issue / review number is linked from the individual commit messages. I believe that the three AVR specific patches can be more or less submitted as-is, although they should be reviewed by someone with more LLVM knowledge. The two general LLVM patches (which are also the ones published on reviews.llvm.org) I'm not really sure about. |
|
So, today I managed to actually compile and flash a program (that would blink SOS on panic) to an Arduino Leonardo 🎉. There appear to be some outstanding issues (missing things from [profile.release]
panic = "abort"
codegen-units = 1
lto = true1: some symbols are missing (the most serious ones are probably 32 bit shifts), another instance of "ran out of registers" when attempting to implement 128 division, and likely some incorrect calling conventions. |
|
Wow, this is great! I mean, really great! Thanks @TimNN Thanks for [adding support for the program memory data layout field])34e01a2), now I don't have to! Also, I'm going to be pretty inactive the next two weeks or so, exam period. I have no problems delegating commit decisions (like whether this is ready to be force-pushed to
I can do that, although it'll be in 2~weeks. I guess, we have to maintain a custom fork anyway so long as |
That's so much cooler than my lame
That's one particularly curly bug, described at avr-llvm/llvm#163. |
|
Raised #116 to track all the LLVM patches to be upstreamed. Assigned to myself. |
Note that by now, it is extremely easy to add the missing symbols to |
|
I got enough stuff compiling again that my pure Rust (and a tiny bit of assembly) code with blinking the LED and two-way serial communication is back up and running. Next will be checking the official AVR blink and then ensuring the two branches have the same interesting commits. |
|
I've pushed up the forked LLVM and force-pushed this code (more-or-less) to the avr-support branch, thanks so much! |
Better diff of the changes.
This PR contains all the patches (somewhat cleaned up) that I've been using to test compiling stock
libcore.With this PR, I can compile stock
libcorewith all-C opt-levels except1(that is, with0,2,3,sandz).