Commit Graph

141583 Commits

Author SHA1 Message Date
Yuki Okushi
0daec04d65
Rollup merge of #83756 - camelid:internal-rename-doc-spotlight, r=GuillaumeGomez
rustdoc: Rename internal uses of `spotlight`

I didn't make these renames in #80965 because I didn't want the PR to
conflict with #80914.
2021-04-04 00:19:36 +09:00
Yuki Okushi
3b40d2c1f3
Rollup merge of #82487 - CDirkx:const-socketaddr, r=m-ou-se
Constify methods of `std::net::SocketAddr`, `SocketAddrV4` and `SocketAddrV6`

The following methods are made unstable const under the `const_socketaddr` feature (https://github.com/rust-lang/rust/issues/82485):

```rust
// std::net

impl SocketAddr {
    pub const fn ip(&self) -> IpAddr;
    pub const fn port(&self) -> u16;
    pub const fn is_ipv4(&self) -> bool;
    pub const fn is_ipv6(&self) -> bool;
}

impl SocketAddrV4 {
    pub const fn ip(&self) -> IpAddr;
    pub const fn port(&self) -> u16;
}

impl SocketAddrV6 {
    pub const fn ip(&self) -> IpAddr;
    pub const fn port(&self) -> u16;
    pub const fn flowinfo(&self) -> u32;
    pub const fn scope_id(&self) -> u32;
}
```

Note: `SocketAddrV4::ip` and `SocketAddrV6::ip` use pointer casting and depend on the unstable feature `const_raw_ptr_deref`
2021-04-04 00:19:30 +09:00
Ben Mezger
7b05cffa18 Fix rustc_lint_defs documentation typo 2021-04-03 12:00:28 -03:00
bors
97717a5618 Auto merge of #83682 - bjorn3:mmap_wrapper, r=cjgillot
Add an Mmap wrapper to rustc_data_structures

This wrapper implements StableAddress and falls back to directly reading the file on wasm32.

Taken from #83640, which I will close due to the perf regression.
2021-04-03 13:23:42 +00:00
bjorn3
bda6d1f158 Add safety comment to StableAddress impl for Mmap 2021-04-03 14:51:05 +02:00
Wilco Kusee
3ea7c90a94 Add fixme comment to revert change once const_panic is stable 2021-04-03 13:07:03 +02:00
bors
640ce99bfe Auto merge of #83738 - jyn514:only-load-some-crates, r=petrochenkov
rustdoc: Don't load all extern crates unconditionally

Instead, only load the crates that are linked to with intra-doc links.

This doesn't help very much with any of rustdoc's fundamental issues
with freezing the resolver, but it at least fixes a stable-to-stable
regression, and makes the crate loading model somewhat more consistent
with rustc's. I tested and it unfortunately does not help at all with https://github.com/rust-lang/rust/pull/82496.

Closes https://github.com/rust-lang/rust/issues/68427. Let me know if you want me to open a separate issue for not freezing the resolver.
r? `@petrochenkov` cc `@eddyb` `@ollie27`
2021-04-03 10:59:24 +00:00
bors
ccd997592b Auto merge of #83549 - sjakobi:no-tidy-line-length-1, r=Mark-Simulacrum
tidy: Add ignore-rules for the line length check

This is step 1 towards fixing https://github.com/rust-lang/rust/issues/77548.

This PR contains the `tidy` change from https://github.com/rust-lang/rust/pull/77675. The "ignoring file length unnecessarily" check is temporarily disabled to simplify landing the ignore-rules. This check will be re-enabled in a follow-up PR.
2021-04-03 08:46:03 +00:00
Wilco Kusee
3cfa0a0dff Remove nightly features in rustc_type_ir 2021-04-03 10:00:09 +02:00
surechen
944b53eb75 add fp-armv8 for ARM_ALLOWED_FEATURES 2021-04-03 15:50:59 +08:00
Anthony Huang
c35a36f9b3 tidy: Add ignore-rules for the line length check
This is step 1 towards fixing #77548.

This commit includes the tidy change from #77675.
The "ignoring file length unnecessarily" check is temporarily
disabled to simplify landing the ignore-rules.
That check will be re-enabled in a follow-up PR.
2021-04-03 08:59:48 +02:00
bors
836c317426 Auto merge of #83774 - richkadel:zero-based-counters, r=tmandry
Translate counters from Rust 1-based to LLVM 0-based counter ids

A colleague contacted me and asked why Rust's counters start at 1, when
Clangs appear to start at 0. There is a reason why Rust's internal
counters start at 1 (see the docs), and I tried to keep them consistent
when codegenned to LLVM's coverage mapping format. LLVM should be
tolerant of missing counters, but as my colleague pointed out,
`llvm-cov` will silently fail to generate a coverage report for a
function based on LLVM's assumption that the counters are 0-based.

See:
https://github.com/llvm/llvm-project/blob/main/llvm/lib/ProfileData/Coverage/CoverageMapping.cpp#L170

Apparently, if, for example, a function has no branches, it would have
exactly 1 counter. `CounterValues.size()` would be 1, and (with the
1-based index), the counter ID would be 1. This would fail the check
and abort reporting coverage for the function.

It turns out that by correcting for this during coverage map generation,
by subtracting 1 from the Rust Counter ID (both when generating the
counter increment intrinsic call, and when adding counters to the map),
some uncovered functions (including in tests) now appear covered! This
corrects the coverage for a few tests!

r? `@tmandry`
FYI: `@wesleywiser`
2021-04-03 06:27:03 +00:00
bors
cb17136405 Auto merge of #83599 - jyn514:unorderable, r=Aaron1011
Avoid sorting by DefId for `necessary_variants()`

Follow-up to https://github.com/rust-lang/rust/pull/83074. Originally I tried removing `impl Ord for DefId` but that hit *lots* of errors 😅 so I thought I would start with easy things.

I am not sure whether this could actually cause invalid query results, but this is used from `MarkSymbolVisitor::visit_arm` so it's at least feasible.

r? `@Aaron1011`
2021-04-03 04:11:35 +00:00
bors
621d4b7cbf Auto merge of #83506 - asomers:backtrace-0.3.56, r=Mark-Simulacrum
Update backtrace to 0.3.56

Fixes #78184
2021-04-03 01:52:36 +00:00
Michael Howell
f64038f983 rustdoc: update macro highlight tests 2021-04-02 17:46:12 -07:00
Rich Kadel
7ceff6835a Translate counters from Rust 1-based to LLVM 0-based counter ids
A colleague contacted me and asked why Rust's counters start at 1, when
Clangs appear to start at 0. There is a reason why Rust's internal
counters start at 1 (see the docs), and I tried to keep them consistent
when codegenned to LLVM's coverage mapping format. LLVM should be
tolerant of missing counters, but as my colleague pointed out,
`llvm-cov` will silently fail to generate a coverage report for a
function based on LLVM's assumption that the counters are 0-based.

See:
https://github.com/llvm/llvm-project/blob/main/llvm/lib/ProfileData/Coverage/CoverageMapping.cpp#L170

Apparently, if, for example, a function has no branches, it would have
exactly 1 counter. `CounterValues.size()` would be 1, and (with the
1-based index), the counter ID would be 1. This would fail the check
and abort reporting coverage for the function.

It turns out that by correcting for this during coverage map generation,
by subtracting 1 from the Rust Counter ID (both when generating the
counter increment intrinsic call, and when adding counters to the map),
some uncovered functions (including in tests) now appear covered! This
corrects the coverage for a few tests!
2021-04-02 17:16:36 -07:00
bors
9b6c9b638e Auto merge of #81866 - nagisa:nagisa/sanitizer-support-target-prop, r=tmiasko
Maintain supported sanitizers as a target property

In an effort to remove a hard-coded allow-list for target-sanitizer support correspondence, this PR moves the configuration to the target options.

Perhaps the one notable change made in this PR is this doc-comment:

```rust
    /// The sanitizers supported by this target
    ///
    /// Note that the support here is at a codegen level. If the machine code with sanitizer
    /// enabled can generated on this target, but the necessary supporting libraries are not
    /// distributed with the target, the sanitizer should still appear in this list for the target.
```

Previously the target would typically be added to the allow-list at the same time as the supporting runtime libraries are shipped for the target. However whether we ship the runtime libraries or not needn't be baked into the compiler; and if we don't users will receive a significantly more directed error about library not being found.

Fixes #81802
2021-04-02 23:33:01 +00:00
Roxane
c29dc120e5 fix clippy error 2021-04-02 19:11:51 -04:00
Roxane
0a97eee8df Reduce size of statements 2021-04-02 19:11:50 -04:00
Roxane
2fb1fb7634 Fix diagnostic issue when using FakeReads in closures 2021-04-02 19:11:50 -04:00
Simonas Kazlauskas
41875c82c7 rm target specific logic in link_sanitizer_runtime 2021-04-03 00:37:49 +03:00
Simonas Kazlauskas
a3c0f0a3df (De-)serialize the supported_sanitizers 2021-04-03 00:37:49 +03:00
Simonas Kazlauskas
16c1d0ae06 Maintain supported sanitizers as a target property
This commit adds an additional target property – `supported_sanitizers`,
and replaces the hardcoded allowlists in argument parsing to use this
new property.

Fixes #81802
2021-04-03 00:37:49 +03:00
Simonas Kazlauskas
64af7eae1e Move SanitizerSet to rustc_target 2021-04-03 00:37:49 +03:00
Simonas Kazlauskas
2f000a78bf Manually set dso_local when its valid to do so
This should have no real effect in most cases, as e.g. `hidden`
visibility already implies `dso_local` (or at least LLVM IR does not
preserve the `dso_local` setting if the item is already `hidden`), but
it should fix `-Crelocation-model=static` and improve codegen in
executables.

Note that this PR does not exhaustively port the logic in [clang]. Only
the obviously correct portion and what is necessary to fix a regression
from LLVM 12 that relates to `-Crelocation_model=static`.

Fixes #83335

[clang]: 3001d080c8/clang/lib/CodeGen/CodeGenModule.cpp (L945-L1039)
2021-04-03 00:00:29 +03:00
Joshua Nelson
e4244e3710 Don't load all extern crates unconditionally
Instead, only load the crates that are linked to with intra-doc links.

This doesn't help very much with any of rustdoc's fundamental issues
with freezing the resolver, but it at least fixes a stable-to-stable
regression, and makes the crate loading model somewhat more consistent
with rustc's.
2021-04-02 16:34:53 -04:00
Michael Howell
617e13548f rustdoc: highlight macros more efficiently
Instead of producing `<span class=macro>assert_eq</span><span class=macro>!</span>`,
just produce `<span class=macro>assert_eq!</span>`.
2021-04-02 13:12:00 -07:00
bors
138fd56cf9 Auto merge of #83790 - Dylan-DPC:rollup-p6ep8jo, r=Dylan-DPC
Rollup of 7 pull requests

Successful merges:

 - #83065 (Rework `std::sys::windows::alloc`)
 - #83478 (rustdoc: Add unstable option to only emit shared/crate-specific files)
 - #83629 (Fix double-drop in `Vec::from_iter(vec.into_iter())` specialization when items drop during panic)
 - #83673 (give full path of constraint in suggest_constraining_type_param)
 - #83755 (Simplify coverage tests)
 - #83757 (2229: Support migration via rustfix)
 - #83771 (Fix stack overflow detection on FreeBSD 11.1+)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2021-04-02 20:06:11 +00:00
Camelid
1fe0fe47fc rustdoc: Remove unused spotlight CSS
I couldn't find any uses of this CSS. I think it was superseded by the
`.notable-traits` CSS class and other similarly-named CSS classes.
2021-04-02 11:38:06 -07:00
Camelid
5f96c48de2 rustdoc: Rename internal uses of spotlight
I didn't make these renames in #80965 because I didn't want the PR to
conflict with #80914.
2021-04-02 11:38:02 -07:00
Dylan DPC
cb7133f693
Rollup merge of #83771 - asomers:stack_overflow_freebsd, r=dtolnay
Fix stack overflow detection on FreeBSD 11.1+

Beginning with FreeBSD 10.4 and 11.1, there is one guard page by
default.  And the stack autoresizes, so if Rust allocates its own guard
page, then FreeBSD's will simply move up one page.  The best solution is
to just use the OS's guard page.
2021-04-02 19:57:35 +02:00
Dylan DPC
eed73c6e4d
Rollup merge of #83757 - sexxi-goose:migrations_out, r=nikomatsakis
2229: Support migration via rustfix

- Adds support of machine applicable suggestions for `disjoint_capture_drop_reorder`.
- Doesn't migrate in the case of pre-existing bugs in user code

r? ``@nikomatsakis``
2021-04-02 19:57:34 +02:00
Dylan DPC
70091171bd
Rollup merge of #83755 - richkadel:cov-test-simplify, r=tmandry
Simplify coverage tests

This change reduces the risk of impacting coverage tests on unrelated
changes (such as MIR and Span changes), and reduces the burden when
blessing coverage changes in case it is necessary.

* Remove all spanview tests. The spanview tests were useful during
  development, but they can be generated as needed, via compiler command
  line flags. They aren't critical to confirming coverage results. (The
  coverage report tests are sufficient.)

  When spanview regeneration was necessary, the diffs were way too hard
  to read to be useful anyway. So I'm removing them to reduce friction
  from a feature that is no longer useful.

* Remove the requirement for `llvm-cov show --debug` when blessing
  tests. The `--debug` flag is, unfortunately, only available if LLVM is
  built with `optimize = false` (in Rust's config.toml). This adds
  significant time and resource burdens to the contributor's build. As
  it turns out, for other reasons in the past, I wasn't actually using
  the debug output (counter info) to validate coverage anymore either,
  so it was required for no reason, I now realize.
2021-04-02 19:57:33 +02:00
Dylan DPC
6cb74ad99f
Rollup merge of #83673 - hi-rustin:rustin-patch-suggestion, r=estebank
give full path of constraint in suggest_constraining_type_param

close https://github.com/rust-lang/rust/issues/83513
2021-04-02 19:57:32 +02:00
Dylan DPC
542f441d44
Rollup merge of #83629 - the8472:fix-inplace-panic-on-drop, r=m-ou-se
Fix double-drop in `Vec::from_iter(vec.into_iter())` specialization when items drop during panic

This fixes the double-drop but it leaves a behavioral difference compared to the default implementation intact: In the default implementation the source and the destination vec are separate objects, so they get dropped separately. Here they share an allocation and the latter only exists as a pointer into the former. So if dropping the former panics then this fix will leak more items than the default implementation would. Is this acceptable or should the specialization also mimic the default implementation's drops-during-panic behavior?

Fixes #83618

`@rustbot` label T-libs-impl
2021-04-02 19:57:31 +02:00
Dylan DPC
31f532092c
Rollup merge of #83478 - jyn514:fine-grained-files, r=Mark-Simulacrum
rustdoc: Add unstable option to only emit shared/crate-specific files

The intended use case is for docs.rs, which can now copy exactly the
files it cares about, rather than having to guess based on whether they
have a resource suffix or not. In particular, some files have a resource
suffix but cannot be shared between crates: https://github.com/rust-lang/docs.rs/pull/1312#issuecomment-798783688

The end goal is to fix rust-lang/docs.rs#1327 by reverting rust-lang/docs.rs#1324.

This obsoletes `--print=unversioned-files`, which I plan to remove as
soon as docs.rs stops using it.

I recommend reviewing this one commit at a time.

r? ``@GuillaumeGomez`` cc ``@Nemo157`` ``@pietroalbini``
2021-04-02 19:57:30 +02:00
Dylan DPC
48ebad58b2
Rollup merge of #83065 - CDirkx:win-alloc, r=dtolnay
Rework `std::sys::windows::alloc`

I came across https://github.com/rust-lang/rust/pull/76676#discussion_r488729990, which points out that there was unsound code in the Windows alloc code, creating a &mut to possibly uninitialized memory. I reworked the code so that that particular issue does not occur anymore, and started adding more documentation and safety comments.

Full list of changes:
 - moved and documented the relevant Windows Heap API functions
 - refactor `allocate_with_flags` to `allocate` (and remove the other helper functions), which now takes just a `bool` if the memory should be zeroed
 - add checks for if `GetProcessHeap` returned null
 - add a test that checks if the size and alignment of a `Header` are indeed <= `MIN_ALIGN`
 - add `#![deny(unsafe_op_in_unsafe_fn)]` and the necessary unsafe blocks with safety comments

I feel like I may have overdone the documenting, the unsoundness fix is the most important part; I could spit this PR up in separate parts.
2021-04-02 19:57:28 +02:00
LeSeulArtichaut
fb7cf0982b Don't suggest dereferencing an else if expression 2021-04-02 19:50:06 +02:00
bors
23fa536050 Auto merge of #76881 - hameerabbasi:issue-53325, r=oli-obk
Add allocation information to undefined behaviour errors.

So far I'm looking on information on whether the error messages are suitable.

Fixes #53325.
2021-04-02 17:38:57 +00:00
Mario Carneiro
99f3e889b1
fix 2021-04-02 10:21:23 -07:00
Mario Carneiro
e01c3b8211
clarify wording 2021-04-02 09:55:23 -07:00
Mario Carneiro
3166e0857d
Monomorphization doc fix
Only public items are monomorphization roots. This can be confirmed by noting that this program compiles:
```rust
fn foo<T>() { if true { foo::<Option<T>>() } }
fn bar() { foo::<()>() }
```
2021-04-02 09:33:34 -07:00
Christiaan Dirkx
db1d003de1 Remove debug_assert 2021-04-02 17:50:23 +02:00
Christiaan Dirkx
c86e0985f9 Introduce get_process_heap and fix atomic ordering. 2021-04-02 17:37:52 +02:00
bors
36bcf40697 Auto merge of #83468 - hi-rustin:rustin-patch-lint, r=nikomatsakis
add OR_PATTERNS_BACK_COMPAT lint

close https://github.com/rust-lang/rust/issues/83318
2021-04-02 15:14:48 +00:00
bors
a207871d5c Auto merge of #83781 - JohnTitor:rollup-1vm3dxo, r=JohnTitor
Rollup of 5 pull requests

Successful merges:

 - #83535 (Break when there is a mismatch in the type count)
 - #83721 (Add a button to copy the "use statement")
 - #83740 (Fix comment typo in once.rs)
 - #83745 (Add my new email address to .mailmap)
 - #83754 (Add test to ensure search tabs behaviour)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2021-04-02 12:51:41 +00:00
Yuki Okushi
1dfbca9266
Rollup merge of #83754 - GuillaumeGomez:search-tab-behaviour, r=jyn514
Add test to ensure search tabs behaviour

It adds a GUI test for https://github.com/rust-lang/rust/pull/80382.

r? ```@jyn514```
2021-04-02 21:28:25 +09:00
Yuki Okushi
39059fb429
Rollup merge of #83745 - JohnTitor:jtitor-mailmap, r=Mark-Simulacrum
Add my new email address to .mailmap
2021-04-02 21:28:24 +09:00
Yuki Okushi
417e6b1dd0
Rollup merge of #83740 - obi1kenobi:patch-1, r=joshtriplett
Fix comment typo in once.rs

I believe I came across a minor typo in a comment. I am not particularly familiar with this part of the codebase, but I have read the surrounding code as well as the referenced `park` and `unpark` functions, and I believe my proposed change is true to the intended meaning of the comment.

I intentionally tried to keep the change as minimal as possible. If I have the maintainers' permission, I'd also love to add a comma to improve readability as follows: `Luckily ``park`` comes with the guarantee that if it got an ``unpark`` just before on an unparked thread, it does not park.`
2021-04-02 21:28:23 +09:00
Yuki Okushi
080aa37629
Rollup merge of #83721 - GuillaumeGomez:copy-use, r=Nemo157
Add a button to copy the "use statement"

Fixes https://github.com/rust-lang/rust/issues/50239

When clicking on the button, it'll add the elements prepended by "use " and will end with a ";". So in the images below, I now have in my clipboard `use std::fs::OpenOptions;`.

A screenshot of the newly added button:

![Screenshot from 2021-03-31 22-12-12](https://user-images.githubusercontent.com/3050060/113205430-90e64500-926e-11eb-8538-529829f611ec.png)

A screenshot after it was clicked:

![Screenshot from 2021-03-31 22-15-31](https://user-images.githubusercontent.com/3050060/113205532-ad827d00-926e-11eb-893d-35f2f8f92696.png)

r? `@Nemo157`
2021-04-02 21:28:21 +09:00