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.
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)
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.`
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;`.
Rollup merge of #83535 - MidasLamb:mir-type-count-mismatch, r=nikomatsakis
Break when there is a mismatch in the type count
When other errors are generated, there can be a mismatch between the
amount of input types in MIR, and the amount in the function itself.
Break from the comparative loop if this is the case to prevent
out-of-bounds.
Fixes #83499
normalize mir::Constant differently from ty::Const in preparation for valtrees
Valtrees are unable to represent many kind of constant values (this is on purpose). For constants that are used at runtime, we do not need a valtree representation and can thus use a different form of evaluation. In order to make this explicit and less fragile, I added a `fold_constant` method to `TypeFolder` and implemented it for normalization. Normalization can now, when it wants to eagerly evaluate a constant, normalize `mir::Constant` directly into a `mir::ConstantKind::Val` instead of relying on the `ty::Const` evaluation.
In the future we can get rid of the `ty::Const` in there entirely and add our own `Unevaluated` variant to `mir::ConstantKind`. This would allow us to remove the `promoted` field from `ty::ConstKind::Unevaluated`, as promoteds can never occur in the type system.
Auto merge of #80965 - camelid:rename-doc-spotlight, r=jyn514
Rename `#[doc(spotlight)]` to `#[doc(notable_trait)]`
Fixes #80936.
"spotlight" is not a very specific or self-explaining name.
Additionally, the dialog that it triggers is called "Notable traits".
So, "notable trait" is a better name.
* Rename `#[doc(spotlight)]` to `#[doc(notable_trait)]`
* Rename `#![feature(doc_spotlight)]` to `#![feature(doc_notable_trait)]`
* Update documentation
* Improve documentation
Auto merge of #80828 - SNCPlay42:opaque-projections, r=estebank
Fix expected/found order on impl trait projection mismatch error
fixes #68561
This PR adds a new `ObligationCauseCode` used when checking the concrete type of an impl trait satisfies its bounds, and checks for that cause code in the existing test to see if a projection's normalized type should be the "expected" or "found" type.
The second commit adds a `peel_derives` to that test, which appears to be necessary in some cases (see projection-mismatch-in-impl-where-clause.rs, which would still give expected/found in the wrong order otherwise). This caused some other changes in diagnostics not involving impl trait, but they look correct to me.
Auto merge of #82780 - cjgillot:dep-stream, r=michaelwoerister
Stream the dep-graph to a file instead of storing it in-memory.
This is a reimplementation of #60035.
Instead of storing the dep-graph in-memory, the nodes are encoded as they come
into the a temporary file as they come. At the end of a successful the compilation,
this file is renamed to be the persistent dep-graph, to be decoded during the next
compilation session.
This two-files scheme avoids overwriting the dep-graph on unsuccessful or crashing compilations.
The structure of the file is modified to be the sequence of `(DepNode, Fingerprint, EdgesVec)`.
The deserialization is responsible for going to the more compressed representation.
The `node_count` and `edge_count` are stored in the last 16 bytes of the file,
in order to accurately reserve capacity for the vectors.
At the end of the compilation, the encoder is flushed and dropped.
The graph is not usable after this point: any creation of a node will ICE.
I had to retrofit the debugging options, which is not really pretty.
Auto merge of #83726 - the8472:large-trustedlen-fail-fast, r=kennytm
panic early when `TrustedLen` indicates a `length > usize::MAX`
Changes `TrustedLen` specializations to immediately panic when `size_hint().1 == None`.
As far as I can tell this is ~not a change~ a minimal change in observable behavior for anything except ZSTs because the fallback path would go through `extend_desugared()` which tries to `reserve(lower_bound)` which already is `usize::MAX` and that would also lead to a panic. Before it might have popped somewhere between zero and a few elements from the iterator before panicking while it now panics immediately.
Overall this should reduce codegen by eliminating the fallback paths.
While looking into the `with_capacity()` behavior I also noticed that its documentation didn't have a *Panics* section, so I added that.
Auto merge of #83732 - ehuss:update-cargo, r=ehuss
Update cargo
5 commits in 1e8703890f285befb5e32627ad4e0a0454dde1fb..3c44c3c4b7900b8b13c85ead25ccaa8abb7d8989
2021-03-26 16:59:39 +0000 to 2021-03-31 21:21:15 +0000
- Fix semver docs for 1.51. (rust-lang/cargo#9316)
- Add `cargo config` subcommand. (rust-lang/cargo#9302)
- Give one more example for the --featuers CLI (rust-lang/cargo#9313)
- Bump to 0.54.0, update changelog (rust-lang/cargo#9308)
- Make the URL to the tracking issue for `--out-dir` into a link (rust-lang/cargo#9309)
Auto merge of #83731 - Dylan-DPC:rollup-v2z3gkt, r=Dylan-DPC
Rollup of 5 pull requests
Successful merges:
- #83015 (Add regression tests for #79825 and #81555)
- #83699 (Add a regression test for issue-68830)
- #83700 (Fix documentation of conversion from String to OsString)
- #83711 (Clarify `--print target-list` is a rustc's option)
- #83712 (Update LLVM with another wasm simd fix)
Rollup merge of #83700 - steffahn:string_to_pathbuf_conversion_documentation, r=JohnTitor
Fix documentation of conversion from String to OsString
From [this question on URLO](https://users.rust-lang.org/t/does-converting-a-string-into-a-pathbuf-allocate-new-buffer/57678), I noticed that the documentation of `From<String> for OsString` incorrectly claims to be copying data.
bors [Wed, 31 Mar 2021 05:47:22 +0000 (05:47 +0000)]
Auto merge of #83681 - jyn514:blanket-impls-tweaks, r=Aaron1011
rustdoc: Only look at blanket impls in `get_blanket_impls`
The idea here is that all the work in https://github.com/rust-lang/rust/blob/16156fb2787f745e57504197bd7fe38b69c6cbea/compiler/rustc_middle/src/ty/trait_def.rs#L172-L186 doesn't matter for `get_blanket_impls` - Rustdoc will already pick up on those blocks when it documents the item.
bors [Wed, 31 Mar 2021 03:20:33 +0000 (03:20 +0000)]
Auto merge of #83666 - Amanieu:instrprof-order, r=tmandry
Run LLVM coverage instrumentation passes before optimization passes
This matches the behavior of Clang and allows us to remove several
hacks which were needed to ensure functions weren't optimized away
before reaching the instrumentation pass.
bors [Tue, 30 Mar 2021 23:47:51 +0000 (23:47 +0000)]
Auto merge of #83692 - Dylan-DPC:rollup-2a2m3jy, r=Dylan-DPC
Rollup of 6 pull requests
Successful merges:
- #80720 (Make documentation of which items the prelude exports more readable.)
- #83654 (Do not emit a suggestion that causes the E0632 error)
- #83671 (Add a regression test for issue-75801)
- #83678 (Fix Self keyword doc URL conflict on case insensitive file systems (until definitely fixed on rustdoc))
- #83680 (Update for loop desugaring docs)
- #83683 (bootstrap: don't complain about linkcheck if it is excluded)
Dylan DPC [Tue, 30 Mar 2021 23:14:48 +0000 (01:14 +0200)]
Rollup merge of #83678 - GuillaumeGomez:hack-Self-keyword-conflict, r=jyn514
Fix Self keyword doc URL conflict on case insensitive file systems (until definitely fixed on rustdoc)
This is just a hack to allow rustup to work on macOS and windows again to distribute std documentation (hopefully once https://github.com/rust-lang/rfcs/pull/3097 or an equivalent is merged).
Fixes https://github.com/rust-lang/rust/issues/80504. Prevents https://github.com/rust-lang/rust/issues/83154 and https://github.com/rust-lang/rustup/issues/2694 in future releases.
Dylan DPC [Tue, 30 Mar 2021 23:14:40 +0000 (01:14 +0200)]
Rollup merge of #80720 - steffahn:prettify_prelude_imports, r=camelid,jyn514
Make documentation of which items the prelude exports more readable.
I recently figured out that rustdoc allows link inside of inline code blocks as long as they’re delimited with `<code> </code>` instead of `` ` ` ``. I think this applies nicely in the listing of prelude exports [in the docs](https://doc.rust-lang.org/std/prelude/index.html). There, currently unformatted `::` and `{ , }` is used in order to mimick import syntax while attatching links to individual identifiers.
## Rendered Comparison
### Currently (light)
### After this PR (light)
### Currently (dark)
### After this PR (dark)
### Currently (ayu)
### After this PR (ayu)
_Edit:_ I just noticed, the “current” screenshots are from stable, so there are a few more differences in the pictures than the ones from just this PR.
bors [Tue, 30 Mar 2021 19:34:23 +0000 (19:34 +0000)]
Auto merge of #83652 - xu-cheng:ipv4-octal, r=sfackler
Disallow octal format in Ipv4 string
In its original specification, leading zero in Ipv4 string is interpreted
as octal literals. So a IP address 0127.0.0.1 actually means 87.0.0.1.
This confusion can lead to many security vulnerabilities. Therefore, in
[IETF RFC 6943], it suggests to disallow octal/hexadecimal format in Ipv4
string all together.
Existing implementation already disallows hexadecimal numbers. This commit
makes Parser reject octal numbers.
Tom Eccles [Tue, 30 Mar 2021 17:36:53 +0000 (18:36 +0100)]
bootstrap: don't complain about linkcheck if it is excluded
We don't need to complain to the user about linkcheck having different
hosts and targets when it is already excluded. This can be achieved by
moving the check to when the step is run instead of in should_run.
projects / rust.git / log