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 9 pull requests #86962

Closed
wants to merge 116 commits into from
Closed

Conversation

JohnTitor
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

alessandrod and others added 30 commits May 23, 2021 18:03
This change adds the bpfel-unknown-none and bpfeb-unknown-none targets
which can be used to generate little endian and big endian BPF
Both cg_llvm and cg_clif don't override it. cg_spirv does override it,
so it needs to be preserved.
…k(kind = "raw-dylib")].

This does not yet support #[link_name] attributes on functions, the #[link_ordinal]
attribute, #[link(kind = "raw-dylib")] on extern blocks in bin crates, or
stdcall functions on 32-bit x86.
BPF target support

This adds `bpfel-unknown-none` and `bpfeb-unknown-none`, two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target, where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker.

I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.
…enkov

Partial support for raw-dylib linkage

First cut of functionality for issue rust-lang#58713: add support for `#[link(kind = "raw-dylib")]` on `extern` blocks in lib crates compiled to .rlib files.  Does not yet support `#[link_name]` attributes on functions, or the `#[link_ordinal]` attribute, or `#[link(kind = "raw-dylib")]` on `extern` blocks in bin crates; I intend to publish subsequent PRs to fill those gaps.  It's also not yet clear whether this works for functions in `extern "stdcall"` blocks; I also intend to investigate that shortly and make any necessary changes as a follow-on PR.

This implementation calls out to an LLVM function to construct the actual `.idata` sections as temporary `.lib` files on disk and then links those into the generated .rlib.
Driver improvements

This PR contains a couple of cleanups for the driver and a few small improvements for the custom codegen backend interface. It also implements `--version` and `-Cpasses=list` support for custom codegen backends.
…ochenkov

Unify duplicate linker_and_flavor methods in rustc_codegen_{cranelift,ssa}.

The two methods were exactly the same so this removes the cranelift copy. This will help make sure both they don't get out of sync.
Drop metadata_encoding_version.

Part of rust-lang#85153

r? `@Aaron1011`
eholk and others added 17 commits July 7, 2021 10:28
Previously this was using a `.stderr` file, but that does not seem to
work for all cases. This change uses `// error-pattern:` instead.
This change merges `check_lint_and_tool_name` into `check_lint_name` in
order to avoid having two very similar functions.

Also adds the `.stderr` file back for the test case, since apparently
it is still needed.
This makes `fs::hard_link` use weak! for some platforms,
thereby preventing a linker error.
`weak!` is needed in a test in another module. With macros
1.0, importing `weak!` would require reordering module
declarations in `std/src/lib.rs`, which is a bit too
evil.
On old macos systems, `fs::hard_link()` will follow symlinks.
This changes the test `symlink_hard_link` to exit early on
these systems, so that tests can pass.
…s-hardlink, r=joshtriplett

Fix linker error

Currently, `fs::hard_link` determines whether platforms have `linkat` based on the OS, and uses `link` if they don't. However, this heuristic does not work well if a platform provides `linkat` on newer versions but not on older ones. On old MacOS, this currently causes a linking error.

This commit fixes `fs::hard_link` by telling it to use `weak!` on macOS This means that, on  that operating system, we now check for `linkat` at runtime and use `link` if it is not available.

Fixes rust-lang#80804.

``@rustbot`` label T-libs-impl
Support lint tool names in rustc command line options

When rustc is running without a lint tool such as clippy enabled, options for lints such as `clippy::foo` are meant to be ignored. This was already working for those specified by attrs, such as `#![allow(clippy::foo)]`, but this did not work for command line arguments like `-A clippy::foo`. This PR fixes that issue.

Note that we discovered this issue while discussing rust-lang/cargo#5034.

Fixes rust-lang#86628.
…e-error, r=JohnTitor

Add doc comment for `impl From<LayoutError> for TryReserveError`
…Simulacrum

Add self to mailmap

For personal reasons, I would currently prefer to be known by this name.
…jorn3

Sync rustc_codegen_cranelift

The main hightlight this sync is basic support for AArch64. Most things should work on Linux, but there does seem to be an ABI incompatibility causing proc-macros to crash, see https://github.com/bjorn3/rustc_codegen_cranelift/issues/1184. Thanks to ``@afonso360`` for implementing all Cranelift features that were necessary to compile for AArch64 using cg_clif. Also thanks to ``@shamatar`` for implementing the `llvm.x86.addcarry.64` and `llvm.x86.subborrow.64` llvm intrinsics used by num-bigint (https://github.com/bjorn3/rustc_codegen_cranelift/pull/1178) and ``@eggyal`` for implementing multi-threading support for the lazy jit mode. (https://github.com/bjorn3/rustc_codegen_cranelift/pull/1166)

r? ``@ghost``

``@rustbot`` label +A-codegen +A-cranelift +T-compiler
Fix ICE when misplaced visibility cannot be properly parsed

Fixes rust-lang#86895

The issue was that a failure to parse the visibility was causing the original error to be dropped before being emitted.

The resulting error isn't quite as nice as when the visibility is parsed properly, but I'm not sure which error to prioritize here. Displaying both errors might be too confusing.

r? ``@estebank``
…ic-files, r=Manishearth

Clean up rustdoc static files

The `html/static` of rustdoc was starting to be quite a mess... So I moved files in sub-folders to make it easier to follow. Here what remains in `html/static` folder:

```
$ ls
COPYRIGHT.txt  css  fonts  images  js  LICENSE-APACHE.txt  LICENSE-MIT.txt
```

cc ``@jyn514``
r? ``@Manishearth``
Revert "Add "every" as a doc alias for "all"."

This reverts commit 3545036 (rust-lang#81697) for "every" and closes rust-lang#86554 in kind for "some".

The new [doc alias policy](https://std-dev-guide.rust-lang.org/documentation/doc-alias-policy.html) is that we don't want language-specific aliases like these JavaScript names, and we especially don't want to conflict with real names. While "every" is okay in the latter regard, its natural pair "some" makes a doc-search collision with `Option::Some`.

r? ``@m-ou-se``
@rustbot rustbot added the rollup A PR which is a rollup label Jul 7, 2021
@JohnTitor
Copy link
Member Author

@bors r+ p=9 rollup=never

@bors
Copy link
Contributor

bors commented Jul 7, 2021

📌 Commit d04c638 has been approved by JohnTitor

@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 7, 2021
@bors
Copy link
Contributor

bors commented Jul 8, 2021

⌛ Testing commit d04c638 with merge 4fe991212feffdea25eafc22423dcc3f86499d6d...

@rust-log-analyzer
Copy link
Collaborator

The job dist-x86_64-netbsd failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
   |
11 | use crate::sys::weak::weak;
   |     ^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: `-D unused-imports` implied by `-D warnings`
error: aborting due to previous error

[RUSTC-TIMING] std test:false 2.058
error: could not compile `std`

@bors
Copy link
Contributor

bors commented Jul 8, 2021

💔 Test failed - checks-actions

@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 8, 2021
@JohnTitor JohnTitor mentioned this pull request Jul 8, 2021
@JohnTitor JohnTitor closed this Jul 8, 2021
@JohnTitor JohnTitor deleted the rollup-hpswuey branch July 8, 2021 01:43
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.