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 13 pull requests #79070

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`.
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
Contributor

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
Contributor

bors commented Nov 15, 2020

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

@bors
Copy link
Contributor

bors commented Nov 15, 2020

☀️ Test successful - checks-actions
Approved by: jonas-schievink
Pushing 5fab31e 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.