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 26 pull requests #79053

Closed
wants to merge 74 commits into from
Closed

Rollup of 26 pull requests #79053

wants to merge 74 commits into from

Conversation

jonas-schievink
Copy link
Contributor

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

JohnTitor and others added 30 commits October 25, 2020 20:52
Including llvm-as adds the ability to include assembly language fragments
that can be inlined using LTO.
This bumps the minimal tested llvm version to 9.
This should enable supporting newer LLVM features (and CPU extensions).
apparently llvm-8-tools already had llvm-8-dev as a dependency
which was removed in llvm-9-tools, so we need to explicitly pull
llvm-9-dev to make a build
This commit grepped for LLVM_VERSION_GE, LLVM_VERSION_LT, get_major_version and
min-llvm-version and statically evaluated every expression possible
(and sensible) assuming that the LLVM version is >=9 now
…ersion

The function was only used in LLVM 8 compatibility code
and was found and flagged by dead code detection and now removed.
as requested in the review and argued that this is only consistent with later LLVM upgrades
If the LLVM was externally provided, then we don't currently copy artifacts into
the sysroot. This is not necessarily the right choice (in particular, it will
require the LLVM dylib to be in the linker's load path at runtime), but the
common use case for external LLVMs is distribution provided LLVMs, and in that
case they're usually in the standard search path (e.g., /usr/lib) and copying
them here is going to cause problems as we may end up with the wrong files and
isn't what distributions want.

This behavior may be revisited in the future though.
This looks like it was forgotten to get updated in #74482 and wasm with
threads isn't built on CI so we didn't catch this by accident.
The inliner looks if a sanitizer is enabled before considering
`no_sanitize` attribute as possible source of incompatibility.

The MIR inlining could happen in a crate with sanitizer disabled, but
code generation in a crate with sanitizer enabled, thus the attribute
would be incorrectly ignored.

To avoid the issue never inline functions with different `no_sanitize`
attributes.
The information about cold attribute is lost during inlining,
Avoid the issue by never inlining cold functions.
The callee body is already transformed; the condition is always false.
During inlining, the callee body is normalized and has types revealed,
but some of locals corresponding to the arguments might come from the
caller body which is not. As a result the caller body does not pass
validation without additional normalization.
…andry

Added some unit tests as requested

As discussed in PR #78267, for example:

* #78267 (comment)
* #78267 (comment)

r? ````@tmandry````
FYI: ````@wesleywiser````

This is pretty much self contained, but depending on feedback and timing, I may have a chance to add a few more unit tests requested against `counters.rs`. I'm looking at those now.
Never inline C variadics, cold functions, functions with incompatible attributes ...

... and fix generator inlining.

Closes #67863.
Closes #78859.
Include llvm-as in llvm-tools-preview component

Including `llvm-as` adds the ability to include assembly language fragments that can be inlined using LTO while making sure the correct version of LLVM is always used.
Normalize function type during validation

During inlining, the callee body is normalized and has types revealed,
but some of locals corresponding to the arguments might come from the
caller body which is not. As a result the caller body does not pass
validation without additional normalization.

Closes #78442.
Fix rustc_ast_pretty print_qpath resulting in invalid macro input

related #76874 (third case)

### Issue:

The input for a procedural macro is incorrect, for the rust code:
```rust

mod m {
    pub trait Tr {
        type Ts: super::Tu;
    }
}

trait Tu {
    fn dummy() { }
}

#[may_proc_macro]
fn foo() {
    <T as m::Tr>::Ts::dummy();
}
```
the macro will get the input:
```rust
fn foo() {
    <T as m::Tr>::dummy();
}
```
Thus `Ts` has disappeared.

### Fix:

This is due to invalid pretty print of qpath. This PR fix it.
Avoid installing external LLVM dylibs

If the LLVM was externally provided, then we don't currently copy artifacts into
the sysroot. This is not necessarily the right choice (in particular, it will
require the LLVM dylib to be in the linker's load path at runtime), but the
common use case for external LLVMs is distribution provided LLVMs, and in that
case they're usually in the standard search path (e.g., /usr/lib) and copying
them here is going to cause problems as we may end up with the wrong files and
isn't what distributions want.

This behavior may be revisited in the future though.

Fixes #78932.
Fix an intrinsic invocation on threaded wasm

This looks like it was forgotten to get updated in #74482 and wasm with
threads isn't built on CI so we didn't catch this by accident.
rustc_target: Fix dash vs underscore mismatches in option names

Fixes #78981 (regression from #78875, the old option names used dashes)
Add column number support to Backtrace

Backtrace frames might include column numbers.
Print them if they are included.
rustc_expand: Mark inner `#![test]` attributes as soft-unstable

Custom inner attributes are feature gated (#54726) except for attributes having name `test` literally, which are not gated for historical reasons.

`#![test]` is an inner proc macro attribute, so it has all the issues described in #54726 too.
This PR gates it with the `soft_unstable` lint.
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.
Limit storage duration of inlined always live locals

Closes #76375.
…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).
@rustbot rustbot added the rollup A PR which is a rollup label Nov 14, 2020
@jonas-schievink
Copy link
Contributor Author

@bors r+ rollup=never p=26

@rustbot modify labels: rollup

@bors
Copy link
Contributor

bors commented Nov 14, 2020

📌 Commit 757443a 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 14, 2020
@bors
Copy link
Contributor

bors commented Nov 14, 2020

⌛ Testing commit 757443a with merge 8c7e296a364d97b3f9d14fbee1ada71074d03bf6...

@tmiasko
Copy link
Contributor

tmiasko commented Nov 14, 2020

Hmm, it looks like #79027 cannot be rolled up together with #78966.

@jonas-schievink
Copy link
Contributor Author

Yup, I'll omit one of them

@jonas-schievink jonas-schievink deleted the rollup-vb4941i branch November 14, 2020 20:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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.