Re-use std::sealed::Sealed in os/linux/process.
This uses `std::sealed::Sealed` in `std::os::linux::process` instead of defining new `Sealed` traits there.
Add back -Zno-profiler-runtime
This was removed by #85284 in favor of `-Zprofiler-runtime=<name>`.However the suggested `-Zprofiler-runtime=None` doesn't work because`None` is treated as a crate name.
Validate FFI-safety warnings on naked functions
Test that FFI-safety warnings don't get accidentally dropped on naked
functions. The big picture is that if you implement a naked function
with the Rust ABI you'll get a warning. Further, if you implement a
naked function with a standardized ABI, but use non-FFI-safe types you
will still get a warning.
rust-lang/rfcs#2774rust-lang/rfcs#2972
cc ``````@joshtriplett`````` ``````@Amanieu`````` ``````@haraldh``````
explicit_generic_args_with_impl_trait: fix min expected number of generics
Fixes#87718
The problem was that `synth_type_param_count` was already subtracted from `named_type_param_count`, so this ended up being subtracted again. This caused `expected_min` to overflow, and ultimately resulting in weird and wrong behaviour.
I've also added another test not present in the original issue but caused by the same bug.
Generate links to definition in rustdoc source code pages
## Description
This PR adds an option (disabled by default) to add links in the source code page on ident. So for for example:
```rust
mod other_module;
struct Foo;
fn bar() {}
fn x<T: other_module::Trait>(f: Foo, g: other_module::Whatever, t: &T) {
let f: Foo = Foo;
bar();
f.some_method();
}
```
In the example (mostly in the `x` function), `other_module::Trait`, `Foo`, `other_module::Whatever`, `bar` and `some_method` are now links (and `other_module` at the top too).
In case there is a type coming from another crate, it'll link to its documentation page and not its definition (but you can then click on `[src]` so I guess it's fine).
Another important detail: I voluntarily didn't add links for primitive types. I think we can discuss about adding links on them or not in a later PR (adding the support for them would require only a few lines).
Here is a video summing up everything I wrote above:
https://user-images.githubusercontent.com/3050060/114622354-21307b00-9cae-11eb-834d-f6d8178a37bd.mp4
## Performance impact
So, on my computer, the performance remains more or less the same (which is quite surprising but that's a nice surprise). Here are the numbers:
Without the option:
* core: 1m 21s
* alloc: 26.78s
* std: 27.30s
* proc_macro: 4.50s
With source to definition links generation (I enabled by default the option):
* core: 1m 25s
* alloc: 25.76s
* std: 27.07s
* proc_macro: 4.66s
So no real change here (again, I'm very surprised by this fact).
For the size of the generated source files (only taking into account the `src` folder here since it's the only one impacted) by running `du -shc .` (when I am in the source folder).
Without the option: 11.939 MB
With the option: 12.611 MB
So not a big change here either. In all those docs, I ran `grep -nR '<a class=' . | wc -l` and got 43917. So there are quite a lot of links added. :)
cc `@rust-lang/rustdoc`
r? `@jyn514`
Core features cleanup
This sorts and categorizes the `#![features]` in `core` and removes unused ones.
This is part of #87766
The following feature attributes were unnecessary and are removed:
```diff
// Library features:
-#![feature(bool_to_option)]
-#![feature(char_indices_offset)]
-#![feature(pin_deref_mut)]
-#![feature(str_split_as_str)]
-#![feature(str_split_inclusive_as_str)]
// Language features:
-#![feature(arbitrary_self_types)]
-#![feature(custom_inner_attributes)]
-#![feature(nll)]
```
Disable unused variable lint for naked functions
In most calling conventions, accessing function parameters may require
stack access. However, naked functions have no assembly prelude to set
up stack access. This is why naked functions may only contain a single
`asm!()` block. All parameter access is done inside the `asm!()` block,
so we cannot validate the liveness of the input parameters. Therefore,
we should disable the lint for naked functions.
rust-lang/rfcs#2774rust-lang/rfcs#2972
`@joshtriplett` `@Amanieu` `@haraldh`
bootstrap.py: use `git rev-list` for robustness
Use `git rev-list` instead of `git log` to be more robust against
UI changes in git. Also, use the full email address for bors,
because `--author` uses a substring match.
Based on #87513, but is separate because it's less minimal and may require additional manual testing.
~Open questions:~
* ~Should the `merge_base` search also use `--first-parent`?~
* ~Do we exclude non-merge commits from bors? There are a few, and I'm not sure what they have in common. Some of them look like squashes, and some look like they're in rollup branches.~
r? `@jyn514`
`@rustbot` label +A-rustbuild +C-cleanup
Allow more "unknown argument" strings from linker
Some toolchains emit slightly different errors, e.g.
ppc-vle-gcc: error: unrecognized option '-no-pie'
rustc: Fill out remaining parts of C-unwind ABI
This commit intends to fill out some of the remaining pieces of the
C-unwind ABI. This has a number of other changes with it though to move
this design space forward a bit. Notably contained within here is:
* On `panic=unwind`, the `extern "C"` ABI is now considered as "may
unwind". This fixes a longstanding soundness issue where if you
`panic!()` in an `extern "C"` function defined in Rust that's actually
UB because the LLVM representation for the function has the `nounwind`
attribute, but then you unwind.
* Whether or not a function unwinds now mainly considers the ABI of the
function instead of first checking the panic strategy. This fixes a
miscompile of `extern "C-unwind"` with `panic=abort` because that ABI
can still unwind.
* The aborting stub for non-unwinding ABIs with `panic=unwind` has been
reimplemented. Previously this was done as a small tweak during MIR
generation, but this has been moved to a separate and dedicated MIR
pass. This new pass will, for appropriate functions and function
calls, insert a `cleanup` landing pad for any function call that may
unwind within a function that is itself not allowed to unwind. Note
that this subtly changes some behavior from before where previously on
an unwind which was caught-to-abort it would run active destructors in
the function, and now it simply immediately aborts the process.
* The `#[unwind]` attribute has been removed and all users in tests and
such are now using `C-unwind` and `#![feature(c_unwind)]`.
I think this is largely the last piece of the RFC to implement.
Unfortunately I believe this is still not stabilizable as-is because
activating the feature gate changes the behavior of the existing `extern
"C"` ABI in a way that has no replacement. My thinking for how to enable
this is that we add support for the `C-unwind` ABI on stable Rust first,
and then after it hits stable we change the behavior of the `C` ABI.
That way anyone straddling stable/beta/nightly can switch to `C-unwind`
safely.
In most calling conventions, accessing function parameters may require
stack access. However, naked functions have no assembly prelude to set
up stack access. This is why naked functions may only contain a single
`asm!()` block. All parameter access is done inside the `asm!()` block,
so we cannot validate the liveness of the input parameters. Therefore,
we should disable the lint for naked functions.
rust-lang/rfcs#2774rust-lang/rfcs#2972
This test proves that naked functions are treated the same as regular
functions regarding unused function parameters. We will change this
behavior in the next patch.
#[inline] slice::Iter::advance_by
https://github.com/rust-lang/rust/pull/87387#issuecomment-891942661 was marked as a regression. One of the methods in the PR was missing an inline annotation unlike all the other methods on slice iterators.
Let's see if that makes a difference.
