bors [Sat, 27 Mar 2021 10:40:16 +0000 (10:40 +0000)]
Auto merge of #78618 - workingjubilee:ieee754-fmt, r=m-ou-se
Add IEEE 754 compliant fmt/parse of -0, infinity, NaN
This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values, namely signed zero, the infinities, and NaN. It also adds IEEE 754 compliance tests that, while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests, are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks.
This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074, and closes #24623.
The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers, i.e. not the extended reals (where floats live), IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely, when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition, the vast majority of other programming languages not only output `-0` but output `-0.0` here.
While IEEE 754 offers a broad leeway in how to handle producing what it calls a "decimal character sequence", it is clear that the operations a language provides should be capable of round tripping, and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further, existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character, but it prints "+0" instead if given such (which was what led to the opening of #24623).
There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard, as well as other well-documented challenges on the arithmetic level, but I hope that this can be the beginning of motion towards solving those challenges.
bors [Sat, 27 Mar 2021 07:59:24 +0000 (07:59 +0000)]
Auto merge of #83547 - JohnTitor:rollup-qh7j6hg, r=JohnTitor
Rollup of 9 pull requests
Successful merges:
- #83239 (Remove/replace some outdated crates from the dependency tree)
- #83328 (Fixes to inline assmebly tests)
- #83343 (Simplify and fix byte skipping in format! string parser)
- #83388 (Make # pretty print format easier to discover)
- #83431 (Tell GitHub to highlight `config.toml.example` as TOML)
- #83508 (Use the direct link to the platform support page)
- #83511 (compiletest: handle llvm_version with suffix like "12.0.0libcxx")
- #83524 (Document that the SocketAddr memory representation is not stable)
- #83525 (fix doc comment for `ty::Dynamic`)
Yuki Okushi [Sat, 27 Mar 2021 03:37:24 +0000 (12:37 +0900)]
Rollup merge of #83524 - faern:document-socketaddr-mem-layout, r=sfackler
Document that the SocketAddr memory representation is not stable
Intended to help out with #78802. Work has been put into finding and fixing code that assumes the memory layout of `SocketAddrV4` and `SocketAddrV6`. But it turns out there are cases where new code continues to make the same assumption ([example](https://github.com/spacejam/seaslug/commit/96927dc2b7b918860a79c4eb6336051e52c6137a#diff-917db3d8ca6f862ebf42726b23c72a12b35e584e497ebdb24e474348d7c6ffb6R610-R621)).
The memory layout of a type in `std` is never part of the public API. Unless explicitly stated I guess. But since that is invalidly relied upon by a considerable amount of code for these particular types, it might make sense to explicitly document this. This can be temporary. Once #78802 lands it does not make sense to rely on the layout any longer, and this documentation can also be removed.
Yuki Okushi [Sat, 27 Mar 2021 03:37:23 +0000 (12:37 +0900)]
Rollup merge of #83511 - 12101111:fix-llvm-version-suffix, r=Mark-Simulacrum
compiletest: handle llvm_version with suffix like "12.0.0libcxx"
The previous code only remove the suffix begin with `-`, but Gentoo Linux [define `LLVM_VERSION_SUFFIX="libcxx"`](https://github.com/gentoo/gentoo/blob/604d79f327176eecb05293d7154e24231229cb31/sys-devel/llvm/llvm-11.1.0.ebuild#L378) when llvm is linked to libc++ and lead to a panic:
```
thread 'main' panicked at 'Malformed version component: ParseIntError { kind: InvalidDigit }', src/tools/compiletest/src/header.rs:968:28
```
This new code will handle all suffix not beginning with digit or dot.
Yuki Okushi [Sat, 27 Mar 2021 03:37:20 +0000 (12:37 +0900)]
Rollup merge of #83388 - alamb:alamb/fmt-dcs, r=Mark-Simulacrum
Make # pretty print format easier to discover
# Rationale:
I use (cargo cult?) three formats in rust: `{}`, debug `{:?}`, and pretty-print debug `{:#?}`. I discovered `{:#?}` in some blog post or guide when I started working in Rust. While `#` is documented I think it is hard to discover. So taking the good advice of ```@carols10cents``` I am trying to improve the docs with a PR
As a reminder "pretty print" means that where `{:?}` will print something like
```
foo: { b1: 1, b2: 2}
```
`{:#?}` will prints something like
```
foo {
b1: 1
b2: 3
}
```
# Changes
Add an example to `fmt` to try and make it easier to discover `#`
bors [Fri, 26 Mar 2021 23:01:18 +0000 (23:01 +0000)]
Auto merge of #83418 - ehuss:update-cargo, r=ehuss
Update cargo
12 commits in 90691f2bfe9a50291a98983b1ed2feab51d5ca55..1e8703890f285befb5e32627ad4e0a0454dde1fb
2021-03-16 21:36:55 +0000 to 2021-03-26 16:59:39 +0000
- tests: Tolerate "exit status" in error messages (rust-lang/cargo#9307)
- Default macOS targets to `unpacked` debuginfo (rust-lang/cargo#9298)
- Fix publication of packages with metadata and resolver (rust-lang/cargo#9300)
- Fix config includes not working. (rust-lang/cargo#9299)
- Emit note when `--future-incompat-report` had nothing to report (rust-lang/cargo#9263)
- RFC 3052: Stop including authors field in manifests made by cargo new (rust-lang/cargo#9282)
- Refactor feature handling, and improve error messages. (rust-lang/cargo#9290)
- Split out cargo-util package for cargo-test-support. (rust-lang/cargo#9292)
- Fix redundant_semicolons warning in resolver-tests. (rust-lang/cargo#9293)
- Use serde's error message option to avoid implementing `Deserialize`. (rust-lang/cargo#9237)
- Allow `cargo update` to operate with the --offline flag (rust-lang/cargo#9279)
- Fix typo in faq.md (rust-lang/cargo#9285)
bors [Fri, 26 Mar 2021 17:26:18 +0000 (17:26 +0000)]
Auto merge of #83488 - Aaron1011:ban-expr-inner-attrs, r=petrochenkov
Ban custom inner attributes in expressions and statements
Split out from https://github.com/rust-lang/rust/pull/82608
Custom inner attributes are unstable, so this won't break any stable users.
This allows us to speed up token collection, and avoid a redundant call to `collect_tokens_no_attrs` when parsing an `Expr` that has outer attributes.
bors [Fri, 26 Mar 2021 11:57:44 +0000 (11:57 +0000)]
Auto merge of #82980 - tmiasko:import-cold-multiplier, r=michaelwoerister
Import small cold functions
The Rust code is often written under an assumption that for generic
methods inline attribute is mostly unnecessary, since for optimized
builds using ThinLTO, a method will be code generated in at least one
CGU and available for import.
For example, deref implementations for Box, Vec, MutexGuard, and
MutexGuard are not currently marked as inline, neither is identity
implementation of From trait.
In PGO builds, when functions are determined to be cold, the default
multiplier of zero will stop the import, no matter how trivial the
implementation.
Increase slightly the default multiplier from 0 to 0.1.
bors [Fri, 26 Mar 2021 04:10:13 +0000 (04:10 +0000)]
Auto merge of #83503 - Dylan-DPC:rollup-mqvjfav, r=Dylan-DPC
Rollup of 8 pull requests
Successful merges:
- #83055 ([rustdoc] Don't document stripped items in JSON renderer.)
- #83437 (Refactor #82270 as lint instead of an error)
- #83444 (Fix bootstrap tests on beta)
- #83456 (Add docs for Vec::from functions)
- #83463 (ExitStatusExt: Fix missing word in two docs messages)
- #83470 (Fix patch note about #80653 not mentioning nested nor recursive)
- #83485 (Mark asm tests as requiring LLVM 10.0.1)
- #83486 (Don't ICE when using `#[global_alloc]` on a non-item statement)
Dylan DPC [Fri, 26 Mar 2021 01:34:43 +0000 (02:34 +0100)]
Rollup merge of #83470 - danielhenrymantilla:patch-1, r=jyn514
Fix patch note about #80653 not mentioning nested nor recursive
Which thus missed the point of the change: `rustdoc` already bundled documentation for methods accessible through one layer of `Deref`, it has now been enhanced to keep recursing 🙂
Dylan DPC [Fri, 26 Mar 2021 01:34:39 +0000 (02:34 +0100)]
Rollup merge of #83437 - Amanieu:asm_syntax, r=petrochenkov
Refactor #82270 as lint instead of an error
This PR fixes several issues with #82270 which generated an error when `.intel_syntax` or `.att_syntax` was used in inline assembly:
- It is now a warn-by-default lint instead of an error.
- The lint only triggers on x86. `.intel_syntax` and `.att_syntax` are only valid on x86.
- The lint no longer provides machine-applicable suggestions for two reasons:
- These changes should not be made automatically since changes to assembly code can be very subtle.
- The template string is not always just a string: it can contain macro invocation (`concat!`), raw strings, escape characters, etc.
bors [Fri, 26 Mar 2021 01:28:59 +0000 (01:28 +0000)]
Auto merge of #83465 - michaelwoerister:safe-read_raw_bytes, r=cjgillot
Allow for reading raw bytes from rustc_serialize::Decoder without unsafe code
The current `read_raw_bytes` method requires using `MaybeUninit` and `unsafe`. I don't think this is necessary. Let's see if a safe interface has any performance drawbacks.
This is a followup to #83273 and will make it easier to rebase #82183.
bors [Thu, 25 Mar 2021 22:09:27 +0000 (22:09 +0000)]
Auto merge of #82873 - GuillaumeGomez:rustdoc-const-ty, r=jyn514
Rework rustdoc const type
This PR is mostly about two things:
1. Not storing some information in the `clean::Constant` type
2. Using `TyCtxt` in the formatting (which we will need in any case as we move forward in any case).
Also: I'm very curious of the perf change in here.
Thanks a lot `@danielhenrymantilla` for your `Captures` idea! It allowed me to solve the lifetime issue completely. :)
bors [Thu, 25 Mar 2021 19:28:16 +0000 (19:28 +0000)]
Auto merge of #82743 - jackh726:resolve-refactor, r=nikomatsakis
Refactor rustc_resolve::late::lifetimes to resolve per-item
There are some changes to tests that I'd like some feedback on; so this is still WIP.
The reason behind this change will (hopefully) allow us to (as part of #76814) be able to essentially use the lifetime resolve code to resolve *all* late bound vars (including those of super traits). Currently, it only resolves those that are *syntactically* in scope. In #76814, I'm essentially finding that I would essentially have to redo the passing of bound vars through scopes (i.e. when instantiating a poly trait ref), and that's what this code does anyways. However, to be able to do this (ask super traits what bound vars are in scope), we have to be able to resolve items separately.
The first commit is actually partially orthogonal. Essentially removing one use of late bound debruijn indices.
Not exactly sure who would be best to review here.
Let r? `@nikomatsakis`
Fix patch note about #80653 not mentioning nested nor recursive
Which thus missed the point of the change: `rustdoc` already bundled documentation for methods accessible through one layer of `Deref`, it now has been enhanced to keep recursing 🙂
bors [Thu, 25 Mar 2021 05:07:34 +0000 (05:07 +0000)]
Auto merge of #83307 - richkadel:cov-unused-functions-1.1, r=tmandry
coverage bug fixes and optimization support
Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to
address multiple, somewhat related issues.
Fixed a significant flaw in prior coverage solution: Every counter
generated a new counter variable, but there should have only been one
counter variable per function. This appears to have bloated .profraw
files significantly. (For a small program, it increased the size by
about 40%. I have not tested large programs, but there is anecdotal
evidence that profraw files were way too large. This is a good fix,
regardless, but hopefully it also addresses related issues.
Fixes: #82144
Invalid LLVM coverage data produced when compiled with -C opt-level=1
Existing tests now work up to at least `opt-level=3`. This required a
detailed analysis of the LLVM IR, comparisons with Clang C++ LLVM IR
when compiled with coverage, and a lot of trial and error with codegen
adjustments.
The biggest hurdle was figuring out how to continue to support coverage
results for unused functions and generics. Rust's coverage results have
three advantages over Clang's coverage results:
1. Rust's coverage map does not include any overlapping code regions,
making coverage counting unambiguous.
2. Rust generates coverage results (showing zero counts) for all unused
functions, including generics. (Clang does not generate coverage for
uninstantiated template functions.)
3. Rust's unused functions produce minimal stubbed functions in LLVM IR,
sufficient for including in the coverage results; while Clang must
generate the complete LLVM IR for each unused function, even though
it will never be called.
This PR removes the previous hack of attempting to inject coverage into
some other existing function instance, and generates dedicated instances
for each unused function. This change, and a few other adjustments
(similar to what is required for `-C link-dead-code`, but with lower
impact), makes it possible to support LLVM optimizations.
Fixes: #79651
Coverage report: "Unexecuted instantiation:..." for a generic function
from multiple crates
Fixed by removing the aforementioned hack. Some "Unexecuted
instantiation" notices are unavoidable, as explained in the
`used_crate.rs` test, but `-Zinstrument-coverage` has new options to
back off support for either unused generics, or all unused functions,
which avoids the notice, at the cost of less coverage of unused
functions.
Fixes: #82875
Invalid LLVM coverage data produced with crate brotli_decompressor
Fixed by disabling the LLVM function attribute that forces inlining, if
`-Z instrument-coverage` is enabled. This attribute is applied to
Rust functions with `#[inline(always)], and in some cases, the forced
inlining breaks coverage instrumentation and reports.
Yuki Okushi [Thu, 25 Mar 2021 00:07:32 +0000 (09:07 +0900)]
Rollup merge of #83442 - durin42:remove-questionable-macros, r=cuviper
LLVMWrapper: attractive nuisance macros
This came up in the review of #83425: it's hard to imagine a use of
LLVM_VERSION_LE() or LLVM_VERSION_EQ() that's not asking for trouble
when a point release gets created, so let's just discard them to prevent
the issue.
Yuki Okushi [Thu, 25 Mar 2021 00:07:26 +0000 (09:07 +0900)]
Rollup merge of #83349 - m-ou-se:unwrap-none, r=dtolnay
Remove Option::{unwrap_none, expect_none}.
This removes `Option::unwrap_none` and `Option::expect_none` since we're not going to stabilize them, see https://github.com/rust-lang/rust/issues/62633.
but it is still an open question whether the other `Debug*` struct's should have a similar method. I would guess that would best be put underneath a new feature gate, as this one seems uncontroversial enough to stabilize as is
bors [Wed, 24 Mar 2021 20:51:37 +0000 (20:51 +0000)]
Auto merge of #83220 - Aaron1011:fix/eval-region-cache, r=nikomatsakis
Use `EvaluatedToOkModuloRegions` whenever we erase regions
Fixes #80691
When we evaluate a trait predicate, we convert an
`EvaluatedToOk` result to `EvaluatedToOkModuloRegions` if we erased any
regions. We cache the result under a region-erased 'freshened'
predicate, so `EvaluatedToOk` may not be correct for other predicates
that have the same cache key.
Aaron Hill [Tue, 16 Mar 2021 23:28:27 +0000 (19:28 -0400)]
Use `EvaluatedToOkModuloRegions` whenever we erase regions
Fixes #80691
When we evaluate a trait predicate, we convert an
`EvaluatedToOk` result to `EvaluatedToOkModuloRegions` if we erased any
regions. We cache the result under a region-erased 'freshened'
predicate, so `EvaluatedToOk` may not be correct for other predicates
that have the same cache key.
Caused by
https://github.com/rust-lang/rust/commit/b0659f9b1bfb92626c40dabceb3268f88bb26224#diff-ede26372490522288745c5b3df2b6b2a1cc913dcd09b29af3a49935afe00c7e6L464-R464
Augie Fackler [Wed, 24 Mar 2021 14:25:03 +0000 (10:25 -0400)]
LLVMWrapper: attractive nuisance macros
THis came up in the review of #83425: it's hard to imagine a use of
LLVM_VERSION_LE() or LLVM_VERSION_EQ() that's not asking for trouble
when a point release gets created, so let's just discard them to prevent
the issue.
bors [Wed, 24 Mar 2021 09:21:06 +0000 (09:21 +0000)]
Auto merge of #83408 - ijackson:expose-splitinclusive, r=dtolnay
Expose str::SplitInclusive in alloc and therefore in std
This seems to have been omitted from the beginning when this feature was first introduced in 86bf96291d82. Most users won't need to name this type which is probably why this wasn't noticed in the meantime.
See #83372 for a different but related bug.
### Notes for reviewers
I think I have got this right but TBH I am not very familiar with the relationship between core and std and so on. <strike>I also haven't don't any kind of test (not even a build) yet. I will do a local docs build to see that the type now appears in the std docs.</strike> I did a local docs build and it has made this type appear as `std::str::SplitInclusive` as expected
The linkification of the return value from `str::split_inclusive` teleports me to the online url for `core::str::SplitInclusive`. I think this may be a rustdoc anomaly (similar to #79630 maybe) but I am not sure. Perhaps it means I haven't done the `std` -> `core` referrence correctly.
I made this insta-stable since it seems like simply a bug. Please LMK if that is not right. *(edited to add:)* In particular, IDK how this ought to relate to the (?)current release process.
bors [Wed, 24 Mar 2021 04:13:27 +0000 (04:13 +0000)]
Auto merge of #75384 - JulianKnodt:cg_def, r=varkor,lcnr
implement `feature(const_generics_defaults)`
Implements const generics defaults `struct Example<const N: usize=3>`, as well as a query for getting the default of a given const-parameter's def id. There are some remaining FIXME's but they were specified as not blocking for merging this PR. This also puts the defaults behind the unstable feature gate `#![feature(const_generics_defaults)]`.
~~This currently creates a field which is always false on `GenericParamDefKind` for future use when
consts are permitted to have defaults. I'm not sure if this is exactly what is best for adding default parameters, but I mimicked the style of type defaults, so hopefully this is ok.~~