Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 11 pull requests #78956

Merged
merged 25 commits into from
Nov 12, 2020
Merged

Rollup of 11 pull requests #78956

merged 25 commits into from
Nov 12, 2020

Conversation

jonas-schievink
Copy link
Contributor

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

workingjubilee and others added 25 commits October 21, 2020 20:03
This expands time's test suite to use more and in more places the
range of methods and constants added to Duration in recent
proposals for the sake of testing more API surface area and
improving legibility.
Duration::ZERO composes better with match and various other things,
at the cost of an occasional parens, and results in less work for the
optimizer, so let's use that instead.
Duration::ZERO supercedes it in effect.
Additionally introduce storage markers for all temporaries created by
the inliner. The temporary introduced for destination rebrorrow, didn't
use them previously.
* `-Zinline-mir-threshold` to change the default threshold.
* `-Zinline-mir-hint-threshold` to change the threshold used by
  functions with inline hint.
occurences -> occurrences
Duration::zero() -> Duration::ZERO

In review for #72790, whether or not a constant or a function should be favored for `#![feature(duration_zero)]` was seen as an open question. In #73544 (comment) an invitation was opened to either stabilize the methods or propose a switch to the constant value, supplemented with reasoning. Followup comments suggested community preference leans towards the const ZERO, which would be reason enough.

ZERO also "makes sense" beside existing associated consts for Duration. It is ever so slightly awkward to have a series of constants specifying 1 of various units but leave 0 as a method, especially when they are side-by-side in code. It seems unintuitive for the one non-dynamic value (that isn't from Default) to be not-a-const, which could hurt discoverability of the associated constants overall. Elsewhere in `std`, methods for obtaining a constant value were even deprecated, as seen with [std::u32::min_value](https://doc.rust-lang.org/std/primitive.u32.html#method.min_value).

Most importantly, ZERO costs less to use. A match supports a const pattern, but const fn can only be used if evaluated through a const context such as an inline `const { const_fn() }` or a `const NAME: T = const_fn()` declaration elsewhere. Likewise, while #73544 (comment) notes `Duration::zero()` can optimize to a constant value, "can" is not "will". Only const contexts have a strong promise of such. Even without that in mind, the comment in question still leans in favor of the constant for simplicity. As it costs less for a developer to use, may cost less to optimize, and seems to have more of a community consensus for it, the associated const seems best.

r? ```@LukasKalbertodt```
Support enable/disable sanitizers/profiler per target

This PR add options under `[target.*]` of `config.toml` which can enable or disable sanitizers/profiler runtime for corresponding target.
If these options are empty, the global options under `[build]` will take effect.

Fix #78329
BTreeMap: split off most code of append

To complete #78056, move the last single-purpose pieces of code out of map.rs into a separate module. Also, tweaked documentation and safeness - I doubt think this code would be safe if the iterators passed in wouldn't be as sorted as the method says they should be - and bounds on MergeIterInner.

r? ```@Mark-Simulacrum```
look at assoc ct, check the type of nodes

an example where types matter are function objects, see the added test which previously passed.

Now does a shallow comparison of unevaluated constants.

r? ```@oli-obk```
Add flags customizing behaviour of MIR inlining

* `-Zinline-mir-threshold` to change the default threshold.
* `-Zinline-mir-hint-threshold` to change the threshold used by
  functions with inline hint.

Having those as configurable flags makes it possible to experiment with with
different inlining thresholds and substantially increase test coverage of MIR
inlining when used with increased thresholds (for example, necessary to test
#78844).
Support inlining diverging function calls

The existing heuristic does penalize diverging calls to some degree, but since
it never inlined them previously it might need some further modifications.

Additionally introduce storage markers for all temporaries created by
the inliner. The temporary introduced for destination rebrorrow, didn't
use them previously.
Cleanup and comment intra-doc link pass

r? ```@Manishearth```
cc ```@seeplusplus```
rustc_target: Move target env "gnu" from `linux_base` to `linux_gnu_base`

Follow up to #77729.

Changes the target spec hierarchy for Linux from
```
linux_base
├── linux_musl_base
└── linux_uclibc_base
```
where `linux_base` is really `linux_gnu_base` and the inheriting targets replace target env "gnu" with "musl"/"uclibc" to
```
linux_base
├── linux_gnu_base
├── linux_musl_base
└── linux_uclibc_base
```
which is slightly less confusing (I think).
rustc_taret: Remove `TargetOptions::is_like_android`

This option was replaced by more specific options and is no longer used by the compiler.
Fix typo in comment

occurences -> occurrences
Ship llvm-cov through llvm-tools

`llvm-cov` is used to generate coverage report with LLVM InstrProf-based code coverage #34701.
So if `llvm-cov` is shipped through llvm-tools, users can try it easily accorging to the instruction of [The Rust Unstable Book](https://doc.rust-lang.org/nightly/unstable-book/compiler-flags/source-based-code-coverage.html).
@rustbot rustbot added the rollup A PR which is a rollup label Nov 11, 2020
@jonas-schievink
Copy link
Contributor Author

@bors r+ rollup=never p=11

@rustbot modify labels: rollup

@bors
Copy link
Contributor

bors commented Nov 11, 2020

📌 Commit 61c0a2c has been approved by jonas-schievink

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Nov 11, 2020
@bors
Copy link
Contributor

bors commented Nov 11, 2020

⌛ Testing commit 61c0a2c with merge 77180db...

@bors
Copy link
Contributor

bors commented Nov 12, 2020

☀️ Test successful - checks-actions
Approved by: jonas-schievink
Pushing 77180db to master...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.