Skip to content

Rollup of 13 pull requests #79070

New issue

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

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

Already on GitHub? # to your account

Merged
merged 26 commits into from
Nov 15, 2020
Merged

Rollup of 13 pull requests #79070

merged 26 commits into from
Nov 15, 2020

Conversation

jonas-schievink
Copy link
Contributor

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

jyn514 and others added 26 commits November 7, 2020 13:45
The main change is that `UnstableOptions::from_environment` now requires
an (optional) crate name. If the crate name is unknown (`None`), then the new feature is not available and you still have to use `RUSTC_BOOTSTRAP=1`. In practice this means the feature is only available for `--crate-name`, not for `#![crate_name]`; I'm interested in supporting the second but I'm not sure how.

Other major changes:

- Added `Session::is_nightly_build()`, which uses the `crate_name` of
the session
- Added `nightly_options::match_is_nightly_build`, a convenience method
for looking up `--crate-name` from CLI arguments.
`Session::is_nightly_build()`should be preferred where possible, since
it will take into account `#![crate_name]` (I think).
- Added `unstable_features` to `rustdoc::RenderOptions`

  There is a user-facing change here: things like `RUSTC_BOOTSTRAP=0` no
  longer active nightly features. In practice this shouldn't be a big
  deal, since `RUSTC_BOOTSTRAP` is the opposite of stable and everyone
  uses `RUSTC_BOOTSTRAP=1` anyway.

- Add tests

  Check against `Cheat`, not whether nightly features are allowed.
  Nightly features are always allowed on the nightly channel.

- Only call `is_nightly_build()` once within a function

- Use booleans consistently for rustc_incremental

  Sessions can't be passed through threads, so `read_file` couldn't take a
  session. To be consistent, also take a boolean in `write_file_header`.
Co-authored-by: varkor <github@varkor.com>
The previous `likely!`/`unlikely!` macros were unsound because it
permits the caller's expr to contain arbitrary unsafe code.

    pub fn huh() -> bool {
        likely!(std::ptr::read(&() as *const () as *const bool))
    }

Before: compiles cleanly.
After:

    error[E0133]: call to unsafe function is unsafe and requires unsafe function or block
       |
    70 |     likely!(std::ptr::read(&() as *const () as *const bool))
       |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ call to unsafe function
       |
       = note: consult the function's documentation for information on how to avoid undefined behavior
… artifacts

Before:

```
Checking rustdoc artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Checking rustdoc v0.0.0 (/home/joshua/rustc/src/librustdoc)
    Checking rustdoc-tool v0.0.0 (/home/joshua/rustc/src/tools/rustdoc)
    Finished release [optimized] target(s) in 2.08s
    Checking regalloc v0.0.31
    Checking gimli v0.22.0
    Checking object v0.21.1
    Checking cranelift-codegen v0.67.0 (https://github.com/bytecodealliance/wasmtime/?branch=main#44cbdece)
    Checking cranelift-module v0.67.0 (https://github.com/bytecodealliance/wasmtime/?branch=main#44cbdece)
    Checking cranelift-native v0.67.0 (https://github.com/bytecodealliance/wasmtime/?branch=main#44cbdece)
    Checking cranelift-frontend v0.67.0 (https://github.com/bytecodealliance/wasmtime/?branch=main#44cbdece)
    Checking cranelift-object v0.67.0 (https://github.com/bytecodealliance/wasmtime/?branch=main#44cbdece)
    Checking cranelift-simplejit v0.67.0 (https://github.com/bytecodealliance/wasmtime/?branch=main#44cbdece)
    Checking rustc_codegen_cranelift v0.1.0 (/home/joshua/rustc/compiler/rustc_codegen_cranelift)
    Finished release [optimized] target(s) in 10.55s

```

After:

```
Checking rustdoc artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Checking rustdoc v0.0.0 (/home/joshua/rustc/src/librustdoc)
    Checking rustdoc-tool v0.0.0 (/home/joshua/rustc/src/tools/rustdoc)
    Finished release [optimized] target(s) in 2.08s
Checking cranelift artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Checking cranelift-codegen v0.67.0 (https://github.com/bytecodealliance/wasmtime/?branch=main#44cbdece)
```
Allow making `RUSTC_BOOTSTRAP` conditional on the crate name

Motivation: This came up in the [Zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Require.20users.20to.20confirm.20they.20know.20RUSTC_.E2.80.A6.20compiler-team.23350/near/208403962) for rust-lang/compiler-team#350.
See also rust-lang/cargo#6608 (comment); this implements rust-lang/cargo#6627.
The goal is for this to eventually allow prohibiting setting `RUSTC_BOOTSTRAP` in build.rs (rust-lang/cargo#7088).

## User-facing changes

- `RUSTC_BOOTSTRAP=1` still works; there is no current plan to remove this.
- Things like `RUSTC_BOOTSTRAP=0` no longer activate nightly features. In practice this shouldn't be a big deal, since `RUSTC_BOOTSTRAP` is the opposite of stable and everyone uses `RUSTC_BOOTSTRAP=1` anyway.
- `RUSTC_BOOTSTRAP=x` will enable nightly features only for crate `x`.
- `RUSTC_BOOTSTRAP=x,y` will enable nightly features only for crates `x` and `y`.

## Implementation changes

The main change is that `UnstableOptions::from_environment` now requires
an (optional) crate name. If the crate name is unknown (`None`), then the new feature is not available and you still have to use `RUSTC_BOOTSTRAP=1`. In practice this means the feature is only available for `--crate-name`, not for `#![crate_name]`; I'm interested in supporting the second but I'm not sure how.

Other major changes:

- Added `Session::is_nightly_build()`, which uses the `crate_name` of
the session
- Added `nightly_options::match_is_nightly_build`, a convenience method
for looking up `--crate-name` from CLI arguments.
`Session::is_nightly_build()`should be preferred where possible, since
it will take into account `#![crate_name]` (I think).
- Added `unstable_features` to `rustdoc::RenderOptions`

I'm not sure whether this counts as T-compiler or T-lang; _technically_ RUSTC_BOOTSTRAP is an implementation detail, but it's been used so much it seems like this counts as a language change too.

r? `@joshtriplett`
cc `@Mark-Simulacrum` `@hsivonen`
Add `--color` support to bootstrap

When running under external utilities which wrap x.py, it can be convenient to force color support on.
cleanup: Remove `ParseSess::injected_crate_name`

Its only remaining use is in pretty-printing where the necessary information can be easily re-computed.
Make `_` an expression, to discard values in destructuring assignments

This is the third and final step towards implementing destructuring assignment (RFC: rust-lang/rfcs#2909, tracking issue: #71126). This PR is the third and final part of #71156, which was split up to allow for easier review.

With this PR, an underscore `_` is parsed as an expression but is allowed *only* on the left-hand side of a destructuring assignment. There it simply discards a value, similarly to the wildcard `_` in patterns. For instance,
```rust
(a, _) = (1, 2)
```
will simply assign 1 to `a` and discard the 2. Note that for consistency,
```
_ = foo
```
is also allowed and equivalent to just `foo`.

Thanks to ````@varkor```` who helped with the implementation, particularly around pre-expansion gating.

r? ````@petrochenkov````
astconv: extract closures into a separate trait

Am currently looking into completely removing `check_generic_arg_count` and `create_substs_for_generic_args` was somewhat difficult to understand for me so I moved these closures into a trait.

This should not have changed the behavior of any of these methods
Implement BTreeMap::retain and BTreeSet::retain

Adds new methods `BTreeMap::retain` and `BTreeSet::retain`.  These are implemented on top of `drain_filter` (#70530).

The API of these methods is identical to `HashMap::retain` and `HashSet::retain`, which were implemented in #39560 and stabilized in #36648.  The docs and tests are also copied from HashMap/HashSet.

The new methods are unstable, behind the `btree_retain` feature gate, with tracking issue #79025.  See also rust-lang/rfcs#1338.
…ievink

Validate that locals have a corresponding `LocalDecl`

Fixes #73356.
rustc_resolve: Make `macro_rules` scope chain compression lazy

As suggested in #78826 (comment).
Move Steal to rustc_data_structures.
Rename clean::{ItemEnum -> ItemKind}, clean::Item::{inner -> kind}

r? ````@petrochenkov````
cc ````@GuillaumeGomez````

Follow-up to #77820 (comment).
Move likely/unlikely argument outside of invisible unsafe block

The previous `likely!`/`unlikely!` macros were unsound because it permits the caller's expr to contain arbitrary unsafe code.

```rust
pub fn huh() -> bool {
    likely!(std::ptr::read(&() as *const () as *const bool))
}
```

**Before:** compiles cleanly.
**After:**

```console
error[E0133]: call to unsafe function is unsafe and requires unsafe function or block
   |
70 |     likely!(std::ptr::read(&() as *const () as *const bool))
   |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ call to unsafe function
   |
   = note: consult the function's documentation for information on how to avoid undefined behavior
```
Print 'checking cranelift artifacts' to easily separate it from other artifacts

Before:

```
Checking rustdoc artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Checking rustdoc v0.0.0 (/home/joshua/rustc/src/librustdoc)
    Checking rustdoc-tool v0.0.0 (/home/joshua/rustc/src/tools/rustdoc)
    Finished release [optimized] target(s) in 2.08s
    Checking regalloc v0.0.31
    Checking gimli v0.22.0
    Checking object v0.21.1
    Checking cranelift-codegen v0.67.0 (https://github.com/bytecodealliance/wasmtime/?branch=main#44cbdece)
    Checking cranelift-module v0.67.0 (https://github.com/bytecodealliance/wasmtime/?branch=main#44cbdece)
    Checking cranelift-native v0.67.0 (https://github.com/bytecodealliance/wasmtime/?branch=main#44cbdece)
    Checking cranelift-frontend v0.67.0 (https://github.com/bytecodealliance/wasmtime/?branch=main#44cbdece)
    Checking cranelift-object v0.67.0 (https://github.com/bytecodealliance/wasmtime/?branch=main#44cbdece)
    Checking cranelift-simplejit v0.67.0 (https://github.com/bytecodealliance/wasmtime/?branch=main#44cbdece)
    Checking rustc_codegen_cranelift v0.1.0 (/home/joshua/rustc/compiler/rustc_codegen_cranelift)
    Finished release [optimized] target(s) in 10.55s

```

After:

```
Checking rustdoc artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Checking rustdoc v0.0.0 (/home/joshua/rustc/src/librustdoc)
    Checking rustdoc-tool v0.0.0 (/home/joshua/rustc/src/tools/rustdoc)
    Finished release [optimized] target(s) in 2.08s
Checking cranelift artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Checking cranelift-codegen v0.67.0 (https://github.com/bytecodealliance/wasmtime/?branch=main#44cbdece)
```

r? `@bjorn3`
`@bors` delegate=bjorn3
@rustbot rustbot added the rollup A PR which is a rollup label Nov 15, 2020
@jonas-schievink
Copy link
Contributor Author

@bors r+ rollup=never p=13

@rustbot modify labels: rollup

@bors
Copy link
Collaborator

bors commented Nov 15, 2020

📌 Commit 568354f 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 15, 2020
@bors
Copy link
Collaborator

bors commented Nov 15, 2020

⌛ Testing commit 568354f with merge 5fab31e...

@bors
Copy link
Collaborator

bors commented Nov 15, 2020

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

# for free to join this conversation on GitHub. Already have an account? # 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.