Dylan DPC [Mon, 10 May 2021 14:15:05 +0000 (16:15 +0200)]
Rollup merge of #85146 - ijackson:seek-rewind, r=m-ou-se
Provide io::Seek::rewind
Using `Seek::seek` is slightly clumsy because of the need to write (or import) `std::io::SeekFrom` to get at `SeekStart`. C already has `rewind` (although with broken error handling); we should have it too.
I'm motivated to do this because I've just found myself copy-pasting my 5-line extension trait between projects.
That the example ends up using `OpenOptions` makes this look like a niche use case, but it is very common to rewind temporary files. `tempfile` isn't available for use in this example or it would have looked shorter and more natural.
If this gets a positive reception I will open a tracking issue and update the feature gate.
Dylan DPC [Mon, 10 May 2021 14:15:03 +0000 (16:15 +0200)]
Rollup merge of #85112 - RalfJung:promoted-errors, r=oli-obk
ensure failing promoteds in const/static bodies are handled correctly
`const`/`static` bodies are the one case where we still promote code that might fail to evaluate. Ensure that this is handled correctly; in particular, it must not fail compilation.
`src/test/ui/consts/const-eval/erroneous-const.rs` ensures that when a non-promoted fails to evaluate, we *do* show an error.
Dylan DPC [Mon, 10 May 2021 14:15:02 +0000 (16:15 +0200)]
Rollup merge of #85096 - clarfonthey:const_unchecked, r=oli-obk
Make unchecked_{add,sub,mul} inherent methods unstably const
The intrinsics are marked as being stably const (even though they're not stable by nature of being intrinsics), but the currently-unstable inherent versions are not marked as const. This fixes this inconsistency. Split out of #85017,
Dylan DPC [Mon, 10 May 2021 14:15:00 +0000 (16:15 +0200)]
Rollup merge of #85050 - FabianWolff:issue-84592, r=jackh726
Fix suggestions for missing return type lifetime specifiers
This pull request aims to fix #84592. The issue is that the current code seems to assume that there is only a single relevant span pointing to the missing lifetime, and only looks at the first one:
https://github.com/rust-lang/rust/blob/e5f83d24aee866a14753a7cedbb4e301dfe5bef5/compiler/rustc_resolve/src/late/lifetimes.rs#L2959
This is incorrect, though, and leads to incorrect error messages and invalid suggestions. For instance, the example from #84592:
```rust
struct TwoLifetimes<'x, 'y> {
x: &'x (),
y: &'y (),
}
fn two_lifetimes_needed(a: &(), b: &()) -> TwoLifetimes<'_, '_> {
TwoLifetimes { x: &(), y: &() }
}
```
currently leads to:
```
error[E0106]: missing lifetime specifiers
--> src/main.rs:6:57
|
6 | fn two_lifetimes_needed(a: &(), b: &()) -> TwoLifetimes<'_, '_> {
| --- --- ^^ expected 2 lifetime parameters
|
= help: this function's return type contains a borrowed value, but the signature does not say whether it is borrowed from `a` or `b`
help: consider introducing a named lifetime parameter
|
6 | fn two_lifetimes_needed<'a>(a: &'a (), b: &'a ()) -> TwoLifetimes<'_<'a, 'a>, '_> {
| ^^^^ ^^^^^^ ^^^^^^ ^^^^^^^^^^
```
There are two problems:
- The error message is wrong. There is only _one_ lifetime parameter expected at the location pointed to by the error message (and another one at a separate location).
- The suggestion is incorrect and will not lead to correct code.
With the changes in this PR, I get the following output:
```
error[E0106]: missing lifetime specifiers
--> p.rs:6:57
|
6 | fn two_lifetimes_needed(a: &(), b: &()) -> TwoLifetimes<'_, '_> {
| --- --- ^^ ^^ expected named lifetime parameter
| |
| expected named lifetime parameter
|
= help: this function's return type contains a borrowed value, but the signature does not say whether it is borrowed from `a` or `b`
help: consider introducing a named lifetime parameter
|
6 | fn two_lifetimes_needed<'a>(a: &'a (), b: &'a ()) -> TwoLifetimes<'a, 'a> {
| ^^^^ ^^^^^^ ^^^^^^ ^^ ^^
error: aborting due to previous error
For more information about this error, try `rustc --explain E0106`.
```
Mainly, I changed `add_missing_lifetime_specifiers_label()` to receive a _vector_ of spans (and counts) instead of just one, and adjusted its body accordingly.
bors [Mon, 10 May 2021 00:42:31 +0000 (00:42 +0000)]
Auto merge of #84507 - crlf0710:codegen_nonlocal_main_wrapper, r=nagisa
Add primary marker on codegen unit and generate main wrapper on primary codegen.
This is the codegen part of changes extracted from #84062.
This add a marker called `primary` on each codegen units, where exactly one codegen unit will be `primary = true` at a time. This specific codegen unit will take charge of generating `main` wrapper when `main` is imported from a foreign crate after the implementation of RFC 1260.
cc #28937
I'm not sure who should i ask for review for codegen changes, so feel free to reassign.
r? `@nagisa`
bors [Sun, 9 May 2021 22:01:26 +0000 (22:01 +0000)]
Auto merge of #83800 - xobs:impl-16351-nightly, r=nagisa
Add default search path to `Target::search()`
The function `Target::search()` accepts a target triple and returns a `Target` struct defining the requested target.
There is a `// FIXME 16351: add a sane default search path?` comment that indicates it is desirable to include some sort of default. This was raised in https://github.com/rust-lang/rust/issues/16351 which was closed without any resolution.
https://github.com/rust-lang/rust/pull/31117 was proposed, however that has platform-specific logic that is unsuitable for systems without `/etc/`.
This patch implements the suggestion raised in https://github.com/rust-lang/rust/issues/16351#issuecomment-180878193 where a `target.json` file may be placed in `$(rustc --print sysroot)/lib/rustlib/<target-triple>/target.json`. This allows shipping a toolchain distribution as a single file that gets extracted to the sysroot.
bors [Sun, 9 May 2021 16:19:21 +0000 (16:19 +0000)]
Auto merge of #83894 - nikic:newpm, r=nagisa
Improve support for NewPM
This adds various missing bits of support for NewPM and allows us to successfully run stage 2 tests with NewPM enabled.
This does not yet enable NewPM by default, as there are still known issue on LLVM 12 (such as a weak fat LTO pipeline). The plan is to make the switch after we update to LLVM 13.
bors [Sun, 9 May 2021 13:38:17 +0000 (13:38 +0000)]
Auto merge of #83596 - jyn514:session-dead-code, r=oli-obk
Remove dead or useless code from Session
This is a more principled follow-up to https://github.com/rust-lang/rust/pull/83185#discussion_r601753839.
- Rename `Parser::span_fatal_err` -> `Parser::span_err`
- Remove some unnecessary uses of `struct_span_fatal`
- Make `Diagnostic::span_fatal` unconditionally raise an error
- Add `impl Deref<Target = Handler>` for Session and remove all functions that are exactly the same as their Handler counterparts
- Note why `Handler::fatal` is different from `Sesssion::fatal`
- Remove unused `opt_span_warn` function
bors [Sun, 9 May 2021 11:17:17 +0000 (11:17 +0000)]
Auto merge of #85093 - camelid:remove-fake-expect_local, r=GuillaumeGomez
Remove `FakeDefId::expect_local()`
This function returned a fake `DefIndex`, with no indication that it was
fake, when it was provided with a `FakeDefId::Fake`. Every use of the
function uses the returned `DefIndex` in a call to
`tcx.local_def_id_to_hir_id()`, which I'm pretty sure would panic if it
were given a fake `DefIndex`.
I removed the function and replaced all calls to it with a call to
`expect_real()` followed by `DefId::expect_local()` (that's a function
on the *real* `DefId`).
Camelid [Sat, 8 May 2021 22:14:21 +0000 (15:14 -0700)]
Add `#[track_caller]` to `FakeDefId::expect_real()`
Now, in the case that the function is not inlined, the panic location
will be the caller's location, which is more helpful since the panic is
not `expect_real()`'s fault.
Camelid [Sat, 8 May 2021 22:03:15 +0000 (15:03 -0700)]
Remove `FakeDefId::expect_local()`
This function returned a fake `DefIndex`, with no indication that it was
fake, when it was provided with a `FakeDefId::Fake`. Every use of the
function uses the returned `DefIndex` in a call to
`tcx.local_def_id_to_hir_id()`, which I'm pretty sure would panic if it
were given a fake `DefIndex`.
I removed the function and replaced all calls to it with a call to
`expect_real()` followed by `DefId::expect_local()` (that's a function
on the *real* `DefId`).
bors [Sat, 8 May 2021 18:41:16 +0000 (18:41 +0000)]
Auto merge of #83278 - Amanieu:bump_stdarch, r=Mark-Simulacrum
Bump stdarch submodule
Major changes:
- More AVX-512 intrinsics.
- More ARM & AArch64 NEON intrinsics.
- Updated unstable WASM intrinsics to latest draft standards.
- Intrinsics that previously used `#[rustc_args_required_const]` now use const generics. See #83167 for more details.
- `std_detect` is now a separate crate instead of a submodule of `std`.
This doesn't seem to be necessary anymore, although I don't know
at which point or why that changed.
Forcing -O1 makes some tests fail under NewPM, because NewPM also
performs inlining at -O1, so it ends up performing much more
optimization in practice than before.
bors [Sat, 8 May 2021 05:50:00 +0000 (05:50 +0000)]
Auto merge of #85059 - ehuss:update-cargo, r=ehuss
Update cargo
7 commits in f3e13226d6d17a2bc5f325303494b43a45f53b7f..e51522ab3db23b0d8f1de54eb1f0113924896331
2021-04-30 21:50:27 +0000 to 2021-05-07 21:29:52 +0000
- Add CARGO_TARGET_TMPDIR env var for integration tests & benches (rust-lang/cargo#9375)
- Bump to 0.55.0, update changelog (rust-lang/cargo#9464)
- Some updates to the unstable documentation (rust-lang/cargo#9457)
- Add CARGO_PROFILE_<name>_SPLIT_DEBUGINFO to env docs. (rust-lang/cargo#9456)
- Add `report` subcommand. (rust-lang/cargo#9438)
- Respect Cargo.toml `[package.exclude]` even not in a git repo. (rust-lang/cargo#9186)
- Document the other crates in the codebase in the contrib guide. (rust-lang/cargo#9439)
bors [Sat, 8 May 2021 00:37:38 +0000 (00:37 +0000)]
Auto merge of #85057 - Dylan-DPC:rollup-efaseq2, r=Dylan-DPC
Rollup of 6 pull requests
Successful merges:
- #76808 (Improve diagnostics for functions in `struct` definitions)
- #84887 (Remove SpanInterner::get)
- #85034 (fix null pointer error messages)
- #85038 (Don't stop running rustdoc-gui tests at first failure)
- #85044 (Use `path.exists()` instead of `fs::metadata(path).is_ok()`)
- #85052 (rustdoc: Link to the docs on namespaces when an unknown disambiguator is found)
Dylan DPC [Fri, 7 May 2021 23:06:25 +0000 (01:06 +0200)]
Rollup merge of #85038 - GuillaumeGomez:dont-stop-first-rustdoc-gui-failure, r=Mark-Simulacrum
Don't stop running rustdoc-gui tests at first failure
I just realized that before this PR, the rustdoc-gui test suite was stopping at the first failure, which isn't very convenient. All tests are now running and if one failed, it returns an error at the end once all tests have run.
Dylan DPC [Fri, 7 May 2021 23:06:23 +0000 (01:06 +0200)]
Rollup merge of #84887 - jyn514:index-span, r=Xanewok
Remove SpanInterner::get
- It's used exactly once, so it's trivial to replace
- It doesn't match the normal convention for containers: normally
`get()` returns an option and indexing panics. Instead `SpanInterner::get()` panics
and there's no indexing operation available.
Dylan DPC [Fri, 7 May 2021 23:06:22 +0000 (01:06 +0200)]
Rollup merge of #76808 - LeSeulArtichaut:diagnose-functions-struct, r=jackh726
Improve diagnostics for functions in `struct` definitions
Tries to implement #76421.
This is probably going to need unit tests, but I wanted to hear from review all the cases tests should cover.
I'd like to follow up with the "mechanically applicable suggestion here that adds an impl block" step, but I'd need guidance. My idea for now would be to try to parse a function, and if that succeeds, create a dummy `ast::Item` impl block to then format it using `pprust`. Would that be a viable approach? Is there a better alternative?
bors [Fri, 7 May 2021 16:24:46 +0000 (16:24 +0000)]
Auto merge of #85036 - Dylan-DPC:rollup-4qfabo3, r=Dylan-DPC
Rollup of 9 pull requests
Successful merges:
- #84254 (illumos should put libc last in library search order)
- #84442 (Unify rustc and rustdoc parsing of `cfg()`)
- #84655 (Cleanup of `wasm`)
- #84866 (linker: Avoid library duplication with `/WHOLEARCHIVE`)
- #84930 (rename LLVM target for RustyHermit)
- #84991 (rustc: Support Rust-specific features in -Ctarget-feature)
- #85029 (SGX mutex is movable)
- #85030 (Rearrange SGX split module files)
- #85033 (some further small cleanups)
Dylan DPC [Fri, 7 May 2021 14:19:24 +0000 (16:19 +0200)]
Rollup merge of #85030 - jethrogb:jb/sgx-rearrange-files, r=nagisa
Rearrange SGX split module files
In #75979 several inlined modules were split out into multiple files.
This PR keeps the multiple files but moves a few things around to
organize things in a coherent way.
Dylan DPC [Fri, 7 May 2021 14:19:22 +0000 (16:19 +0200)]
Rollup merge of #84991 - alexcrichton:target-feature-remap, r=nagisa
rustc: Support Rust-specific features in -Ctarget-feature
Since the beginning of time the `-Ctarget-feature` flag on the command
line has largely been passed unmodified to LLVM. Afterwards, though, the
`#[target_feature]` attribute was stabilized and some of the names in
this attribute do not match the corresponding LLVM name. This is because
Rust doesn't always want to stabilize the exact feature name in LLVM for
the equivalent functionality in Rust. This creates a situation, however,
where in Rust you'd write:
This difference is somewhat odd to deal with if you're a newcomer and
the situation may be made worse with upcoming features like [WebAssembly
SIMD](https://github.com/rust-lang/rust/issues/74372) which may be more
prevalent.
This commit implements a mapping to translate requests via
`-Ctarget-feature` through the same name-mapping functionality that's
present for attributes in Rust going to LLVM. This means that
`+pclmulqdq` will work on x86 targets where as previously it did not.
I've attempted to keep this backwards-compatible where the compiler will
just opportunistically attempt to remap features found in
`-Ctarget-feature`, but if there's something it doesn't understand it
gets passed unmodified to LLVM just as it was before.
Dylan DPC [Fri, 7 May 2021 14:19:21 +0000 (16:19 +0200)]
Rollup merge of #84930 - hermitcore:target, r=nagisa
rename LLVM target for RustyHermit
- RustyHermit is a library operating system, where the user-
and the kernel-space use the same target
- by a mistake a previous patch changes the target to an incorect value
- this merge request revert the previous changes
Dylan DPC [Fri, 7 May 2021 14:19:20 +0000 (16:19 +0200)]
Rollup merge of #84655 - CDirkx:wasm, r=m-ou-se
Cleanup of `wasm`
Some more cleanup of `sys`, this time `wasm`
- Reuse `unsupported::args` (functionally equivalent implementation, just an empty iterator).
- Split out `atomics` implementation of `wasm::thread`, the non-`atomics` implementation is reused from `unsupported`.
- Move all of the `atomics` code to a separate directory `wasm/atomics`.
Dylan DPC [Fri, 7 May 2021 14:19:19 +0000 (16:19 +0200)]
Rollup merge of #84442 - jyn514:doc-cfg, r=petrochenkov
Unify rustc and rustdoc parsing of `cfg()`
This extracts a new `parse_cfg` function that's used between both.
- Treat `#[doc(cfg(x), cfg(y))]` the same as `#[doc(cfg(x)]
#[doc(cfg(y))]`. Previously it would be completely ignored.
- Treat `#[doc(inline, cfg(x))]` the same as `#[doc(inline)]
#[doc(cfg(x))]`. Previously, the cfg would be ignored.
- Pass the cfg predicate through to rustc_expand to be validated
Technically this is a breaking change, but doc_cfg is still nightly so I don't think it matters.
Both libc and libgcc_s provide an unwinder implementation, but libgcc_s
provides some extra symbols upon which Rust directly depends. If libc
is first in the NEEDED list we will find some of those symbols in libc
but others in libgcc_s, resulting in undefined behaviour as the two
implementations do not use compatible interior data structures.
This solution is not perfect, but is the simplest way to produce correct
binaries on illumos for now.
Jethro Beekman [Fri, 7 May 2021 11:40:43 +0000 (13:40 +0200)]
Rearrange SGX split module files
In #75979 several inlined modules were split out into multiple files.
This PR keeps the multiple files but moves a few things around to
organize things in a coherent way.
bors [Fri, 7 May 2021 10:06:40 +0000 (10:06 +0000)]
Auto merge of #84797 - richkadel:cover-unreachable-statements, r=tmandry
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.
If `instrument-coverage` is enabled, `simplify::remove_dead_blocks()`
finds all dropped coverage `Statement`s and adds their `code_region`s as
`Unreachable` coverage `Statement`s to the `START_BLOCK`, so they are
still included in the coverage map.
Check out the resulting changes in the test coverage reports in this PR (in [commit 1](https://github.com/rust-lang/rust/pull/84797/commits/0b0d293c7c46bdadf80e5304a667e34c53c0cf7e)).
Stefan Lankes [Tue, 4 May 2021 23:03:50 +0000 (01:03 +0200)]
rename LLVM target for RustyHermit
RustyHermit ist is a library operating system. In this case, we link a static library as kernel to the application. The final result is a bootable application. The library and the application have to use the same target. Currently, the targets are different (see also https://github.com/rust-lang/rust/blob/master/compiler/rustc_target/src/spec/x86_64_unknown_hermit.rs). Consequently, this commit change the LLVM target to 'hermit'.
This kernel spec is needed to disable the usage of FPU registers, which are not allowed in kernel space. In contrast to Linux, everything is running in ring 0 and also in the same address space.
Signed-off-by: Stefan Lankes <slankes@eonerc.rwth-aachen.de>
Yuki Okushi [Fri, 7 May 2021 06:20:26 +0000 (15:20 +0900)]
Rollup merge of #84897 - richkadel:cover-closure-macros, r=tmandry
Coverage instruments closure bodies in macros (not the macro body)
Fixes: #84884
This solution might be considered a compromise, but I think it is the
better choice.
The results in the `closure.rs` test correctly resolve all test cases
broken as described in #84884.
One test pattern (in both `closure_macro.rs` and
`closure_macro_async.rs`) was also affected, and removes coverage
statistics for the lines inside the closure, because the closure
includes a macro. (The coverage remains at the callsite of the macro, so
we lose some detail, but there isn't a perfect choice with macros.
Often macro implementations are split across the macro and the callsite,
and there doesn't appear to be a single "right choice" for which body
should be covered. For the current implementation, we can't do both.
The callsite is most likely to be the preferred site for coverage.
Yuki Okushi [Fri, 7 May 2021 06:20:25 +0000 (15:20 +0900)]
Rollup merge of #84875 - richkadel:no-coverage-dont-check-unused, r=tmandry
Removes unneeded check of `#[no_coverage]` in mapgen
There is an anticipated feature request to support a compiler flag that
only adds coverage for specific files (or perhaps mods). As I thought
about where that change would need to be supported, I realized that
checking the attribute in mapgen (for unused functions) was unnecessary.
The unused functions are only synthesized if they have MIR coverage, and
functions with the `no_coverage` attribute will not have been
instrumented with MIR coverage statements in the first place.
New tests confirm this.
Also, while adding tests, I updated resolved comments and FIXMEs in
other tests, and expanded comments and tests on one remaining issue that
is still not resolved.