Rollup merge of #86933 - GuillaumeGomez:cleanup-rustdoc-static-files, r=Manishearth
Clean up rustdoc static files
The `html/static` of rustdoc was starting to be quite a mess... So I moved files in sub-folders to make it easier to follow. Here what remains in `html/static` folder:
Rollup merge of #86932 - rylev:fix-ice-86895, r=estebank
Fix ICE when misplaced visibility cannot be properly parsed
Fixes #86895
The issue was that a failure to parse the visibility was causing the original error to be dropped before being emitted.
The resulting error isn't quite as nice as when the visibility is parsed properly, but I'm not sure which error to prioritize here. Displaying both errors might be too confusing.
Rollup merge of #86927 - bjorn3:sync_cg_clif-2021-07-07, r=bjorn3
Sync rustc_codegen_cranelift
The main hightlight this sync is basic support for AArch64. Most things should work on Linux, but there does seem to be an ABI incompatibility causing proc-macros to crash, see https://github.com/bjorn3/rustc_codegen_cranelift/issues/1184. Thanks to ```@afonso360``` for implementing all Cranelift features that were necessary to compile for AArch64 using cg_clif. Also thanks to ```@shamatar``` for implementing the `llvm.x86.addcarry.64` and `llvm.x86.subborrow.64` llvm intrinsics used by num-bigint (https://github.com/bjorn3/rustc_codegen_cranelift/pull/1178) and ```@eggyal``` for implementing multi-threading support for the lazy jit mode. (https://github.com/bjorn3/rustc_codegen_cranelift/pull/1166)
Rollup merge of #86812 - FabianWolff:recover-dyn-mut, r=petrochenkov
Recover from `&dyn mut ...` parse errors
Consider this example:
```rust
fn main() {
let r: &dyn mut Trait;
}
```
This currently leads to:
```
error: expected one of `!`, `(`, `;`, `=`, `?`, `for`, lifetime, or path, found keyword `mut`
--> src/main.rs:2:17
|
2 | let r: &dyn mut Trait;
| ^^^ expected one of 8 possible tokens
error: aborting due to previous error
```
However, especially for beginners, I think it is easy to get `&dyn mut` and `&mut dyn` confused. With my changes, I get a help message, and the parser even recovers:
```
error: `mut` must precede `dyn`
--> test.rs:2:12
|
2 | let r: &dyn mut Trait;
| ^^^^^^^^ help: place `mut` before `dyn`: `&mut dyn`
error[E0405]: cannot find trait `Trait` in this scope
--> test.rs:2:21
|
2 | let r: &dyn mut Trait;
| ^^^^^ not found in this scope
Rollup merge of #86639 - eholk:lint-tool, r=petrochenkov
Support lint tool names in rustc command line options
When rustc is running without a lint tool such as clippy enabled, options for lints such as `clippy::foo` are meant to be ignored. This was already working for those specified by attrs, such as `#![allow(clippy::foo)]`, but this did not work for command line arguments like `-A clippy::foo`. This PR fixes that issue.
Note that we discovered this issue while discussing https://github.com/rust-lang/cargo/issues/5034.
Rollup merge of #86919 - ehuss:update-books, r=ehuss
Update books
## nomicon
8 commits in b9ca313e687c991223e23e5520529815dc281205..7a13537f96af4b9b8e3ea296d6e5c3c7ab72ce9f
2021-06-22 12:02:20 -0400 to 2021-07-05 23:34:47 -0400
- Apply review comments
- Fix some style issues
- Move the list of coercions to the reference
- Add an example that shows the null-pointer opt does not happen
- Remove casting list from the nomicon (rust-lang-nursery/nomicon#287)
- Audit `ignore` annotations (rust-lang-nursery/nomicon#288)
- rename typo "lifetime" to "reference" (rust-lang-nursery/nomicon#286)
- Add an incomplete warning to the top page (rust-lang-nursery/nomicon#274)
## reference
7 commits in d9699fa8f3186440fdaadd703d63d8d42322c176..ab60513a3a5a0591e237fddff5d027a982648392
2021-06-21 12:23:10 -0700 to 2021-07-05 08:27:31 -0700
- fix grammar in Expressions (rust-lang-nursery/reference#1057)
- fix comment in function parameter drop scope example (rust-lang-nursery/reference#1056)
- fix typo in macro-ambiguity.md (rust-lang-nursery/reference#1058)
- Mention (negative) infinity values on float-to-int casting (rust-lang-nursery/reference#1054)
- (rust-lang-nursery/reference#841)
- Missing TypeParamBounds in TypeAlias (rust-lang-nursery/reference#1036)
- Be more precise about array offset in type layouts (rust-lang-nursery/reference#1034)
## book
34 commits in 55a26488ddefc8433e73a2e8352d70f7a5c7fc2b..a90f07f1e9a7fc75dc9105a6c6f16d5c13edceb0
2021-05-09 12:03:18 -0500 to 2021-07-05 14:43:12 -0400
- Clarify ?Sized syntax. Fixes rust-lang/book#2422.
- Add some notes that macros are different than functions
- Break up a long sentence. Fixes rust-lang/book#2329.
- Further clarify and make consistent the reference to deref coercion
- Update ch04-03-slices.md
- add usage for `String` reference
- Update ch15-02-deref.md (rust-lang/book#2780)
- Remove claim about performance of i32
- Reword to avoid awkward pluralization
- Make the link to the reference relative
- Merge remote-tracking branch 'origin/pr/2753'
- Reword number of library crates a package contains (rust-lang/book#2750)
- Clarify explanation of why you can test private functions; add link
- Merge remote-tracking branch 'origin/pr/2743'
- Fix code hiding that I broke in eb60fedc9
- Link to the exact later section we're talking about
- improve cross-references for newtype pattern
- ch12-05, listing 12-20: Add missing "does not compile" warning (rust-lang/book#2731)
- cargo format
- Merge remote-tracking branch 'origin/pr/2724'
- Remove ordinal numbers and only refer to indexes to avoid confusion
- Let's mention the former and current authors of tlborm.
- Update tlborm link to point to Veykril's up-to-date version (rust-lang/book#2722)
- Merge remote-tracking branch 'origin/pr/2720'
- Describe the ferris pictures in the alt text
- Merge remote-tracking branch 'origin/pr/2707'
- Reword ... explanation to include the word deprecated, list that first
- Precise that the `...` inclusive range pattern has been replaces (rust-lang/book#2714)
- (rust-lang/book#2696)
- fix typo: missing "type" after generic (rust-lang/book#2777)
- (rust-lang/book#2709)
- Remove sentence about how Rust used to be
- Fix a potentially confusing statement about static lifetimes of static variables. (rust-lang/book#2692)
- Replace 'which'. (rust-lang/book#2663)
13 commits in fe34beddb41dea5cb891032512a8d5b842b99696..60e282559104035985331645907c3d9f842312c5
2021-06-21 21:50:12 +0200 to 2021-07-05 11:21:03 -0400
- Fixed typos in inline code
- Document lang items (rust-lang/rustc-dev-guide#1119)
- More specifics on what future-incompatible lints are used for
- Fix line lens
- Update information on lints particularly on future-incompatible
- Update section of lint store
- Update around half of the January 2021 date references (rust-lang/rustc-dev-guide#1155)
- Create issues for many TODOs (rust-lang/rustc-dev-guide#1163)
- Links from rustc-dev-guide to std-dev-guide (rust-lang/rustc-dev-guide#1152)
- Document how to mark features as incomplete (rust-lang/rustc-dev-guide#1151)
- Remove requests or suggestions about rebase and fixup contradictory to rust-highfive bot comment (rust-lang/rustc-dev-guide#1111)
- Generate glossary table correctly (rust-lang/rustc-dev-guide#1146)
- Correct the wrong serial number (rust-lang/rustc-dev-guide#1147)
## edition-guide
3 commits in c74b2a0d6bf55774cf15d69f05dfe05408b8f81a..5d57b3832f8d308a9f478ce0a69799548f27ad4d
2021-06-14 10:48:27 -0700 to 2021-07-05 10:33:32 +0200
- Add more info for warnings promoted to errors (rust-lang-nursery/edition-guide#247)
- Create triagebot.toml
- Clarify snippets in 2021 panic docs. (rust-lang-nursery/edition-guide#245)
Rollup merge of #86916 - godmar:@godmar/thread-yield-documentation-fix, r=joshtriplett
rewrote documentation for thread::yield_now()
The old documentation suggested the use of yield_now for repeated
polling instead of discouraging it; it also made the false claim that
channels are implemented using yield_now. (They are not, except for
a corner case).
Rollup merge of #86907 - pietroalbini:ci-cpu-stats-python3, r=Mark-Simulacrum
Migrate `cpu-usage-over-time.py` to Python 3
The only change here is a fix for `sys.platform` on Linux. Python 3.3 changed the API to return `"linux"` instead of `"linux2"`/`"linux3"`, so this PR uses `.startswith("linux")` to make the code work on Python 3 without breaking Python 2.
Rollup merge of #86717 - rylev:rename, r=nikomatsakis
Rename some Rust 2021 lints to better names
Based on conversation in https://github.com/rust-lang/rust/issues/85894.
Rename a bunch of Rust 2021 related lints:
Lints that are officially renamed because they are already in beta or stable:
* `disjoint_capture_migration` => `rust_2021_incompatible_closure_captures`
* `or_patterns_back_compat` => `rust_2021_incompatible_or_patterns`
* `non_fmt_panic` => `non_fmt_panics`
Lints that are renamed but don't require any back -compat work since they aren't yet in stable:
* `future_prelude_collision` => `rust_2021_prelude_collisions`
* `reserved_prefix` => `rust_2021_token_prefixes`
Lints that have been discussed but that I did not rename:
* ~`non_fmt_panic` and `bare_trait_object`: is making this plural worth the headache we might cause users?~
* `array_into_iter`: I'm unsure of a good name and whether bothering users with a name change is worth it.
Rollup merge of #80918 - yoshuawuyts:int-log2, r=m-ou-se
Add Integer::log variants
_This is another attempt at landing https://github.com/rust-lang/rust/pull/70835, which was approved by the libs team but failed on Android tests through Bors. The text copied here is from the original issue. The only change made so far is the addition of non-`checked_` variants of the log methods._
_Tracking issue: #70887_
---
This implements `{log,log2,log10}` methods for all integer types. The implementation was provided by `@substack` for use in the stdlib.
_Note: I'm not big on math, so this PR is a best effort written with limited knowledge. It's likely I'll be getting things wrong, but happy to learn and correct. Please bare with me._
## Motivation
Calculating the logarithm of a number is a generally useful operation. Currently the stdlib only provides implementations for floats, which means that if we want to calculate the logarithm for an integer we have to cast it to a float and then back to an int.
> would be nice if there was an integer log2 instead of having to either use the f32 version or leading_zeros() which i have to verify the results of every time to be sure
At higher numbers converting from an integer to a float we also risk overflows. This means that Rust currently only provides log operations for a limited set of integers.
The process of doing log operations by converting between floats and integers is also prone to rounding errors. In the following example we're trying to calculate `base10` for an integer. We might try and calculate the `base2` for the values, and attempt [a base swap](https://www.rapidtables.com/math/algebra/Logarithm.html#log-rules) to arrive at `base10`. However because we're performing intermediate rounding we arrive at the wrong result:
```rust
// log10(900) = ~2.95 = 2
dbg!(900f32.log10() as u64);
// log base change rule: logb(x) = logc(x) / logc(b)
// log2(900) / log2(10) = 9/3 = 3
dbg!((900f32.log2() as u64) / (10f32.log2() as u64));
```
_[playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6bd6c68b3539e400f9ca4fdc6fc2eed0)_
This is somewhat nuanced as a lot of the time it'll work well, but in real world code this could lead to some hard to track bugs. By providing correct log implementations directly on integers we can help prevent errors around this.
## Implementation notes
I checked whether LLVM intrinsics existed before implementing this, and none exist yet. ~~Also I couldn't really find a better way to write the `ilog` function. One option would be to make it a private method on the number, but I didn't see any precedent for that. I also didn't know where to best place the tests, so I added them to the bottom of the file. Even though they might seem like quite a lot they take no time to execute.~~
## References
- [Log rules](https://www.rapidtables.com/math/algebra/Logarithm.html#log-rules)
- [Rounding error playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6bd6c68b3539e400f9ca4fdc6fc2eed0)
- [substack's tweet asking about integer log2 in the stdlib](https://twitter.com/substack/status/1236445105197727744)
- [Integer Logarithm, A. Jaffer 2008](https://people.csail.mit.edu/jaffer/III/ilog.pdf)
Auto merge of #86911 - bjorn3:crate_info_refactor, r=petrochenkov
Refactor linker code
This merges `LinkerInfo` into `CrateInfo` as there is no reason to keep them separate. `LinkerInfo::to_linker` is merged into `get_linker` as both have different logic for each linker type and `to_linker` is directly called after `get_linker`. Also contains a couple of small cleanups.
Godmar Back [Tue, 6 Jul 2021 19:50:42 +0000 (15:50 -0400)]
rewrote documentation for thread::yield_now()
The old documentation suggested the use of yield_now for repeated
polling instead of discouraging it; it also made the false claim that
channels are implementing using yield_now. (They are not, except for
a corner case).
Auto merge of #86636 - wesleywiser:misc_enum_improvements, r=michaelwoerister
[msvc] Consistently show active variant and fix visualization for single variant enums
Prior to this change, there were a few cases where inspecting an enum in either WinDbg or Visual Studio would not show the active variant name. After these changes, we now consistently show the active variant name as `[variant]` in the debugger.
We also didn't handle single variant enums very well. That is now also resolved.
Pietro Albini [Tue, 6 Jul 2021 13:45:15 +0000 (15:45 +0200)]
migrate cpu-usage-over-time.py to python 3
The only change here is a fix for `sys.platform` on Linux. Python 3.3
changed the API to return "linux" instead of "linux2"/"linux3", so this
commit uses `.startswith("python")` to make the code work on Python 3
without breaking Python 2.
Auto merge of #86231 - nagisa:nagisa/abi-allowlist, r=petrochenkov
Replace per-target ABI denylist with an allowlist
It makes very little sense to maintain denylists of ABIs when, as far as
non-generic ABIs are concerned, targets usually only support a small
subset of the available ABIs.
This has historically been a cause of bugs such as us allowing use of
the platform-specific ABIs on x86 targets – these in turn would cause
LLVM errors or assertions to fire.
In this PR we got rid of the per-target ABI denylists, and instead compute
which ABIs are supported with a simple match based on, mostly, the
`Target::arch` field. Among other things, this makes it impossible to
forget to consider this problem (in either direction) and forces one to
consider what the ABI support looks like when adding an ABI (rarely)
rather than target (often), which should hopefully also reduce the
cognitive load on both contributors as well as reviewers.
Fixes #57182
Sponsored by: standard.ai
---
## Summary for teams
One significant user-facing change after this PR is that there's now a future compat warning when building…
* `stdcall`, `fastcall`, `thiscall` using code with targets other than 32-bit x86 (i386...i686) or *-windows-*;
* `vectorcall` using code when building for targets other than x86 (either 32 or 64 bit) or *-windows-*.
Previously these ABIs have been accepted much more broadly, even for architectures and targets where this made no sense (e.g. on wasm32) and would fall back to the C ABI. In practice this doesn't seem to be used too widely and the [breakages in crater](https://github.com/rust-lang/rust/pull/86231#issuecomment-866300943) that we see are mostly about Windows-specific code that was missing relevant `cfg`s and just happened to successfully `check` on Linux for one reason or another.
The intention is that this warning becomes a hard error after some time.
It makes very little sense to maintain denylists of ABIs when, as far as
non-generic ABIs are concerned, targets usually only support a small
subset of the available ABIs.
This has historically been a cause of bugs such as us allowing use of
the platform-specific ABIs on x86 targets – these in turn would cause
LLVM errors or assertions to fire.
Auto merge of #86644 - Stupremee:replace-fakedefids-with-itemid, r=jyn514
rustdoc: Replace `FakeDefId` with new `ItemId` type
Follow up from #84707
`@Manishearth` [suggested](https://github.com/rust-lang/rust/pull/84707#issuecomment-831994669) that there should be a new `ItemId` type that can distinguish between auto traits, normal ids, and blanket impls instead of using `FakeDefId`s.
This type is introduced by this PR.
There are still some `FIXME`s left, because I was unsure what the best solution for them would be.
Especially the naming in general now is a bit weird right now and needs to be cleaned up. Now there are no "fake" ids so the `is_fake` method on `Item` does not really make sense and maybe the methods on `ItemId` should be renamed too?
Also, we need to represent the new item ids in the JSON backend somehow.
Rollup merge of #86886 - jyn514:no-clean-symbol, r=GuillaumeGomez
Remove `impl Clean for {Ident, Symbol}`
These were only used once, in a place where it was trivial to replace.
Also, it's unclear what 'clean' would mean for these, so it seems better
to be explicit.
Found while reviewing https://github.com/rust-lang/rust/pull/86841, which makes the same change to `build_macro`, so the two will conflict.
Rollup merge of #86852 - Amanieu:remove_doc_aliases, r=joshtriplett
Remove some doc aliases
As per the new doc alias policy in https://github.com/rust-lang/std-dev-guide/pull/25, this removes some controversial doc aliases:
- `malloc`, `alloc`, `realloc`, etc.
- `length` (alias for `len`)
- `delete` (alias for `remove` in collections and also file/directory deletion)
Rollup merge of #85377 - ijackson:abort-docs, r=m-ou-se
aborts: Clarify documentation and comments
In the docs for intrinsics::abort():
* Strengthen the recommendation by to use process::abort instead.
* Document the fact that it sometimes (ab)uses an LLVM debug trap and what the likely consequences are.
* State that the precise behaviour is unstable.
In the docs for process::abort():
* Promise that we have the same behaviour as C `abort()`.
* Document the likely consequences, including, specifically, the consequences on Unix.
In the internal comment for unix::abort_internal:
* Refer to the public docs for the public API functions.
* Correct and expand the description of libc::abort. Specifically:
* Do not claim that abort() unregisters signal handlers. It doesn't; it honours the SIGABRT handler.
* Discuss, extensively, the issue with abort() flushing stdio buffers.
* Describe the glibc behaviour in some detail.
Co-authored-by: Mark Wooding <mdw@distorted.org.uk> Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Fixes #40230
This is my first PR here, so please forgive me if I've missed an important step or otherwise done something wrong. I'm very open to suggestions/fixes/corrections.
This PR adds a function that allows `std::fs::DirEntry` to vend a borrow of its filename on Unix platforms, which is especially useful for sorting. (Windows has (as I understand it) encoding differences that require an allocation.) This new function sits alongside the cross-platform [`file_name(&self) -> OsString`](https://doc.rust-lang.org/std/fs/struct.DirEntry.html#method.file_name) function.
I pitched this idea in an [internals thread](https://internals.rust-lang.org/t/allow-std-direntry-to-vend-borrows-of-its-filename/14328/4), and no one objected vehemently, so here we are.
I understand features in general, I believe, but I'm not at all confident that my whole-cloth invention of a new feature string (as required by the compiler) was correct (or that the name is appropriate). Further, there doesn't appear to be a test for the sibling `ino` function, so I didn't add one for this similarly trivial function either. If it's desirable that I should do so, I'd be happy to [figure out how to] do that.
The following is a trivial sample of a use-case for this function, in which directory entries are sorted without any additional allocations:
```rust
use std::os::unix::fs::DirEntryExt;
use std::{fs, io};
Auto merge of #86674 - Aaron1011:new-querify-limits, r=michaelwoerister
Query-ify global limit attribute handling
Currently, we read various 'global limits' from inner attributes the crate root (`recursion_limit`, `move_size_limit`, `type_length_limit`, `const_eval_limit`). These limits are then stored in `Sessions`, allowing them to be access from a `TyCtxt` without registering a dependency on the crate root attributes.
This PR moves the calculation of these global limits behind queries, so that we properly track dependencies on crate root attributes. During the setup of macro expansion (before we've created a `TyCtxt`), we need to access the recursion limit, which is now done by directly calling into the code shared by the normal query implementations.
Joshua Nelson [Mon, 5 Jul 2021 15:18:13 +0000 (11:18 -0400)]
Remove `impl Clean for {Ident, Symbol}`
These were only used once, in a place where it was trivial to replace.
Also, it's unclear what 'clean' would mean for these, so it seems better
to be explicit.
projects / rust.git / log