Guillaume Gomez [Sun, 6 Jun 2021 23:06:48 +0000 (01:06 +0200)]
Rollup merge of #83433 - jyn514:cfg-bootstrap-macro, r=Mark-Simulacrum
Pass --cfg=bootstrap for proc macros built by stage0
Cargo has a bug where it ignores RUSTFLAGS when building proc macro
crates (https://github.com/rust-lang/cargo/issues/4423).
However, sometimes rustc_macro needs to have conditional
compilation when there are breaking changes to the `libproc_macro` API
(see for example #83363). Previously, this wasn't possible, because the
crate couldn't tell the difference between stage 0 and stage 1.
Another alternative is to unconditionally build rustc_macros with the
master libstd instead of the beta one (i.e. use `--sysroot
stage0-sysroot`), but that led to strange and maddening errors:
```
error[E0460]: found possibly newer version of crate `std` which `synstructure` depends on
--> compiler/rustc_macros/src/lib.rs:5:5
|
5 | use synstructure::decl_derive;
| ^^^^^^^^^^^^
|
= note: perhaps that crate needs to be recompiled?
= note: the following crate versions were found:
crate `std`: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/stage0-sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-b3602c301b71cc3d.rmeta
crate `synstructure`: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/stage0-rustc/release/deps/libsynstructure-74ee66863479e972.rmeta
error[E0460]: found possibly newer version of crate `std` which `proc_macro2` depends on
--> /home/joshua/.local/lib/cargo/registry/src/github.com-1ecc6299db9ec823/tracing-attributes-0.1.13/src/lib.rs:90:5
|
90 | use proc_macro2::TokenStream;
| ^^^^^^^^^^^
|
= note: perhaps that crate needs to be recompiled?
= note: the following crate versions were found:
crate `std`: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/stage0-sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-b3602c301b71cc3d.rmeta
crate `proc_macro2`: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/stage0-rustc/release/deps/libproc_macro2-a83c1f01610c129e.rlib
```
bors [Sun, 6 Jun 2021 19:12:05 +0000 (19:12 +0000)]
Auto merge of #85343 - Aaron1011:variance-diag, r=estebank
Add variance-related information to lifetime error messages
This PR adds a basic framework for displaying variance-related information in error messages. For example:
```
error: lifetime may not live long enough
--> $DIR/type-check-pointer-comparisons.rs:12:5
|
LL | fn compare_mut<'a, 'b>(x: *mut &'a i32, y: *mut &'b i32) {
| -- -- lifetime `'b` defined here
| |
| lifetime `'a` defined here
LL | x == y;
| ^ requires that `'a` must outlive `'b`
|
= help: consider adding the following bound: `'a: 'b`
= note: requirement occurs because of a mutable pointer to &i32
= note: mutable pointers are invariant over their type parameter
= help: see <https://doc.rust-lang.org/nomicon/subtyping.html> for more information about variance
```
The last three lines are new.
This is accomplished by adding a new struct `VarianceDiagInfo`, and passing it along through the various relation methods. When relating types that change the variance (e.g. `&mut T` or `*mut T`), we pass a more specific `VarianceDiagInfo` storing information about the cause of the variance change. When an error, we use the `VarianceDiagInfo` to add additional information to the error message.
This PR doesn't change any variance-related computation or behavior - only diagnostic messages. Therefore, the implementation is quite incomplete - more detailed error messages can be filled in in subsequent PRs.
Limitations:
* We only attempt to deal with invariance - since it's at the bottom of the 'variance lattice', our variance will never change again after it becomes invariant. Handling contravariance would be trickier, since we can change between contravariance and covariance multiple times (e.g. `fn(fn(&'static u8))`). Since contravariance (AFAIK) is only used for function arguments, we can probably get away without a very fancy message for cases involving contravariance.
* `VarianceDiagInfo` currently only handles mutable pointers/references. However, user-defined types (structs, enums, and unions) have the variance of their type parameters inferred, so it would be good to eventually display information about that. We'll want to try to find a balance between displaying too much and too little information about how the variance was inferred.
* The improved error messages are only displayed when `#![feature(nll)]` / `-Z borrowck=mir` is enabled. If issue https://github.com/rust-lang/rust/issues/58781 is not resolved relatively soon, then we might want to duplicate some of this logic in the 'current' (non-NLL) region/outlives handling code.
- Combine all native library arguments together, to simplify potential support for library deduplication and similar things
- Split arguments into order-independent and order-dependent, to define more precisely what (pre,post,late)-link-args mean
bors [Sun, 6 Jun 2021 14:00:43 +0000 (14:00 +0000)]
Auto merge of #84995 - petrochenkov:tcollect, r=Aaron1011
parser: Ensure that all nonterminals have tokens after parsing
`parse_nonterminal` should always result in something with tokens.
This requirement wasn't satisfied in two cases:
- `stmt` nonterminal with expression statements (e.g. `0`, or `{}`, or `path + 1`) because `fn parse_stmt_without_recovery` forgot to propagate `force_collect` in some cases.
- `expr` nonterminal with expressions with built-in attributes (e.g. `#[allow(warnings)] 0`) due to an incorrect optimization in `fn parse_expr_force_collect`, it assumed that all expressions starting with `#` have their tokens collected during parsing, but that's not true if all the attributes on that expression are built-in and inert.
(Discovered when trying to implement eager `cfg` expansion for all attributes https://github.com/rust-lang/rust/pull/83824#issuecomment-817317170.)
bors [Sun, 6 Jun 2021 11:31:16 +0000 (11:31 +0000)]
Auto merge of #86054 - JohnTitor:rollup-j40z7sm, r=JohnTitor
Rollup of 8 pull requests
Successful merges:
- #85436 (Avoid cloning cache key)
- #85772 (Preserve metadata w/ Solaris-like linkers.)
- #85920 (Tweak wasm_base target spec to indicate linker is not GNU and update linker inferring logic for wasm-ld.)
- #85930 (Update standard library for IntoIterator implementation of arrays )
- #85972 (Rustdoc html fixes)
- #86028 (Drop an `if let` that will always succeed)
- #86043 (don't clone attrs)
- #86047 (Don't fire `invalid_doc_attributes` on `extern crate` items)
Yuki Okushi [Sun, 6 Jun 2021 10:11:19 +0000 (19:11 +0900)]
Rollup merge of #85930 - mominul:array_into_iter, r=m-ou-se
Update standard library for IntoIterator implementation of arrays
This PR partially resolves issue #84513 of updating the standard library part.
I haven't found any remaining doctest examples which are using iterators over e.g. &i32 instead of just i32 in the standard library. Can anyone point me to them if there's remaining any?
Yuki Okushi [Sun, 6 Jun 2021 10:11:18 +0000 (19:11 +0900)]
Rollup merge of #85920 - luqmana:wasm-linker-tweaks, r=petrochenkov
Tweak wasm_base target spec to indicate linker is not GNU and update linker inferring logic for wasm-ld.
Reported via [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/wasi.20linker.20unknown.20argument.3A.20--as-needed): we try passing `--as-needed` to the linker if it's GNU ld which `wasm-ld` is not. Usually this isn't an issue for wasm as we would use the WasmLd linker driver but because the linker in question (`wasm32-unknown-wasi-wasm-ld`) ended with `-ld` our linker inferring [logic](https://github.com/rust-lang/rust/blob/f64503eb555475d65ae5503ef22439ca5dd394fd/compiler/rustc_codegen_ssa/src/back/link.rs#L957-L1040) used the `GccLinker` implementations. (UPD: The linker inferring logic actually didn't apply in this case because the linker is actually invoked through gcc in the reported issue. But it's still worth updating the logic I think.)
This change then has 2 parts:
1. Update wasm_base target spec to indicate `linker_is_gnu: false` plus a few additions of `target.is_like_wasm` to handle flags `wasm-ld` does in fact support.
2. Improve the linker detection logic to properly determine the correct flavor of wasm linker we're using when we can.
We need to add the new `target.is_like_wasm` branches to handle the case where the "linker" used could be something like clang which would then under the hood call wasm-ld.
Yuki Okushi [Sun, 6 Jun 2021 10:11:17 +0000 (19:11 +0900)]
Rollup merge of #85772 - luqmana:ignored-metadata, r=petrochenkov
Preserve metadata w/ Solaris-like linkers.
#84468 moved the `-zignore` linker flag from the `gc_sections` method to `add_as_needed` which is more accurate but Solaris-style linkers will also end up removing an unreferenced ELF sections [1]. This had the unfortunate side effect of causing the `.rustc` section (which has the metada) to be removed which could cause issues when trying to link against the resulting crates or use proc macros.
Since the `-zignore` is positional, we fix this by moving the metadata objects to before the flag.
[1] Specifically a section is considered unreferenced if:
* The section is allocatable
* No other sections bind to (relocate) to this section
* The section provides no global symbols
bors [Sun, 6 Jun 2021 09:13:59 +0000 (09:13 +0000)]
Auto merge of #84863 - ABouttefeux:libtest, r=m-ou-se
Show test type during prints
Test output can sometimes be confusing. For example doctest with the no_run argument are displayed the same way than test that are run.
During #83857 I got the feedback that test output can be confusing.
For the moment test output is
```
test $DIR/test-type.rs - f (line 12) ... ignored
test $DIR/test-type.rs - f (line 15) ... ok
test $DIR/test-type.rs - f (line 21) ... ok
test $DIR/test-type.rs - f (line 6) ... ok
```
I propose to change output by indicating the test type as
```
test $DIR/test-type.rs - f (line 12) ... ignored
test $DIR/test-type.rs - f (line 15) - compile ... ok
test $DIR/test-type.rs - f (line 21) - compile fail ... ok
test $DIR/test-type.rs - f (line 6) ... ok
```
by indicating the test type after the test name (and in the case of doctest after the function name and line) and before the "...".
------------
Note: this is a proof of concept, the implementation is probably not optimal as the properties added in `TestDesc` are only use in the display and does not represent actual change of behavior, maybe `TestType::DocTest` could have fields
bors [Sun, 6 Jun 2021 03:59:17 +0000 (03:59 +0000)]
Auto merge of #84171 - ricobbe:raw-dylib-via-llvm, r=petrochenkov
Partial support for raw-dylib linkage
First cut of functionality for issue #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.
bors [Sun, 6 Jun 2021 01:02:32 +0000 (01:02 +0000)]
Auto merge of #79608 - alessandrod:bpf, r=nagisa
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.
bors [Sat, 5 Jun 2021 18:41:36 +0000 (18:41 +0000)]
Auto merge of #86032 - GuillaumeGomez:rollup-y3ij27b, r=GuillaumeGomez
Rollup of 7 pull requests
Successful merges:
- #83646 (Add a map method to Bound)
- #85501 (Fix `deny(invalid_doc_attributes)`)
- #85503 (rustdoc: add tooltips to some buttons)
- #85710 (Document `From` impls in path.rs)
- #85760 (Possible errors when accessing file metadata are platform specific)
- #85974 (td align attribute)
- #86014 (msp430 linker does not accept -znoexecstack. Set linker_is_gnu to fal…)
I also opened an issue about it: raphlinus/pulldown-cmark#533. However, I'm not sure if this is the right course of action... Should we instead ignore the warning?
Guillaume Gomez [Sat, 5 Jun 2021 17:41:43 +0000 (19:41 +0200)]
Rollup merge of #85760 - ChrisDenton:path-doc-platform-specific, r=m-ou-se
Possible errors when accessing file metadata are platform specific
In particular the `is_dir`, `is_file` and `exists` functions suggests that querying a file requires querying the directory. On Windows this is not normally true.
bors [Sat, 5 Jun 2021 14:08:38 +0000 (14:08 +0000)]
Auto merge of #85869 - tmiasko:box-free, r=nagisa
Remove special handling of `box_free` from `LocalAnalyzer`
The special casing of `box_free` predates the use of dominators in
analyzer. It is no longer necessary now that analyzer verifies that
the first assignment dominates all uses.
bors [Sat, 5 Jun 2021 06:17:17 +0000 (06:17 +0000)]
Auto merge of #85919 - workingjubilee:simd-ptrs-are-valid, r=petrochenkov
Allow raw pointers in SIMD types
Closes #85915 by loosening the strictness in typechecking and adding a test to guarantee it passes.
This still might be too strict, as references currently do pass monomorphization, but my understanding is that they are not guaranteed to be "scalar" in the same way.
bors [Sat, 5 Jun 2021 03:36:26 +0000 (03:36 +0000)]
Auto merge of #85457 - jyn514:remove-doc-include, r=GuillaumeGomez
Remove `doc(include)`
This nightly feature is redundant now that `extended_key_value_attributes` is stable (https://github.com/rust-lang/rust/pull/83366). `@rust-lang/rustdoc` not sure if you think this needs FCP; there was already an FCP in #82539, but technically it was for deprecating, not removing the feature altogether.
Joshua Nelson [Wed, 24 Mar 2021 01:48:29 +0000 (21:48 -0400)]
Pass --cfg=bootstrap for proc_macros or build scripts built by stage0
Cargo ignores RUSTFLAGS when building proc macro crates. However,
sometimes rustc_macro needs to have conditional compilation when there
are breaking changes to the `libproc_macro` API (see for example
tell the difference between stage 0 and stage 1.
Another alternative is to unconditionally build rustc_macros with the
master libstd instead of the beta one (i.e. use `--sysroot
stage0-sysroot`), but that led to strange and maddening errors:
```
error[E0460]: found possibly newer version of crate `std` which `proc_macro2` depends on
--> /home/joshua/.local/lib/cargo/registry/src/github.com-1ecc6299db9ec823/tracing-attributes-0.1.13/src/lib.rs:90:5
|
90 | use proc_macro2::TokenStream;
| ^^^^^^^^^^^
|
= note: perhaps that crate needs to be recompiled?
= note: the following crate versions were found:
crate `std`: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/stage0-sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-b3602c301b71cc3d.rmeta
crate `proc_macro2`: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/stage0-rustc/release/deps/libproc_macro2-a83c1f01610c129e.rlib
```
Richard Cobbe [Mon, 8 Mar 2021 20:42:54 +0000 (12:42 -0800)]
Add first cut of functionality for #58713: support for #[link(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.
bors [Fri, 4 Jun 2021 22:18:16 +0000 (22:18 +0000)]
Auto merge of #86006 - JohnTitor:rollup-97iuoi3, r=JohnTitor
Rollup of 10 pull requests
Successful merges:
- #83653 (Remove unused code from `rustc_data_structures::sync`)
- #84466 (rustdoc: Remove `PrimitiveType::{to_url_str, as_str}`)
- #84880 (Make match in `register_res` easier to read)
- #84942 (rustdoc: link to stable/beta docs consistently in documentation)
- #85853 (Warn against boxed DST in `improper_ctypes_definitions` lint)
- #85939 (Fix suggestion for removing &mut from &mut macro!().)
- #85966 (wasm: Make simd types passed via indirection again)
- #85979 (don't suggest unsized indirection in where-clauses)
- #85983 (Update to semver 1.0.3)
- #85988 (Note that `ninja = false` goes under `[llvm]`)
Yuki Okushi [Fri, 4 Jun 2021 21:13:45 +0000 (06:13 +0900)]
Rollup merge of #85979 - tlyu:where-no-unsized-indirection, r=estebank
don't suggest unsized indirection in where-clauses
Skip where-clauses when suggesting using indirection in combination with
`?Sized` bounds on type parameters.
Fixes #85943.
`@estebank` I think this doesn't conflict with your work in #85947; please let me know if you'd like me to cherry pick it to a new branch based on yours instead.
Yuki Okushi [Fri, 4 Jun 2021 21:13:43 +0000 (06:13 +0900)]
Rollup merge of #85966 - alexcrichton:wasm-simd-indirect, r=workingjubilee
wasm: Make simd types passed via indirection again
This commit updates wasm target specs to use `simd_types_indirect: true`
again. Long ago this was added since wasm simd types were always
translated to `v128` under-the-hood in LLVM, meaning that it didn't
matter whether that target feature was enabled or not. Now, however,
`v128` is conditionally used in codegen depending on target features
enabled, meaning that it's possible to get linker errors about different
signatures in code that correctly uses simd types. The fix is the same
as for all other platforms, which is to pass the type indirectly.
Yuki Okushi [Fri, 4 Jun 2021 21:13:37 +0000 (06:13 +0900)]
Rollup merge of #84942 - jyn514:channel-replace, r=Manishearth
rustdoc: link to stable/beta docs consistently in documentation
This is an alternative to https://github.com/rust-lang/rust/pull/84941 which fixes the problem consistently by linking to stable/beta for *all* items, not just for primitives.
## User-facing changes
- Intra-doc links to primitives that currently go to rust-lang.org/nightly/std/primitive.x.html will start going to channel that rustdoc was built with. Nightly will continue going to /nightly; Beta will link to /beta; stable compilers will link to /1.52.1 (or whatever version they were built as).
- Cross-crate links from std to core currently go to /nightly unconditionally. They will start going to /1.52.0 on stable channels (but remain the same on nightly channels).
- Intra-crate links from std to std (or core to core) currently go to the same URL they are hosted at; they will continue to do so. Notably, this is different from everything else because it can preserve the distinction between /stable and /1.52.0 by using relative links.
Note that "links" includes both intra-doc links and rustdoc's own
automatically generated hyperlinks.
## Implementation changes
- Update the testsuite to allow linking to /beta and /1.52.1 in docs
- Use an html_root_url for the standard library that's dependent on the channel
This avoids linking to nightly docs on stable.
- Update rustdoc to use channel-dependent links for primitives from an
unknown crate
- Set DOC_RUST_LANG_ORG_CHANNEL from bootstrap to ensure it's in sync
- Include doc.rust-lang.org in the channel
cc Mark-Simulacrum - I know [you were dubious about this in the past](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Rustdoc.20unconditionally.20links.20to.20nightly.20libstd.20docs/near/231223124), but I'm not quite sure why? I see this as "just a bugfix", I don't know why rustdoc should unconditionally link to nightly.
cc dtolnay who commented in https://github.com/rust-lang/rust/issues/30693:
> I would welcome a PR to solve this permanently if anyone has ideas for how. I don't believe we need an RFC.
Fixes https://github.com/rust-lang/rust/issues/30693 (note that issue is marked as feature-accepted, although I don't see where it was discussed).
Yuki Okushi [Fri, 4 Jun 2021 21:13:32 +0000 (06:13 +0900)]
Rollup merge of #84880 - jyn514:cleanup-itemkind, r=GuillaumeGomez
Make match in `register_res` easier to read
- Don't duplicate DefKind -> ItemType handling; that's a good way to get bugs
- Use exhaustive match
- Add comments
This found that register_res is very wrong in at least one way: if it
registers a Res for `Variant`, it should also register one for `Field`.
But I don't know whether the one for Variant should be removed or Field
added. Maybe someone has ideas?
Found while reviewing https://github.com/rust-lang/rust/pull/84176.
bors [Fri, 4 Jun 2021 19:29:50 +0000 (19:29 +0000)]
Auto merge of #84449 - alexcrichton:metadata-in-object, r=nagisa
rustc: Store metadata-in-rlibs in object files
This commit updates how rustc compiler metadata is stored in rlibs.
Previously metadata was stored as a raw file that has the same format as
`--emit metadata`. After this commit, however, the metadata is encoded
into a small object file which has one section which is the contents of
the metadata.
The motivation for this commit is to fix a common case where #83730
arises. The problem is that when rustc crates a `dylib` crate type it
needs to include entire rlib files into the dylib, so it passes
`--whole-archive` (or the equivalent) to the linker. The problem with
this, though, is that the linker will attempt to read all files in the
archive. If the metadata file were left as-is (today) then the linker
would generate an error saying it can't read the file. The previous
solution was to alter the rlib just before linking, creating a new
archive in a temporary directory which has the metadata file removed.
This problem from before this commit is now removed if the metadata file
is stored in an object file that the linker can read. The only caveat we
have to take care of is to ensure that the linker never actually
includes the contents of the object file into the final output. We apply
similar tricks as the `.llvmbc` bytecode sections to do this.
This involved changing the metadata loading code a bit, namely updating
some of the LLVM C APIs used to use non-deprecated ones and fiddling
with the lifetimes a bit to get everything to work out. Otherwise though
this isn't intended to be a functional change really, only that metadata
is stored differently in archives now.
This should end up fixing #83730 because by default dylibs will no
longer have their rlib dependencies "altered" meaning that
split-debuginfo will continue to have valid paths pointing at the
original rlibs. (note that we still "alter" rlibs if LTO is enabled to
remove Rust object files and we also "alter" for the #[link(cfg)]
feature, but that's rarely used).
Joshua Nelson [Wed, 5 May 2021 03:36:33 +0000 (23:36 -0400)]
rustdoc: link to stable/beta docs consistently in documentation
## User-facing changes
- Intra-doc links to primitives that currently go to rust-lang.org/nightly/std/primitive.x.html will start going to channel that rustdoc was built with. Nightly will continue going to /nightly; Beta will link to /beta; stable compilers will link to /1.52.1 (or whatever version they were built as).
- Cross-crate links from std to core currently go to /nightly unconditionally. They will start going to /1.52.0 on stable channels (but remain the same on nightly channels).
- Intra-crate links from std to std (or core to core) currently go to the same URL they are hosted at; they will continue to do so. Notably, this is different from everything else because it can preserve the distinction between /stable and /1.52.0 by using relative links.
Note that "links" includes both intra-doc links and rustdoc's own
automatically generated hyperlinks.
## Implementation changes
- Update the testsuite to allow linking to /beta and /1.52.1 in docs
- Use an html_root_url for the standard library that's dependent on the channel
This avoids linking to nightly docs on stable.
- Update rustdoc to use channel-dependent links for primitives from an
unknown crate
- Set DOC_RUST_LANG_ORG_CHANNEL from bootstrap to ensure it's in sync
- Include doc.rust-lang.org in the channel
Alex Crichton [Thu, 22 Apr 2021 18:53:33 +0000 (11:53 -0700)]
rustc: Store metadata-in-rlibs in object files
This commit updates how rustc compiler metadata is stored in rlibs.
Previously metadata was stored as a raw file that has the same format as
`--emit metadata`. After this commit, however, the metadata is encoded
into a small object file which has one section which is the contents of
the metadata.
The motivation for this commit is to fix a common case where #83730
arises. The problem is that when rustc crates a `dylib` crate type it
needs to include entire rlib files into the dylib, so it passes
`--whole-archive` (or the equivalent) to the linker. The problem with
this, though, is that the linker will attempt to read all files in the
archive. If the metadata file were left as-is (today) then the linker
would generate an error saying it can't read the file. The previous
solution was to alter the rlib just before linking, creating a new
archive in a temporary directory which has the metadata file removed.
This problem from before this commit is now removed if the metadata file
is stored in an object file that the linker can read. The only caveat we
have to take care of is to ensure that the linker never actually
includes the contents of the object file into the final output. We apply
similar tricks as the `.llvmbc` bytecode sections to do this.
This involved changing the metadata loading code a bit, namely updating
some of the LLVM C APIs used to use non-deprecated ones and fiddling
with the lifetimes a bit to get everything to work out. Otherwise though
this isn't intended to be a functional change really, only that metadata
is stored differently in archives now.
This should end up fixing #83730 because by default dylibs will no
longer have their rlib dependencies "altered" meaning that
split-debuginfo will continue to have valid paths pointing at the
original rlibs. (note that we still "alter" rlibs if LTO is enabled to
remove Rust object files and we also "alter" for the #[link(cfg)]
feature, but that's rarely used).
bors [Fri, 4 Jun 2021 16:48:50 +0000 (16:48 +0000)]
Auto merge of #85806 - ATiltedTree:android-ndk-beta, r=petrochenkov
Support Android ndk versions `r23-beta3` and up
Since android ndk version `r23-beta3`, `libgcc` has been replaced with `libunwind`. This moves the linking of `libgcc`/`libunwind` into the `unwind` crate where we check if the system compiler can find `libunwind` and fall back to `libgcc` if needed.
This PR adds a new command line option `force-warns` which will force the provided lints to warn even if they are allowed by some other mechanism such as `#![allow(warnings)]`.
Some remaining issues:
* https://github.com/rust-lang/rust/issues/85512 mentions that `force-warns` should also be capable of taking lint groups instead of individual lints. This is not implemented.
* If a lint has a higher warning level than `warn`, this will cause that lint to warn instead. We probably want to allow the lint to error if it is set to a higher lint and is not allowed somewhere else.
* One test is currently ignored because it's not working - when a deny-by-default lint is allowed, it does not currently warn under `force-warns`. I'm not sure why, but I wanted to get this in before the weekend.
bors [Fri, 4 Jun 2021 10:18:54 +0000 (10:18 +0000)]
Auto merge of #85385 - richkadel:simpler-simplify-with-coverage, r=wesleywiser
Reland - Report coverage `0` of dead blocks
Fixes: #84018
With `-Z instrument-coverage`, coverage reporting of dead blocks
(for example, blocks dropped because a conditional branch is dropped,
based on const evaluation) is now supported.
Note, this PR relands an earlier, reverted PR that failed when compiling
generators. The prior issues with generators has been resolved and a new
test was added to prevent future regressions.
Check out the resulting changes to test coverage of dead blocks in the
test coverage reports in this PR.
bors [Fri, 4 Jun 2021 07:10:55 +0000 (07:10 +0000)]
Auto merge of #85959 - RalfJung:miri-stage-0, r=Mark-Simulacrum
fix testing Miri with --stage 0
Fixes https://github.com/rust-lang/rust/issues/78778 for Miri.
The issue remains open for error_index_generator, which has its own dylib logic:
https://github.com/rust-lang/rust/blob/903e369c831d52726a5292f847e384622189d9a0/src/bootstrap/tool.rs#L396-L400
`@jyn514` I could just copy the logic from `add_rustc_lib_path`, but that does not seem great. Any other suggestions?
Also I wonder if maybe `prepare_tool_cargo` should already call `add_rustc_lib_path`.
bors [Fri, 4 Jun 2021 04:50:36 +0000 (04:50 +0000)]
Auto merge of #85984 - JohnTitor:rollup-rq0g9ph, r=JohnTitor
Rollup of 8 pull requests
Successful merges:
- #85717 (Document `From` impls for cow.rs)
- #85850 (Remove unused feature gates)
- #85888 (Fix typo in internal documentation for `TrustedRandomAccess`)
- #85889 (Restoring the `num_def_ids` function in the CStore API )
- #85899 (jsondocck small cleanup)
- #85937 (Fix bad suggestions for code from proc_macro)
- #85963 (Show `::{{constructor}}` in std::any::type_name().)
- #85977 (Fix linkcheck script from getting out of sync.)
Yuki Okushi [Fri, 4 Jun 2021 04:43:06 +0000 (13:43 +0900)]
Rollup merge of #85977 - ehuss:linkcheck-nightly, r=Mark-Simulacrum
Fix linkcheck script from getting out of sync.
When there are changes to the linkcheck script, the CI jobs used in the books would download the latest version on master, but run it against nightly. During that 24 hour window, the CI can fail if the script has changes that are incompatible with the last nightly. This fixes it so that it downloads the linkchecker that matches the version of nightly.
This also includes a fix to build with release to make it run much faster (I forgot to add this in #85652).
Yuki Okushi [Fri, 4 Jun 2021 04:42:57 +0000 (13:42 +0900)]
Rollup merge of #85899 - klensy:jsondocck-f, r=Mark-Simulacrum
jsondocck small cleanup
updated `shlex` (there was some fix https://github.com/comex/rust-shlex/commit/6db4704fcad8393dd6947b1d31720327546a84a2)
replaced `lazy_static` with `once_cell`
removed `serde` direct dependency (`serde_json` will pull it)
Yuki Okushi [Fri, 4 Jun 2021 04:42:56 +0000 (13:42 +0900)]
Rollup merge of #85889 - denismerigoux:master, r=petrochenkov
Restoring the `num_def_ids` function in the CStore API
## The context
I am the maintainer of https://github.com/hacspec/hacspec, an embedded Rust DSL aimed at cryptographic specifications. As it is normal for an embedded DSL, Hacspec's compiler relies on being plugged to the internal API of the Rust compiler, which is unstable and subject to changes.
## The problem
The Hacspec compiler features its own typechecker, that performs an additional, more restrictive typechecking pass over the Rust code of a crate. To complete this typechecking, the Hacspec compiler needs to retrieve the signature of functions defined in non-local imported crates. Rather than retrieving these signatures on-demand, the Hacspec compiler pre-populates its typechecking context with all the Hacspec-compatible symbols defined in non-local crates first. This requires having a way to iterate over all the definitions in a non-local crate.
I used to do this with `CrateMetadata::all_def_path_hashes_and_def_ids`, but this function was deleted in 908bf5a310b7265a3e. Then, I fellback on `CStore::num_def_ids`, exploiting the fact that all the `DefIds` for a crate have the same `krate_num` and range from `0` to `num_def_ids(krate_num)`. But `num_def_ids` was deleted in b6120bfb354c1c1c9fdf.
I looked to the `Cstore::item_children_untracked` function to replicate the feature of traversing through all the `DefId` for a crate, using `CRATE_DEF_INDEX` as the root, but this does not work as recursive `Cstore::item_children_untracked` calls do not reach all the symbols I was able to reach using the two previous methods.
## Description of this PR
This PR simply restores in the public API of `CStore` the `num_def_ids` function, giving the size of the definition table for a given crate.
Yuki Okushi [Fri, 4 Jun 2021 04:42:54 +0000 (13:42 +0900)]
Rollup merge of #85850 - bjorn3:less_feature_gates, r=jyn514
Remove unused feature gates
The first commit removes a usage of a feature gate, but I don't expect it to be controversial as the feature gate was only used to workaround a limitation of rust in the past. (closures never being `Clone`)
The second commit uses `#[allow_internal_unstable]` to avoid leaking the `trusted_step` feature gate usage from inside the index newtype macro. It didn't work for the `min_specialization` feature gate though.
The third commit removes (almost) all feature gates from the compiler that weren't used anyway.
Alex Crichton [Thu, 3 Jun 2021 15:58:12 +0000 (08:58 -0700)]
wasm: Make simd types passed via indirection again
This commit updates wasm target specs to use `simd_types_indirect: true`
again. Long ago this was added since wasm simd types were always
translated to `v128` under-the-hood in LLVM, meaning that it didn't
matter whether that target feature was enabled or not. Now, however,
`v128` is conditionally used in codegen depending on target features
enabled, meaning that it's possible to get linker errors about different
signatures in code that correctly uses simd types. The fix is the same
as for all other platforms, which is to pass the type indirectly.
bors [Thu, 3 Jun 2021 15:32:38 +0000 (15:32 +0000)]
Auto merge of #85292 - wesleywiser:enum_debuginfo, r=michaelwoerister
Improve debugging experience for enums on windows-msvc
This PR makes significant improvements over the status quo of debugging enums on the windows-msvc platform with either WinDbg or Visual Studio in three ways:
1. Improves the debugger experience for directly tagged enums.
2. Fixes a bug which caused the debugger to sometimes show the wrong debug info for niche layout enums. For example, `Option<&u32>` could sometimes use the debug info for `Option<&f64>` instead leading to nonsensical variable values in the debugger.
3. Significantly improves the debugger experience for niche-layout enums.
fn main() {
let a = Some(CStyleEnum::Base);
let b = Option::<CStyleEnum>::None;
let c = NicheLayoutEnum::Tag1;
let d = NicheLayoutEnum::Data { my_data: CStyleEnum::Exponent };
let e = NicheLayoutEnum::Tag2;
let f = Some(&1u32);
let g = Option::<&'static u32>::None;
let h = Some(&2u64);
let i = Option::<&'static u64>::None;
let j = Some(12u32);
let k = Option::<u32>::None;
let l = Some(12.34f64);
let m = Option::<f64>::None;
let n = CStyleEnum::Base;
let o = CStyleEnum::Exponent;
let p = Some("IAMA optional string!".to_string());
let q = OtherEnum::Case1(42u32);
}
```
This is what WinDbg Preview shows using the latest rustc nightly:
Most of the variables don't show a meaningful value expect for a few cases that we have targeted natvis definitions covering. Even worse, drilling into many of these variables shows information that can be difficult to interpret without an understanding of the layout of Rust types:
With the changes in this PR, we're able to write two natvis definitions that cover all enum cases generally. After building with these changes, WinDbg now shows this instead:
projects / rust.git / log