Noah Lev [Fri, 29 Oct 2021 03:48:48 +0000 (20:48 -0700)]
rustdoc: Remove `Crate.src` and instead compute it on-demand
It is only used in one place; `src` was about a third of `Crate`'s total
size; `Crate` is frequently moved by-value; and `src` can be easily
computed on-demand.
bors [Fri, 29 Oct 2021 15:31:37 +0000 (15:31 +0000)]
Auto merge of #90389 - camelid:rustdoc-rayon, r=jyn514
rustdoc: Switch to mainline rayon
The rustc fork of rayon integrates with Cargo's jobserver to limit the
amount of parallelism. However, rustdoc's use case is concurrent I/O,
which is not CPU-heavy, so it should be able to use mainline rayon.
bors [Fri, 29 Oct 2021 12:21:09 +0000 (12:21 +0000)]
Auto merge of #90373 - tmiasko:union-qualification, r=oli-obk
Use type based qualification for unions
Union field access is currently qualified based on the qualification of
a value previously assigned to the union. At the same time, every union
access transmutes the content of the union, which might result in a
different qualification.
For example, consider constants A and B as defined below, under the
current rules neither contains interior mutability, since a value used
in the initial assignment did not contain `UnsafeCell` constructor.
```rust
#![feature(untagged_unions)]
union U { i: u32, c: std::cell::Cell<u32> }
const A: U = U { i: 0 };
const B: std::cell::Cell<u32> = unsafe { U { i: 0 }.c };
```
To avoid the issue, the changes here propose to consider the content of
a union as opaque and use type based qualification for union types.
bors [Fri, 29 Oct 2021 08:38:39 +0000 (08:38 +0000)]
Auto merge of #90214 - tmiasko:indirect-mutation-qualif, r=ecstatic-morse,oli-obk
Consider indirect mutation during const qualification dataflow
Previously a local would be qualified if either one of two separate data
flow computations indicated so. First determined if a local could
contain the qualif, but ignored any forms of indirect mutation. Second
determined if a local could be mutably borrowed (and so indirectly
mutated), but which in turn ignored the qualif.
The end result was incorrect because the effect of indirect mutation was
effectivelly ignored in the all but the final stage of computation.
In the new implementation the indirect mutation is directly incorporated
into the qualif data flow. The local variable becomes immediately
qualified once it is mutably borrowed and borrowed place type can
contain the qualif.
In general we will now reject additional programs, program that were
prevously unintentionally accepted.
There are also some cases which are now accepted but were previously
rejected, because previous implementation didn't consider whether
borrowed place could have the qualif under the consideration.
bors [Fri, 29 Oct 2021 01:50:08 +0000 (01:50 +0000)]
Auto merge of #90363 - camelid:build-impl-perf, r=jyn514
Improve perf measurements of `build_extern_trait_impl`
Before, it was only measuring one callsite of `build_impl`, and it
incremented the call count even if `build_impl` returned early because
the `did` was already inlined.
Now, it measures all calls, minus calls that return early.
Noah Lev [Fri, 29 Oct 2021 01:19:01 +0000 (18:19 -0700)]
rustdoc: Switch to mainline rayon
The rustc fork of rayon integrates with Cargo's jobserver to limit the
amount of parallelism. However, rustdoc's use case is concurrent I/O,
which is not CPU-heavy, so it should be able to use mainline rayon.
bors [Thu, 28 Oct 2021 19:34:01 +0000 (19:34 +0000)]
Auto merge of #90281 - xldenis:public-borrow-set, r=nikomatsakis
Add BorrowSet to public api
This PR adds `BorrowSet` to the public api so that verification tools can obtain the activation and reservation points of two phase borrows without having to redo calculations themselves (and thus potentially differently from rustc).
Turns out we already can obtain `MoveData` thanks to the public `HasMoveData` trait, so constructing a `BorrowSet` should not provide much of an issue. However, I can't speak to the soundness of this approach, is it safe to take an under-approximation of `MoveData`?
bors [Thu, 28 Oct 2021 16:03:13 +0000 (16:03 +0000)]
Auto merge of #90218 - JakobDegen:adt_significant_drop_fix, r=nikomatsakis
Fixes incorrect handling of ADT's drop requirements
Fixes #90024 and a bunch of duplicates.
The main issue was just that the contract of `NeedsDropTypes::adt_components` was inconsistent; the list of types it might return were the generic parameters themselves or the fields of the ADT, depending on the nature of the drop impl. This meant that the caller could not determine whether a `.subst()` call was still needed on those types; it called `.subst()` in all cases, and this led to ICEs when the returned types were the generic params.
First contribution of more than a few lines, so feedback definitely appreciated.
Noah Lev [Thu, 28 Oct 2021 03:06:48 +0000 (20:06 -0700)]
Improve perf measurements of `build_extern_trait_impl`
Before, it was only measuring one callsite of `build_impl`, and it
incremented the call count even if `build_impl` returned early because
the `did` was already inlined.
Now, it measures all calls, minus calls that return early.
Tomasz Miąsko [Thu, 28 Oct 2021 00:00:00 +0000 (00:00 +0000)]
Use type based qualification for unions
Union field access is currently qualified based on the qualification of
a value previously assigned to the union. At the same time, every union
access transmutes the content of the union, which might result in a
different qualification.
For example, consider constants A and B as defined below, under the
current rules neither contains interior mutability, since a value used
in the initial assignment did not contain `UnsafeCell` constructor.
```rust
#![feature(untagged_unions)]
union U { i: u32, c: std::cell::Cell<u32> }
const A: U = U { i: 0 };
const B: std::cell::Cell<u32> = unsafe { U { i: 0 }.c };
```
To avoid the issue, the changes here propose to consider the content of
a union as opaque and use type based qualification for union types.
bors [Wed, 27 Oct 2021 18:42:13 +0000 (18:42 +0000)]
Auto merge of #90347 - matthiaskrgr:rollup-rp2ms7j, r=matthiaskrgr
Rollup of 5 pull requests
Successful merges:
- #90239 (Consistent big O notation in map.rs)
- #90267 (fix: inner attribute followed by outer attribute causing ICE)
- #90288 (Add hint for people missing `TryFrom`, `TryInto`, `FromIterator` import pre-2021)
- #90304 (Add regression test for #75961)
- #90344 (Add tracking issue number to const_cstr_unchecked)
Matthias Krüger [Wed, 27 Oct 2021 16:25:47 +0000 (18:25 +0200)]
Rollup merge of #90344 - xfix:tracking-issue-const_cstr_unchecked, r=Mark-Simulacrum
Add tracking issue number to const_cstr_unchecked
Also created a tracking issue, see #90343.
I think it makes sense to stabilize this somewhat soon considering abuse of `transmute` to have this feature in constants, see https://crates.io/crates/cstr for an example. Code can be rewritten to use `mem::transmute` to work on stable.
Matthias Krüger [Wed, 27 Oct 2021 16:25:44 +0000 (18:25 +0200)]
Rollup merge of #90267 - EliseZeroTwo:elisezerotwo/fix_invalid_attrs_ice, r=Aaron1011
fix: inner attribute followed by outer attribute causing ICE
Fixes #87936, #88938, and #89971.
This removes the assertion that validates that there are no outer attributes following inner attributes. Where the inner attribute is invalid you get an actual error.
bors [Wed, 27 Oct 2021 12:27:47 +0000 (12:27 +0000)]
Auto merge of #90186 - jsha:fix-header-sizes, r=GuillaumeGomez
Fix documentation header sizes
And add a rustdoc-gui test confirming various header sizes.
Split off from #90156. This fixes a regression in #89506 where the heading level of titles within Markdown was too high (h2) for docblocks under structs, unions, and enum impls.
bors [Wed, 27 Oct 2021 09:19:42 +0000 (09:19 +0000)]
Auto merge of #89652 - rcvalle:rust-cfi, r=nagisa
Add LLVM CFI support to the Rust compiler
This PR adds LLVM Control Flow Integrity (CFI) support to the Rust compiler. It initially provides forward-edge control flow protection for Rust-compiled code only by aggregating function pointers in groups identified by their number of arguments.
Forward-edge control flow protection for C or C++ and Rust -compiled code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code share the same virtual address space) will be provided in later work as part of this project by defining and using compatible type identifiers (see Type metadata in the design document in the tracking issue #89653).
LLVM CFI can be enabled with -Zsanitizer=cfi and requires LTO (i.e., -Clto).
bors [Wed, 27 Oct 2021 06:16:47 +0000 (06:16 +0000)]
Auto merge of #90337 - matthiaskrgr:rollup-azkr158, r=matthiaskrgr
Rollup of 3 pull requests
Successful merges:
- #90154 (rustdoc: Remove `GetDefId`)
- #90232 (rustdoc: Use TTF based font instead of OTF for CJK glyphs to improve readability)
- #90278 (rustdoc: use better highlighting for *const, *mut, and &mut)
Matthias Krüger [Wed, 27 Oct 2021 04:11:36 +0000 (06:11 +0200)]
Rollup merge of #90232 - konan8205:master, r=GuillaumeGomez
rustdoc: Use TTF based font instead of OTF for CJK glyphs to improve readability
Due to Windows' implementation of font rendering, OpenType fonts can be distorted. So the existing font, Noto Sans KR, is not very readable on Windows. This PR improves readability of Korean glyphs on Windows.
bors [Wed, 27 Oct 2021 03:08:47 +0000 (03:08 +0000)]
Auto merge of #89937 - JohnTitor:fix-89875, r=Amanieu
Properly check `target_features` not to trigger an assertion
Fixes #89875
I think it should be a condition instead of an assertion to check if it's a register as it's possible that `reg` is a register class.
Also, this isn't related to the issue directly, but `is_target_supported` doesn't check `target_features` attributes. Is there any way to check it on rustc_codegen_llvm?
Matthias Krüger [Tue, 26 Oct 2021 17:32:44 +0000 (19:32 +0200)]
Rollup merge of #90296 - CAD97:rip-lerp, r=Mark-Simulacrum
Remove fNN::lerp
Lerp is [surprisingly complex with multiple tradeoffs depending on what guarantees you want to provide](https://github.com/rust-lang/rust/issues/86269#issuecomment-869108301) (and what you're willing to drop for raw speed), so we don't have consensus on what implementation to use, let alone what signature - `t.lerp(a, b)` nicely puts `a, b` together, but makes dispatch to lerp custom types with the same signature basically impossible, and major ecosystem crates (e.g. nalgebra, glium) use `a.lerp(b, t)`, which is easily confusable. It was suggested to maybe provide a `Lerp<T>` trait and `t.lerp([a, b])`, which _could_ be implemented by downstream math libraries for their types, but also significantly raises the bar from a simple fNN method to a full trait, and does nothing to solve the implementation question. (It also raises the question of whether we'd support higher-order bezier interpolation.)
The only consensus we have is the lack of consensus, and the [general temperature](https://github.com/rust-lang/rust/issues/86269#issuecomment-951347135) is that we should just remove this method (giving the method space back to 3rd party libs) and revisit this if (and likely only if) IEEE adds lerp to their specification.
If people want a lerp, they're _probably_ already using (or writing) a math support library, which provides a lerp function for its custom math types and can provide the same lerp implementation for the primitive types via an extension trait.
See also [previous Zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/lerp.20API.20design)
cc ``@clarfonthey`` (original PR author), ``@m-ou-se`` (original r+), ``@scottmcm`` (last voice in tracking issue, prompted me to post this)
bors [Tue, 26 Oct 2021 11:45:13 +0000 (11:45 +0000)]
Auto merge of #90284 - tonyyzy:patch-1, r=JohnTitor
Remove redundant Aligner
The `Aligner` struct seems to be unnecessary.
Previously noted by `@arthurprs` https://github.com/rust-lang/rust/pull/44963#discussion_r145340754
Reddit discussion: https://www.reddit.com/r/rust/comments/pfvvz2/aligner_and_cachealigned/
Playground: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=fa7ca554922755f9d1b62b017d785c6f
Tony Yang [Tue, 26 Oct 2021 10:34:03 +0000 (11:34 +0100)]
Remove redundant Aligner
The `Aligner` struct seems to be unnecessary.
Previously noted by @arthurprs https://github.com/rust-lang/rust/pull/44963#discussion_r145340754
Reddit discussion: https://www.reddit.com/r/rust/comments/pfvvz2/aligner_and_cachealigned/
Playground: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=fa7ca554922755f9d1b62b017d785c6f
Tomasz Miąsko [Sat, 23 Oct 2021 00:00:00 +0000 (00:00 +0000)]
Consider indirect mutation during const qualification dataflow
Previously a local would be qualified if either one of two separate data
flow computations indicated so. First determined if a local could
contain the qualif, but ignored any forms of indirect mutation. Second
determined if a local could be mutably borrowed (and so indirectly
mutated), but which in turn ignored the qualif.
The end result was incorrect because the effect of indirect mutation was
effectivelly ignored in the all but the final stage of computation.
In the new implementation the indirect mutation is directly incorporated
into the qualif data flow. The local variable becomes immediately
qualified once it is mutably borrowed and borrowed place type can
contain the qualif.
In general we will now reject additional programs, program that were
prevously unintentionally accepted.
There are also some cases which are now accepted but were previously
rejected, because previous implementation didn't consider whether
borrowed place could have the qualif under the consideration.
bors [Tue, 26 Oct 2021 04:44:51 +0000 (04:44 +0000)]
Auto merge of #90299 - matthiaskrgr:rollup-n77ntld, r=matthiaskrgr
Rollup of 4 pull requests
Successful merges:
- #90181 (fix(rustc_typeck): report function argument errors on matching type)
- #90241 (Make thiscall abi on unsupported platforms a hard error)
- #90294 (Update books)
- #90295 (Update cargo)
Matthias Krüger [Tue, 26 Oct 2021 04:14:08 +0000 (06:14 +0200)]
Rollup merge of #90294 - ehuss:update-books, r=ehuss
Update books
## nomicon
3 commits in 2d66852a27c5d0ec50ae021820d1de22caa2b1bd..358e6a61d5f4f0496d0a81e70cdcd25d05307342
2021-10-07 19:00:37 +0900 to 2021-10-20 11:23:12 -0700
- Write a basic "call Rust from C" example (rust-lang/nomicon#296)
- Clarify the Safe vs. Unsafe Rust relationship (rust-lang/nomicon#294)
- Fix typo with respect to dangling pointer (rust-lang/nomicon#319)
## book
8 commits in eb1282ec444db94055fa9531b6f3f803e86bb382..fd9299792852c9a368cb236748781852f75cdac6
2021-09-16 21:17:09 -0400 to 2021-10-22 21:59:46 -0400
- Reword description to emphasize what return does in a match arm
- Correct backwards wording describing From impls. Fixes rust-lang/book#2829
- Remove multiple negatives, add examples. Fixes rust-lang/book#2833
- Fix capitalization in sidebar. Fixes rust-lang/book#2860
- fix quotes
- comments from nostarch and responses for chapter 2
- (rust-lang/book#2906)
- Merge pull request rust-lang/book#2892 from Enrico2/patch-1
Matthias Krüger [Tue, 26 Oct 2021 04:14:07 +0000 (06:14 +0200)]
Rollup merge of #90241 - DrMeepster:thiscall_lint_upgrade, r=petrochenkov
Make thiscall abi on unsupported platforms a hard error
As suggested in https://github.com/rust-lang/rust/issues/42202#issuecomment-950205016, this PR makes use of the `thiscall` abi on unsupported a hard error instead of a lint.
This commit adds LLVM Control Flow Integrity (CFI) support to the Rust
compiler. It initially provides forward-edge control flow protection for
Rust-compiled code only by aggregating function pointers in groups
identified by their number of arguments.
Forward-edge control flow protection for C or C++ and Rust -compiled
code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code
share the same virtual address space) will be provided in later work as
part of this project by defining and using compatible type identifiers
(see Type metadata in the design document in the tracking issue #89653).
LLVM CFI can be enabled with -Zsanitizer=cfi and requires LTO (i.e.,
-Clto).
The changes introduced in https://github.com/rust-lang/rust/pull/87280 allowed for "duplicate" caller bounds candidates to be assembled that only differed in their default substs having been "exposed" or not and resulted in an ambiguity error during trait selection. To fix this we expose the defaults substs during the creation of the ParamEnv.
Matthias Krüger [Mon, 25 Oct 2021 20:59:47 +0000 (22:59 +0200)]
Rollup merge of #90196 - yanok:master, r=scottmcm
Fix and extent ControlFlow `traverse_inorder` example
Fix and extent ControlFlow `traverse_inorder` example
1. The existing example compiles on its own, but any usage fails to be monomorphised and so doesn't compile. Fix that by using Fn trait instead of FnMut.
2. Added an example usage of `traverse_inorder` showing how we can terminate the traversal early.
Matthias Krüger [Mon, 25 Oct 2021 20:59:46 +0000 (22:59 +0200)]
Rollup merge of #89581 - jblazquez:master, r=Mark-Simulacrum
Add -Z no-unique-section-names to reduce ELF header bloat.
This change adds a new compiler flag that can help reduce the size of ELF binaries that contain many functions.
By default, when enabling function sections (which is the default for most targets), the LLVM backend will generate different section names for each function. For example, a function `func` would generate a section called `.text.func`. Normally this is fine because the linker will merge all those sections into a single one in the binary. However, starting with [LLVM 12](https://github.com/llvm/llvm-project/commit/ee5d1a04), the backend will also generate unique section names for exception handling, resulting in thousands of `.gcc_except_table.*` sections ending up in the final binary because some linkers like LLD don't currently merge or strip these EH sections (see discussion [here](https://reviews.llvm.org/D83655)). This can bloat the ELF headers and string table significantly in binaries that contain many functions.
The new option is analogous to Clang's `-fno-unique-section-names`, and instructs LLVM to generate the same `.text` and `.gcc_except_table` section for each function, resulting in a smaller final binary.
The motivation to add this new option was because we have a binary that ended up with so many ELF sections (over 65,000) that it broke some existing ELF tools, which couldn't handle so many sections.
Here's our old binary:
```
$ readelf --sections old.elf | head -1
There are 71746 section headers, starting at offset 0x2a246508: