11 commits in 0687daac28939c476df51778f5a1d1aff1a3fddf..a9bd2bbf31e4f92b5d3d8e80b22839d0cc7a2022
2021-03-28 13:33:56 -0400 to 2021-04-09 18:12:21 -0400
- Improve formatting and update info in "method lookup" section
- Change wording a bit: `module` => `crate`
- fix typo (rust-lang/rustc-dev-guide#1107)
- fix typo
- Mention CI build of LLVM in build instruction
- Fix rustdocs test command typo (rust-lang/rustc-dev-guide#1103)
- Update the "LLVM updates" section
- Fix a link about Rustdoc internals
- Add quickstart for adding a new optimization (rust-lang/rustc-dev-guide#1094)
- Add back example of {{cwd}} (rust-lang/rustc-dev-guide#1099)
- Document test input normalization
It was my impression that the goal for `std::sys` has changed from extracting it into a separate crate to making std work with features. However the fact remains that there is a lot of interdependence between `sys` and `sys_common`, this is because `sys_common` contains two types of code:
- abstractions over the different platform implementations in `std::sys` (for example [`std::sys_common::mutex`](https://github.com/rust-lang/rust/blob/master/library/std/src/sys_common/mutex.rs))
- code shared between platforms (for example [`std::sys_common::alloc`](https://github.com/rust-lang/rust/blob/master/library/std/src/sys_common/alloc.rs))
This PR attempts to address this by adding a new module `common` to `std::sys` which will contain code shared between platforms, `alloc.rs` in this case but more can be moved over in the future.
Auto merge of #83948 - ABouttefeux:lint-nullprt-deref, r=RalfJung
add lint deref_nullptr detecting when a null ptr is dereferenced
fixes #83856
changelog: add lint that detect code like
```rust
unsafe {
&*core::ptr::null::<i32>()
};
unsafe {
addr_of!(std::ptr::null::<i32>())
};
let x: i32 = unsafe {*core::ptr::null()};
let x: i32 = unsafe {*core::ptr::null_mut()};
unsafe {*(0 as *const i32)};
unsafe {*(core::ptr::null() as *const i32)};
```
```
warning: Dereferencing a null pointer causes undefined behavior
--> src\main.rs:5:26
|
5 | let x: i32 = unsafe {*core::ptr::null()};
| ^^^^^^^^^^^^^^^^^^
| |
| a null pointer is dereferenced
| this code causes undefined behavior when executed
|
= note: `#[warn(deref_nullptr)]` on by default
```
Limitation:
It does not detect code like
```rust
const ZERO: usize = 0;
unsafe {*(ZERO as *const i32)};
```
or code where `0` is not directly a literal
Auto merge of #84158 - cratelyn:patch-extern-c-unwind-behavior, r=nikomatsakis
move new c abi abort behavior behind feature gate
*Background*
In #76570, new ABI strings including `C-unwind` were introduced. Their
behavior is specified in RFC 2945 <sup>[1]</sup>.
However, it was reported in the #ffi-unwind stream of the Rust community Zulip
that this had altered the way that `extern "C"` functions behaved even when the
`c_unwind` feature gate was not active. <sup>[2]</sup>
*Overview*
This makes a small patch to `rustc_mir_build::build::should_abort_on_panic`, so
that the same behavior from before is in place when the `c_unwind` gate is not
active.
`rustc_middle::ty::layout::fn_can_unwind` is not touched, as the visible
behavior should not differ before/after #76570. <sup>[3]</sup>
Auto merge of #83068 - mockersf:method-trait-foreign-impl, r=GuillaumeGomez
rustdoc: links from items in a trait impl are inconsistent
Depending on where the struct implementing a trait is coming from, or the current page, the items in a trait impl are not linking to the same thing:
|item| trait page, implementors| trait page, implementations on Foreign Types|struct page, trait implementations|
|-|-|-|-|
|function| link to current impl|link to first impl in the list|link to trait def
|default function | not present |not present |link to trait def
|default function with custom impl|link to current impl|link to trait def |link to trait def
|constant| link to current impl|link to trait def |link to trait def
|associated type| link to current impl|link to trait def |link to trait def
||*missing link to trait def*|*function link wrong + missing link to current impl*|*missing link to current impl*|
<details>
<summary>rust code with those cases</summary>
impl MyTrait for String {
/// will link to trait def
type Assoc = ();
/// will link to trait def
const VALUE: u32 = 5;
/// will link to first foreign implementor
fn trait_function(&self) {}
/// will link to trait def
fn defaulted_override(&self) {}
}
impl MyTrait for Vec<u8> {
/// will link to trait def
type Assoc = ();
/// will link to trait def
const VALUE: u32 = 5;
/// will link to first foreign implementor
fn trait_function(&self) {}
/// will link to trait def
fn defaulted_override(&self) {}
}
impl MyTrait for MyStruct {
/// in trait page, will link to current impl
///
/// in struct page, will link to trait def
type Assoc = bool;
/// in trait page, will link to current impl
///
/// in struct page, will link to trait def
const VALUE: u32 = 20;
/// in trait page, will link to current impl
///
/// in struct page, will link to trait def
fn trait_function(&self) {}
/// in trait page, will link to current impl
///
/// in struct page, will link to trait def
fn defaulted_override(&self) {}
}
pub struct MyStruct;
```
</details>
In this PR, I fixed all links to target the trait definition, and added an anchor-link to the current implementation appearing on mouse hover.
Auto merge of #84135 - rust-lang:GuillaumeGomez-patch-1, r=kennytm
Improve code example for length comparison
Small fix/improvement: it's much safer to check that you're under the length of an array rather than chacking that you're equal to it. It's even more true in case you update the length of the array while iterating.
In #76570, new ABI strings including `C-unwind` were introduced.
Their behavior is specified in RFC 2945 [1].
However, it was reported in the #ffi-unwind stream of the Rust
community Zulip that this had altered the way that `extern "C"`
functions behaved even when the `c_unwind` feature gate was not
active. [2]
### Overview
This makes a small patch to
`rustc_mir_build::build::should_abort_on_panic`, so that the same
behavior from before is in place when the `c_unwind` gate is not
active.
`rustc_middle::ty::layout::fn_can_unwind` is not touched, as the
visible behavior should not differ before/after #76570. [3]
Rollup merge of #84141 - camelid:fix-typo, r=Dylan-DPC
Fix typo in error message
Also tweaked the message a bit by
- removing the hyphen, because in my opinion the hyphen makes the
message a bit harder to read, especially combined with the backticks;
- adding the word "be", because I think it's a bit clearer that way.
This is an approved feature on BTree{Map,Set} to mirror a functionality in Hash{Map,Set}, which has had some adequate testing since its introduction in https://github.com/rust-lang/rust/pull/79026 and doesn't seem to have caused any problems since.
Rollup merge of #83438 - CDirkx:releases, r=Mark-Simulacrum
Update RELEASES.md
A couple of things that were missing in the release notes:
- `Div` and `Rem` by their `NonZero` variant is now implemented for all unsigned integers (#79134)
- Stabilization of `VecDeque::range` and `VecDeque::range_mut` (#79022, stabilization version corrected to 1.51.0 #80448)
- Deprecation of `spin_loop_hint` (#80966)
Auto merge of #82992 - philippeitis:stabilize_bufreader_seek_relative, r=workingjubilee
Stabilize `bufreader_seek_relative`
This PR marks `BufReader::seek_relative` as stable - the associated issue, #31100, has passed the final comment period without any issues, and from what I understand, the only thing left to stabilize this is to submit a PR marking the method as stable.
Auto merge of #82918 - Manishearth:edition-2015-warn, r=oli-obk
Turn old edition lint (anonymous-parameters) into warn-by-default on 2015
This makes `anonymous_parameters` <s>and `keyword_idents` </s>warn-by-default on the 2015 edition. I would also like to do this for `absolute_paths_not_starting_with_crate`, but I feel that case is slightly less clear-cut.
Note that this only affects code on the 2015 edition, such code is illegal in future editions anyway.
This was spurred by https://github.com/dtolnay/syn/issues/972: old edition syntax breaks tooling (like syn), and while the tooling should be free to find its balance on how much to support prior editions, it does seem like we should be nudging such code towards the newer edition, and we can do that by turning this Allow lint into a Warn.
In general, I feel like migration lints from an old edition should be made Warn after a year or so, and idiom lints for the new edition should be made Warn after a couple months.
cc `@m-ou-se,` this is for stuff from the 2015-2018 migration but you might be interested.
- removing the hyphen, because in my opinion the hyphen makes the
message a bit harder to read, especially combined with the backticks;
- adding the word "be", because I think it's a bit clearer that way.
Auto merge of #83776 - jyn514:update-stdarch-docs, r=Amanieu
Update stdarch submodule (to before it switched to const generics)
https://github.com/rust-lang/rust/pull/83278#issuecomment-812389823: This unblocks #82539.
Major changes:
- More AVX-512 intrinsics.
- More ARM & AArch64 NEON intrinsics.
- Updated unstable WASM intrinsics to latest draft standards.
- std_detect is now a separate crate instead of a submodule of std.
I double-checked and the first use of const generics looks like https://github.com/rust-lang/stdarch/commit/8d5017861ed594a2baf169e632379862d516e013, which isn't included in this PR.
Joshua Nelson [Fri, 2 Apr 2021 08:11:46 +0000 (04:11 -0400)]
Update stdarch submodule (to before it switched to const generics)
This also includes a cherry-pick of
https://github.com/rust-lang/stdarch/commit/ec1461905b421cf0c56adeebb49bbf55bb33fd17
and https://github.com/rust-lang/stdarch/pull/1108 to fix a build
failure.
It also adds a re-export of various macros to the crate root of libstd -
previously they would show up automatically because std_detect was defined
in the same crate.
Rollup merge of #84101 - jyn514:early-pass, r=Manishearth
rustdoc: Move crate loader to collect_intra_doc_links::early
This groups the similar code together, and also allows making most of collect_intra_doc_links private again.
This builds on https://github.com/rust-lang/rust/pull/84066, but it wouldn't be too hard to base it off master if you want this to land first.
Helps with https://github.com/rust-lang/rust/issues/83761.
Rollup merge of #84067 - rust-lang:steveklabnik-patch-1, r=joshtriplett
clean up example on read_to_string
This is the same thing, but simpler.
This came out of a comment from a user: https://news.ycombinator.com/item?id=25318117 but rather than hide the signature of main, I think a `use` plus not including the `'static` makes more sense.
Rollup merge of #84059 - zvirja:update-libc, r=JohnTitor
Bump libc dependency of std to 0.2.93
Update `libc` dependency of `std` to the latest version. That allows to consume the https://github.com/rust-lang/libc/pull/2131 fix and fix build for the `mipsel-unknown-linux-uclibc` target.
Rollup merge of #84014 - estebank:cool-bears-hot-tip, r=varkor
Improve trait/impl method discrepancy errors
* Use more accurate spans
* Clean up some code by removing previous hack
* Provide structured suggestions
Structured suggestions are particularly useful for cases where arbitrary self types are used, like in custom `Future`s, because the way to write `self: Pin<&mut Self>` is not necessarily self-evident when first encountered.
Rollup merge of #83669 - kwj2104:issue-81508-fix, r=varkor
Issue 81508 fix
Fix #81508
**Problem**: When variable name is used incorrectly as path, error and warning point to undeclared/unused name, when in fact the name is used, just incorrectly (should be used as a variable, not part of a path).
**Summary for fix**: When path resolution errs, diagnostics checks for variables in ```ValueNS``` that have the same name (e.g., variable rather than path named Foo), and adds additional suggestion that user may actually intend to use the variable name rather than a path.
The fix does not suppress or otherwise change the *warning* that results. I did not find a straightforward way in the code to modify this, but would love to make changes here as well with any guidance.
Allow using `-C force-unwind-tables=no` when `panic=unwind`
It seems LLVM still generates proper unwind tables even there is no `uwtable` attribute, unless I looked at the wrong place :thinking::
https://github.com/llvm/llvm-project/blob/c21016715f0ee4a36affdf7150ac135ca98b0eae/llvm/include/llvm/IR/Function.h#L666
Therefore, I *assume* it's safe to omit `uwtable` even when `panic=unwind`, and this PR removes the restriction that disallows using `-C force-unwind-tables=no` when `panic=unwind`.
Auto merge of #81469 - tweksteen:android_set_message, r=m-ou-se
android: set abort message
Android has the ability to supply an abort message [1]. This message is
automatically included in the debug trace, which helps debugging [2].
Modify panic_abort to populate this message before calling abort().
Add note about reverting a workaround in the future
The root cause was fixed upstream in LLVM main. This adds a reminder to revert the workaround once the LLVM rustc depends on is new enough. Since I'm not sure how such optimizations get routed to LLVM releases, I used the conservative assumption that it will only show up with LLVM 13.
Auto merge of #82608 - Aaron1011:feature/final-preexp-tts, r=petrochenkov
Implement token-based handling of attributes during expansion
This PR modifies the macro expansion infrastructure to handle attributes
in a fully token-based manner. As a result:
* Derives macros no longer lose spans when their input is modified
by eager cfg-expansion. This is accomplished by performing eager
cfg-expansion on the token stream that we pass to the derive
proc-macro
* Inner attributes now preserve spans in all cases, including when we
have multiple inner attributes in a row.
This is accomplished through the following changes:
* New structs `AttrAnnotatedTokenStream` and `AttrAnnotatedTokenTree` are introduced.
These are very similar to a normal `TokenTree`, but they also track
the position of attributes and attribute targets within the stream.
They are built when we collect tokens during parsing.
An `AttrAnnotatedTokenStream` is converted to a regular `TokenStream` when
we invoke a macro.
* Token capturing and `LazyTokenStream` are modified to work with
`AttrAnnotatedTokenStream`. A new `ReplaceRange` type is introduced, which
is created during the parsing of a nested AST node to make the 'outer'
AST node aware of the attributes and attribute target stored deeper in the token stream.
* When we need to perform eager cfg-expansion (either due to `#[derive]` or `#[cfg_eval]`), we tokenize and reparse our target, capturing additional information about the locations of `#[cfg]` and `#[cfg_attr]` attributes at any depth within the target. This is a performance optimization, allowing us to perform less work in the typical case where captured tokens never have eager cfg-expansion run.
Aaron Hill [Sat, 28 Nov 2020 23:33:17 +0000 (18:33 -0500)]
Implement token-based handling of attributes during expansion
This PR modifies the macro expansion infrastructure to handle attributes
in a fully token-based manner. As a result:
* Derives macros no longer lose spans when their input is modified
by eager cfg-expansion. This is accomplished by performing eager
cfg-expansion on the token stream that we pass to the derive
proc-macro
* Inner attributes now preserve spans in all cases, including when we
have multiple inner attributes in a row.
This is accomplished through the following changes:
* New structs `AttrAnnotatedTokenStream` and `AttrAnnotatedTokenTree` are introduced.
These are very similar to a normal `TokenTree`, but they also track
the position of attributes and attribute targets within the stream.
They are built when we collect tokens during parsing.
An `AttrAnnotatedTokenStream` is converted to a regular `TokenStream` when
we invoke a macro.
* Token capturing and `LazyTokenStream` are modified to work with
`AttrAnnotatedTokenStream`. A new `ReplaceRange` type is introduced, which
is created during the parsing of a nested AST node to make the 'outer'
AST node aware of the attributes and attribute target stored deeper in the token stream.
* When we need to perform eager cfg-expansion (either due to `#[derive]` or `#[cfg_eval]`),
we tokenize and reparse our target, capturing additional information about the locations of
`#[cfg]` and `#[cfg_attr]` attributes at any depth within the target.
This is a performance optimization, allowing us to perform less work
in the typical case where captured tokens never have eager cfg-expansion run.
Auto merge of #84071 - nagisa:nixos-patching-fix, r=Mark-Simulacrum
Fix NixOS patching
Moving the `.nix-deps` has resulted in rpath links being broken and
therefore bootstrap on NixOS broken entirely.
This PR still produces a `.nix-deps` but only for the purposes of
producing a gc root. We rpath a symlink-resolved result instead.
For purposes of simplicity we also use joinSymlink to produce a single
merged output directory so that we don't need to update multiple
locations every time we add a library or something.
Fixes a regression from https://github.com/rust-lang/rust/pull/82739.
The lint used to be called `non-autolinks`, and linted more than just
bare URLs. Now, it is called `bare-urls` and only lints against bare
URLs. So, `bare-urls` is a better name for the test.
Moving the `.nix-deps` has resulted in rpath links being broken and
therefore bootstrap on NixOS broken entirely.
This PR still produces a `.nix-deps` but only for the purposes of
producing a gc root. We rpath a symlink-resolved result instead.
For purposes of simplicity we also use joinSymlink to produce a single
merged output directory so that we don't need to update multiple
locations every time we add a library or something.