Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 8 pull requests #62372

Closed

Conversation

Mark-Simulacrum
Copy link
Member

Successful merges:

Failed merges:

r? @ghost

nitnelave and others added 30 commits June 24, 2019 23:11
So far it is assumed that using a DLL as a -l parameter argument is ok,
but the assumption doesn't hold when compiling the native code with
llvm.
In which case, an import library is required, so let's build one
This also requires the cargo counterpart to add the import library in
the stamp files, at least when compiling libstd. Otherwise, the files
don't get uplifted
So that uwp-windows-gnu also gets its startup objects built
libgcc's support is using forbidden functions
As Rtl* functions are not allowed there
Attempt to create sockets with the WSA_FLAG_NO_HANDLE_INHERIT flag, and
handle the potential error gracefully (as the flag isn't support on
Windows 7 before SP1)
Or rather expose it, but always return an error
The required functions are not available, so hope for the best
This avoids adding archives multiple times, which results in duplicate
objects in the resulting rlib, leading to symbol collision and link
failures. This could happen when crate contains multiple link attributes
that all reference the same archive.
The reader itself doesn't need ability to peek tokens, so it's better
if clients implement this functionality.

This hopefully becomes especially easy once we use iterator interface
for lexer, but this is not too easy at the moment, because of buffered
errors.
matklad and others added 16 commits July 4, 2019 09:08
Add support for UWP targets

Hi,

This pull request aims at adding support for UWP (Universal Windows Apps) platform.
A few notes:
- This requires a very recent mingw-w64 version (containing this commit and the previous related ones: mirror/mingw-w64@e8c433c#diff-eefdfbfe9cec5f4ebab88c9a64d423a9)
- This was tested using LLVM/clang rather than gcc, and so far it assumes that LLVM/clang will be the native compiler. This is mostly due to the fact that the support for exceptions/stack unwinding for UWP got much more attention in libunwind
- The "uwp" part of the target needs support for it in the `cc-rs` & `backtrace-rs` crates. I'll create the MR there right after I submit this one and will link everything together, but I'm not sure what's the correct way of dealing with external dependencies in the context of rust
- Enabling import libraries and copying them across stages requires a change in cargo, for which I'll open a MR right after I submit this one as well
- The i686 stack unwinding is unsupported for now, because LLVM assumes SjLj, while rust seems to assume SEH will be used. I'm unsure how to fix this

Also, this is my first encounter with rust, so please bear with my code, it might not feel so idiomatic or even correct :)

I'm pretty sure there's a way of doing things in a cleaner way when it comes to win/c.rs, maybe having a UWP & desktop specific modules, and import those conditionally? It doesn't feel right to sprinkle `#[cfg(...)]` all over the place

Off course, I'll gladly update anything you see fit (to the extent of my abilities/knowledge :) )!

Thanks,
Add debug assertions to write_bytes and copy*

Looks like @nitnelave  went MIA in rust-lang#58783, so I am re-submitting their PR, tweaked just a bit. I took care to preserve commit authorship.

Cc rust-lang#53871
…es, r=cramertj

Check if the archive has already been added to avoid duplicates

This avoids adding archives multiple times, which results in duplicate
objects in the resulting rlib, leading to symbol collision and link
failures. This could happen when crate contains multiple link attributes
that all reference the same archive.
…mertj

Move `async || ...` closures into `#![feature(async_closure)]`

The `async || expr` syntax is moved out from `#![feature(async_await)]` into its own gate `#![feature(async_closure)]`.

New tracking issue: rust-lang#62290

Closes rust-lang#62214.

cc rust-lang#62149

r? @varkor
Remove support for 1-token lookahead from the lexer

`StringReader` maintained `peek_token` and `peek_span_src_raw` for look ahead.

`peek_token` was used only by rustdoc syntax coloring. After moving peeking logic into highlighter, I was able to remove `peek_token` from the lexer. I tried to use `iter::Peekable`, but that wasn't as pretty as I hoped, due to buffered fatal errors. So I went with hand-rolled peeking.

After that I've noticed that the only peeking behavior left was for raw tokens to test tt jointness. I've rewritten it in terms of trivia tokens, and not just spans.

After that it became possible to simplify the awkward constructor of the lexer, which could return `Err` if the first peeked token contained error.
@Mark-Simulacrum
Copy link
Member Author

@bors r+ p=30

@bors
Copy link
Contributor

bors commented Jul 4, 2019

📌 Commit 866233b has been approved by Mark-Simulacrum

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Jul 4, 2019
@bors
Copy link
Contributor

bors commented Jul 4, 2019

⌛ Testing commit 866233b with merge 75a2f8b2c00b7c2fa8ab229ddc0856bea06fb06e...

@bors
Copy link
Contributor

bors commented Jul 4, 2019

💔 Test failed - checks-azure

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jul 4, 2019
@RalfJung
Copy link
Member

RalfJung commented Jul 4, 2019

On armhf-gnu:

---- [run-pass] run-pass/debuginfo-lto.rs stdout ----

error: test compilation failed although it shouldn't!
status: exit code: 1
command: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/src/test/run-pass/debuginfo-lto.rs" "-Zthreads=1" "--target=arm-unknown-linux-gnueabihf" "--error-format" "json" "-Zui-testing" "--out-dir" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-pass/debuginfo-lto" "-Crpath" "-O" "-Zunstable-options" "-Lnative=/checkout/obj/build/arm-unknown-linux-gnueabihf/native/rust-test-helpers" "-Clinker=arm-linux-gnueabihf-gcc" "-C" "lto" "-g" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-pass/debuginfo-lto/auxiliary"
stdout:
------------------------------------------

------------------------------------------
stderr:
------------------------------------------
error: linking with `arm-linux-gnueabihf-gcc` failed: exit code: 1
   |
   = note: "arm-linux-gnueabihf-gcc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/arm-unknown-linux-gnueabihf/lib" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-pass/debuginfo-lto/debuginfo-lto.debuginfo_lto.7rcbfp3g-cgu.1.rcgu.o" "-o" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-pass/debuginfo-lto/debuginfo-lto" "-Wl,--gc-sections" "-pie" "-Wl,-zrelro" "-Wl,-znow" "-Wl,-O1" "-nodefaultlibs" "-L" "/checkout/obj/build/arm-unknown-linux-gnueabihf/native/rust-test-helpers" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-pass/debuginfo-lto/auxiliary" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/arm-unknown-linux-gnueabihf/lib" "-Wl,--start-group" "-Wl,-Bstatic" "/tmp/rustcwZ9vAg/libbacktrace_sys-69828ba5b177f6e2.rlib" "-Wl,--end-group" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/arm-unknown-linux-gnueabihf/lib/libcompiler_builtins-34ad96caca8cd606.rlib" "-Wl,-Bdynamic" "-ldl" "-lrt" "-lpthread" "-lgcc_s" "-lc" "-lm" "-lrt" "-lpthread" "-lutil" "-lutil" "-Wl,-rpath,$ORIGIN/auxiliary" "-Wl,-rpath,$ORIGIN/../../../stage2/lib/rustlib/arm-unknown-linux-gnueabihf/lib" "-Wl,-rpath,/checkout/obj/lib/rustlib/arm-unknown-linux-gnueabihf/lib" "-Wl,--enable-new-dtags"
   = note: /checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/arm-unknown-linux-gnueabihf/lib/libcompiler_builtins-34ad96caca8cd606.rlib(compiler_builtins-34ad96caca8cd606.compiler_builtins.7arsbjs9-cgu.0.rcgu.o): In function `__aeabi_memcpy8':
           compiler_builtins.7arsbjs9-cgu.0:(.text.__aeabi_memcpy4+0x6c): undefined reference to `core::panicking::panic::h747b6b606f8c4f43'
           compiler_builtins.7arsbjs9-cgu.0:(.text.__aeabi_memcpy4+0x7c): undefined reference to `core::panicking::panic::h747b6b606f8c4f43'
           collect2: error: ld returned 1 exit status
           

error: aborting due to previous error

Not sure if the new debug_assert! from #62103 might have caused this? #62286 also looks like it has the potential to cause linking failures.

@Centril Centril closed this Jul 4, 2019
@Centril Centril added the rollup A PR which is a rollup label Oct 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.