Guillaume Gomez [Tue, 18 May 2021 12:08:51 +0000 (14:08 +0200)]
Rollup merge of #85339 - FabianWolff:issue-83893, r=varkor
Report an error if a lang item has the wrong number of generic arguments
This pull request fixes #83893. The issue is that the lang item code currently checks whether the lang item has the correct item kind (e.g. a `#[lang="add"]` has to be a trait), but not whether the item has the correct number of generic arguments.
This can lead to an "index out of bounds" ICE when the compiler tries to create more substitutions than there are suitable types available (if the lang item was declared with too many generic arguments).
For instance, here is a reduced ("reduced" in the sense that it does not trigger additional errors) version of the example given in #83893:
```rust
#![feature(lang_items,no_core)]
#![no_core]
#![crate_type="lib"]
#[lang = "sized"]
trait MySized {}
#[lang = "add"]
trait MyAdd<'a, T> {}
fn ice() {
let r = 5;
let a = 6;
r + a
}
```
On current nightly, this immediately causes an ICE without any warnings or errors emitted. With the changes in this PR, however, I get no ICE and two errors:
```
error[E0718]: `add` language item must be applied to a trait with 1 generic argument
--> pr-ex.rs:8:1
|
8 | #[lang = "add"]
| ^^^^^^^^^^^^^^^
9 | trait MyAdd<'a, T> {}
| ------- this trait has 2 generic arguments, not 1
error[E0369]: cannot add `{integer}` to `{integer}`
--> pr-ex.rs:14:7
|
14 | r + a
| - ^ - {integer}
| |
| {integer}
error: aborting due to 2 previous errors
Some errors have detailed explanations: E0369, E0718.
For more information about an error, try `rustc --explain E0369`.
```
Guillaume Gomez [Tue, 18 May 2021 12:08:46 +0000 (14:08 +0200)]
Rollup merge of #85338 - lopopolo:core-iter-repeat-gh-81292, r=joshtriplett
Implement more Iterator methods on core::iter::Repeat
`core::iter::Repeat` always returns the same element, which means we can
do better than implementing most `Iterator` methods in terms of
`Iterator::next`.
Fixes #81292.
#81292 raises the question of whether these changes violate the contract of `core::iter::Repeat`, but as far as I can tell `core::iter::repeat` doesn't make any guarantees around how it calls `Clone::clone`.
Guillaume Gomez [Tue, 18 May 2021 12:08:42 +0000 (14:08 +0200)]
Rollup merge of #85280 - jsha:move-trait-toggles, r=GuillaumeGomez
Toggle-wrap items differently than top-doc.
This makes sure things like trait methods get wrapped at the
`<h3><code>` level rather than at the `.docblock` level. Also it ensures
that only the actual top documentation gets the `.top-doc` class.
Guillaume Gomez [Tue, 18 May 2021 12:08:41 +0000 (14:08 +0200)]
Rollup merge of #84587 - jyn514:rustdoc-lint-block, r=CraftSpider
rustdoc: Make "rust code block is empty" and "could not parse code block" warnings a lint (`INVALID_RUST_CODEBLOCKS`)
Fixes https://github.com/rust-lang/rust/issues/79792. This already went through FCP in https://github.com/rust-lang/rust/pull/79816, so it only needs final review.
This is mostly a rebase of https://github.com/rust-lang/rust/pull/79816 - thank you ``@poliorcetics`` for doing most of the work!
bors [Tue, 18 May 2021 08:01:32 +0000 (08:01 +0000)]
Auto merge of #82973 - ijackson:exitstatuserror, r=yaahc
Provide ExitStatusError
Closes #73125
In MR #81452 "Add #[must_use] to [...] process::ExitStatus" we concluded that the existing arrangements in are too awkward so adding that `#[must_use]` is blocked on improving the ergonomics.
I wrote a mini-RFC-style discusion of the approach in https://github.com/rust-lang/rust/issues/73125#issuecomment-771092741
Lee Bradley [Tue, 18 May 2021 05:33:17 +0000 (00:33 -0500)]
Add x.py pre-setup instructions
This change adds pre-setup instructions that outline how x.py requires
python to be setup and how to work around the problem of x.py failing to
locate python, especially now that Ubuntu 20.04's dropped default python
command is causing people to encounter this issue regularly.
#[path = concat!(env!("OUT_DIR"), "/generated.rs")]
mod m;
```
See the changes to the reference for details on what macros are allowed;
see Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455)
for alternatives that were considered and rejected ("why accept no more
and no less?")
This has been available on nightly since 1.50 with no major issues.
## Notes
### Accepted syntax
The parser accepts arbitrary Rust expressions in this position, but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g., `#[doc]`). Note that decorators and the like may be able to observe other expression forms.
### Expansion ordering
Expansion of macro expressions in "inert" attributes occurs after decorators have executed, analogously to macro expressions appearing in the function body or other parts of decorator input.
There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion, that can work).
- Initial proposal: https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412
- Experiment to see how much code it would break: https://github.com/rust-lang/rust/pull/67121
- Preliminary work to restrict expansion that would conflict with this
feature: https://github.com/rust-lang/rust/pull/77271
- Initial implementation: https://github.com/rust-lang/rust/pull/78837
- Fix for an ICE: https://github.com/rust-lang/rust/pull/80563
## Unresolved Questions
~~https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738 listed some concerns, but they have been resolved as of this final report.~~
## Additional Information
There are two workarounds that have a similar effect for `#[doc]`
attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons:
forward_inner_docs!(include_str!("lib.rs") => struct S {});
```
This also works for other attributes (like `#[path = concat!(...)]`).
The other is to use `doc(include)`:
```rust
#![feature(external_doc)]
#[doc(include = "lib.rs")]
struct S {}
```
The first works, but is non-trivial for people to discover, and
difficult to read and maintain. The second is a strange special-case for
a particular use of the macro. This generalizes it to work for any use
case, not just including files.
I plan to remove `doc(include)` when this is stabilized. The
`forward_inner_docs` workaround will still compile without warnings, but
I expect it to be used less once it's no longer necessary.
Alexis Bourget [Mon, 28 Dec 2020 22:07:20 +0000 (23:07 +0100)]
New rustdoc lint to respect -Dwarnings correctly
This adds a new lint to `rustc` that is used in rustdoc when a code
block is empty or cannot be parsed as valid Rust code.
Previously this was unconditionally a warning. As such some
documentation comments were (unknowingly) abusing this to pass despite
the `-Dwarnings` used when compiling `rustc`, this should not be the
case anymore.
bors [Mon, 17 May 2021 19:15:21 +0000 (19:15 +0000)]
Auto merge of #85414 - RalfJung:rollup-ueqcik4, r=RalfJung
Rollup of 8 pull requests
Successful merges:
- #85087 (`eval_fn_call`: check the ABI of `body.source`)
- #85302 (Expand WASI abbreviation in docs)
- #85355 (More tests for issue-85255)
- #85367 (Fix invalid input:disabled CSS selector)
- #85374 (mark internal inplace_iteration traits as hidden)
- #85408 (remove size field from Allocation)
- #85409 (Simplify `cfg(any(unix, target_os="redox"))` in example to just `cfg(unix)`)
- #85412 (remove some functions that were only used by Miri)
In https://reviews.llvm.org/D102093 lots of things stopped taking the
DebugLogging boolean parameter. Mercifully we appear to always set
DebugPassManager to false, so I don't think we're losing anything by not
passing this parameter.
Ralf Jung [Mon, 17 May 2021 16:52:13 +0000 (18:52 +0200)]
Rollup merge of #85409 - CDirkx:cfg_redox, r=nagisa
Simplify `cfg(any(unix, target_os="redox"))` in example to just `cfg(unix)`
Update example for `OsString` that handled `redox` seperately from `unix`: Redox has been completely integrated under `target_family="unix"`, so `cfg(unix)` implies `target_os="redox"`
Ralf Jung [Mon, 17 May 2021 16:52:04 +0000 (18:52 +0200)]
Rollup merge of #85302 - r00ster91:patch-7, r=joshtriplett
Expand WASI abbreviation in docs
I was pretty sure this was related to something for WebAssembly but wasn't 100% sure so I checked but even on these top-level docs I couldn't find the abbreviation expanded. I'm normally used to Rust docs being detailed and explanatory and writing abbreviations like this out in full at least once so I thought it was worth the change. Feel free to close this if it's too much.
Ralf Jung [Mon, 17 May 2021 16:51:59 +0000 (18:51 +0200)]
Rollup merge of #85087 - hyd-dev:lots-of-abis, r=RalfJung
`eval_fn_call`: check the ABI of `body.source`
And stop checking `instance_ty.fn_sig(*self.tcx).abi()`, if the function is not an intrinsic.
Addresses https://github.com/rust-lang/miri/pull/1776#discussion_r615381169.
No idea how to test this without Miri...
bors [Mon, 17 May 2021 16:34:11 +0000 (16:34 +0000)]
Auto merge of #85352 - Xanewok:update-rls, r=Xanewok
Update RLS
Contains https://github.com/rust-lang/rls/pull/1736. With #82208 merged, this should now close https://github.com/rust-lang/rust/issues/85225. Tested locally with `./x.py test src/tools/rls` and seems to be working as expected.
I noticed the rustfmt merge didn't trigger toolstate upgrade (because we pruned most but not all of the related machinery?), so I'd rather get this rubber-stamped by someone more knowledgeable with infra/the merged changes in case I missed something and need to include something else here to unbreak the RLS toolstate.
bors [Sun, 16 May 2021 23:00:53 +0000 (23:00 +0000)]
Auto merge of #84993 - eddyb:cg-ssa-on-demand-blocks, r=nagisa
rustc_codegen_ssa: only create backend `BasicBlock`s as-needed.
Instead of creating one backend (e.g. LLVM) block per MIR block ahead of time, and then deleting the ones that weren't visited, this PR moves to creating the blocks as they're needed (either reached via the RPO visit, or used as the target of a branch from a different block).
As deleting a block was the only `unsafe` builder method (generally we only *create* backend objects, not *remove* them), that's gone now and codegen is overall a bit safer.
The only change in output is the order of LLVM blocks (which AFAIK has no semantic meaning, other than the first block being the entry block). This happens because the blocks are now created due to control-flow edges, rather than MIR block order.
I'm making this a standalone PR because I keep getting wild perf results when I change *anything* in codegen, but if you want to read more about my plans in this area, see https://github.com/rust-lang/rust/pull/84771#issuecomment-830636256 (and https://github.com/rust-lang/rust/pull/84771#issue-628295651 - but that may be a bit outdated).
(You may notice some of the APIs in this PR, like `append_block`, don't help with the future plans - but I didn't want to include the necessary refactors that pass a build around everywhere, in this PR, so it's a small compromise)
bors [Sun, 16 May 2021 20:19:45 +0000 (20:19 +0000)]
Auto merge of #85312 - ehuss:macro_use-unused-attr, r=petrochenkov
Fix unused attributes on macro_rules.
The `unused_attributes` lint wasn't firing on attributes of `macro_rules` definitions. The consequence is that many attributes are silently ignored on `macro_rules`. The reason is that `unused_attributes` is a late-lint pass, and only has access to the HIR, which does not have macro_rules definitions.
My solution here is to change `non_exported_macro_attrs` to be `macro_attrs` (a list of all attributes used for `macro_rules`, instead of just those for `macro_export`), and then to check this list in the `unused_attributes` lint. There are a number of alternate approaches, but this seemed the most reliable and least invasive. I am open to completely different approaches, though.
One concern is that I don't fully understand the implications of extending `non_exported_macro_attrs` to include non-exported macros. That list was originally added in #62042 to handle stability attributes, so I suspect it was just an optimization since that was all that was needed. It was later extended to be included in SVH in #83901. #80641 also added a use to check for `invalid` attributes, which seems a little odd to me (it didn't validate non-exported macros, and seems highly specific).
Overall, there doesn't seem to be a clear story of when `unused_attributes` should be used versus an error like E0518. I considered alternatively using an "allow list" of built-in attributes that can be used on macro_rules (allow, warn, deny, forbid, cfg, cfg_attr, macro_export, deprecated, doc), but I feel like that could be a pain to maintain.
Some built-in attributes already present hard-errors when used with macro_rules. These are each hard-coded in various places:
- `derive`
- `test` and `bench`
- `proc_macro` and `proc_macro_derive`
- `inline`
- `global_allocator`
The primary motivation is that I sometimes see people use `#[macro_use]` in front of `macro_rules`, which indicates there is some confusion out there (evident that there was even a case of it in rustc).
bors [Sun, 16 May 2021 15:11:48 +0000 (15:11 +0000)]
Auto merge of #84549 - tmiasko:static-initializer, r=varkor
Reachable statics have reachable initializers
Static initializer can read other statics. Initializers are evaluated at
compile time, and so their content could become inlined into another
crate. Ensure that initializers of reachable statics are also reachable.
Previously, when an item incorrectly considered to be unreachable was
reached from another crate an attempt would be made to codegen it. The
attempt could fail with an ICE (in the case MIR wasn't available to do
so) in some circumstances the attempt could also succeed resulting in
a local codegen of non-local items, including static ones.
bors [Sun, 16 May 2021 12:30:07 +0000 (12:30 +0000)]
Auto merge of #85316 - eddyb:cg-ssa-on-demand-cleanuppad, r=nagisa
rustc_codegen_ssa: generate MSVC cleanup pads on demand, like GNU landing pads.
This unblocks #84993 in terms of codegen tests, as it brings the MSVC-style (`cleanup_pad`) EH (LLVM) block order in line with the GNU-style (`landing_pad`) EH (LLVM) block order, by having both of them be on-demand (instead of MSVC-style being eager and GNU-style lazy/on-demand).
It also unifies the two implementations a bit, similar to #84699, but in the opposite direction (as that attempt made both kinds of EH pads eagerly built).
~~Opening as draft because I haven't done enough Windows testing just yet, of both this PR, and of #84993 rebased on it.~~ (**EDIT**: seems to be working as expected)
bors [Sun, 16 May 2021 09:49:12 +0000 (09:49 +0000)]
Auto merge of #85332 - RalfJung:ptr-in-str, r=oli-obk
CTFE validation: handle pointers in str
I also finally learned how I can match *some* NOTEs in a ui test without matching all of them, and applied that to some const tests in the 2nd commit where I added NOTE because I did not know what I was doing. I can separate this into its own PR if you prefer.
bors [Sun, 16 May 2021 00:54:01 +0000 (00:54 +0000)]
Auto merge of #85259 - Smittyvb:thir-unsafeck-inline-asm, r=nikomatsakis
Check for inline assembly in THIR unsafeck
#83129 was merged recently and added a THIR unsafe checker. This adds a check for inline assembly. (and this is 2x simpler than the MIR version, which has to check for `asm` and `llvm_asm` in two separate spots!)
bors [Sat, 15 May 2021 22:27:09 +0000 (22:27 +0000)]
Auto merge of #81858 - ijackson:fork-no-unwind, r=m-ou-se
Do not allocate or unwind after fork
### Objective scenarios
* Make (simple) panics safe in `Command::pre_exec_hook`, including most `panic!` calls, `Option::unwrap`, and array bounds check failures.
* Make it possible to `libc::fork` and then safely panic in the child (needed for the above, but this requirement means exposing the new raw hook API which the `Command` implementation needs).
* In singlethreaded programs, where panic in `pre_exec_hook` is already memory-safe, prevent the double-unwinding malfunction #79740.
I think we want to make panic after fork safe even though the post-fork child environment is only experienced by users of `unsafe`, beause the subset of Rust in which any panic is UB is really far too hazardous and unnatural.
#### Approach
* Provide a way for a program to, at runtime, switch to having panics abort. This makes it possible to panic without making *any* heap allocations, which is needed because on some platforms malloc is UB in a child forked from a multithreaded program (see https://github.com/rust-lang/rust/pull/80263#issuecomment-774272370, and maybe also the SuS [spec](https://pubs.opengroup.org/onlinepubs/9699919799/functions/fork.html)).
* Make that change in the child spawned by `Command`.
* Document the rules comprehensively enough that a programmer has a fighting chance of writing correct code.
* Test that this all works as expected (and in particular, that there aren't any heap allocations we missed)
* Change the panic machinery to be able to unwind without allocating, at least when the payload and message are both `'static`. This seems like it would be even more subtle. Also that is a potentially-hot path which I don't want to mess with.
* Change the existing panic hook mechanism to not convert the message to a `String` before calling the hook. This would be a surprising change for existing code and would not be detected by the type system.
* Provide a `raw_panic_hook` function to intercept panics in a way that doesn't allocate. (That was an earlier version of this MR.)
### History
This MR could be considered a v2 of #80263. Thanks to everyone who commented there. In particular, thanks to `@m-ou-se,` `@Mark-Simulacrum` and `@hyd-dev.` (Tagging you since I think you might be interested in this new MR.) Compared to #80263, this MR has very substantial changes and additions.
Additionally, I have recently (2021-04-20) completely revised this series following very helpful comments from `@m-ou-se.`
bors [Sat, 15 May 2021 19:58:59 +0000 (19:58 +0000)]
Auto merge of #84920 - Aaron1011:pretty-print-rental, r=petrochenkov
Remove some unncessary spaces from pretty-printed tokenstream output
In addition to making the output look nicer for all crates, this also
aligns the pretty-printing output with what the `rental` crate expects.
This will allow us to eventually disable a backwards-compat hack in a
follow-up PR.
See https://github.com/rust-lang/rust/issues/84428 for some background information about why we want to make this change. Note that this change would be desirable (but not particularly necessary) even if `rental` didn't exist, so we're not adding any crate-specific hacks into the compiler.
Ryan Lopopolo [Sat, 15 May 2021 17:37:05 +0000 (10:37 -0700)]
Implement more Iterator methods on core::iter::Repeat
`core::iter::Repeat` always returns the same element, which means we can
do better than implementing most `Iterator` methods in terms of
`Iterator::next`.
Aaron Hill [Sat, 1 May 2021 19:54:47 +0000 (15:54 -0400)]
Remove some unncessary spaces from pretty-printed tokenstream output
In addition to making the output look nicer for all crates, this also
aligns the pretty-printing output with what the `rental` crate expects.
This will allow us to eventually disable a backwards-compat hack in a
follow-up PR.
Guillaume Gomez [Sat, 15 May 2021 15:56:50 +0000 (17:56 +0200)]
Rollup merge of #85329 - RalfJung:version, r=Mark-Simulacrum
fix version_str comment
This version string is ultimately generated here
https://github.com/rust-lang/rust/blob/87423fbc6af5aae2b5f6d0a11f2a0c60c7c22e98/src/bootstrap/channel.rs#L72
and I don't think it includes the `rustc` prefix. That also matches its use here
https://github.com/rust-lang/rust/blob/ac923d94f86a6f7c881ecbedcd0a68d7986a35bd/compiler/rustc_driver/src/lib.rs#L758
Guillaume Gomez [Sat, 15 May 2021 15:56:49 +0000 (17:56 +0200)]
Rollup merge of #85324 - FabianWolff:issue-85255, r=varkor
Warn about unused `pub` fields in non-`pub` structs
This pull request fixes #85255. The current implementation of dead code analysis is too prudent because it marks all `pub` fields of structs as live, even though they cannot be accessed from outside of the current crate if the struct itself only has restricted or private visibility.
I have changed this behavior to take the containing struct's visibility into account when looking at field visibility and liveness. This also makes dead code warnings more consistent; consider the example given in #85255:
```rust
struct Foo {
a: i32,
pub b: i32,
}
fn main() {
let _ = Foo { a: 1, b: 2 };
let _ = Bar;
}
```
Current nightly already warns about `Bar::b()`, even though it is `pub` (but `Bar` is not). It should therefore also warn about `Foo::b`, which it does with the changes in this PR.
Guillaume Gomez [Sat, 15 May 2021 15:56:47 +0000 (17:56 +0200)]
Rollup merge of #84751 - Soveu:is_char_boundary_opt, r=Amanieu
str::is_char_boundary - slight optimization
Current `str::is_char_boundary` implementation emits slightly more instructions, because it includes an additional branch for `index == s.len()`
```rust
pub fn is_char_boundary(s: &str, index: usize) -> bool {
if index == 0 || index == s.len() {
return true;
}
match s.as_bytes().get(index) {
None => false,
Some(&b) => (b as i8) >= -0x40,
}
}
```
Just changing the place of `index == s.len()` merges it with `index < s.len()` from `s.as_bytes().get(index)`
```rust
pub fn is_char_boundary2(s: &str, index: usize) -> bool {
if index == 0 {
return true;
}
match s.as_bytes().get(index) {
// For some reason, LLVM likes this comparison here more
None => index == s.len(),
// This is bit magic equivalent to: b < 128 || b >= 192
Some(&b) => (b as i8) >= -0x40,
}
}
```
This one has better codegen on every platform, except powerpc
<details><summary>x86 codegen</summary>
<p>
```nasm
example::is_char_boundary:
mov al, 1
test rdx, rdx
je .LBB0_5
cmp rsi, rdx
je .LBB0_5
cmp rsi, rdx
jbe .LBB0_3
cmp byte ptr [rdi + rdx], -65
setg al
.LBB0_5:
ret
.LBB0_3:
xor eax, eax
ret
example::is_char_boundary2:
test rdx, rdx
je .LBB1_1
cmp rsi, rdx
jbe .LBB1_4
cmp byte ptr [rdi + rdx], -65
setg al
ret
.LBB1_1: ; technically this branch is the same as LBB1_4
mov al, 1
ret
.LBB1_4:
sete al
ret
```
</p>
</details>
projects / rust.git / log