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 5 pull requests #87423

Closed

Conversation

LeSeulArtichaut
Copy link
Contributor

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

Aaron1011 and others added 11 commits July 19, 2021 17:49
These attributes are currently discarded.
This may change in the future (see rust-lang#63221), but for now,
placing inert attributes on a macro invocation does nothing,
so we should warn users about it.

Technically, it's possible for there to be attribute macro
on the same macro invocation (or at a higher scope), which
inspects the inert attribute. For example:

```rust
#[look_for_inline_attr]
#[inline]
my_macro!()

#[look_for_nested_inline]
mod foo { #[inline] my_macro!() }
```

However, this would be a very strange thing to do.
Anyone running into this can manually suppress the warning.
The function parameters were renamed, but the documentation wasn't.
…stics

Previously, this would change the test output when RUSTUP_HOME was set:

```
---- [ui] ui/issues/issue-49851/compiler-builtins-error.rs stdout ----
diff of stderr:

1       error[E0463]: can't find crate for `core`
2          |
3          = note: the `thumbv7em-none-eabihf` target may not be installed
+          = help: consider downloading the target with `rustup target add thumbv7em-none-eabihf`
4
5       error: aborting due to previous error
6
```

Originally, I fixed it by explicitly unsetting RUSTUP_HOME in
compiletest. Then I realized that almost no one has RUSTUP_HOME set,
since rustup doesn't set it itself; although it does set RUST_RECURSION_COUNT
whenever it launches a proxy. Then it was pointed out that this runtime
check doesn't really make sense and it's fine to make it unconditional.
Warn on inert attributes used on bang macro invocation

These attributes are currently discarded.
This may change in the future (see rust-lang#63221), but for now,
placing inert attributes on a macro invocation does nothing,
so we should warn users about it.

Technically, it's possible for there to be attribute macro
on the same macro invocation (or at a higher scope), which
inspects the inert attribute. For example:

```rust
#[look_for_inline_attr]
#[inline]
my_macro!()

#[look_for_nested_inline]
mod foo { #[inline] my_macro!() }
```

However, this would be a very strange thing to do.
Anyone running into this can manually suppress the warning.
Remove detection of rustup and cargo in 'missing extern crate' diagnostics

Previously, this would change the test output when RUSTUP_HOME was set:

```
---- [ui] ui/issues/issue-49851/compiler-builtins-error.rs stdout ----
diff of stderr:

1       error[E0463]: can't find crate for `core`
2          |
3          = note: the `thumbv7em-none-eabihf` target may not be installed
+          = help: consider downloading the target with `rustup target add thumbv7em-none-eabihf`
4
5       error: aborting due to previous error
6
```

Originally, I fixed it by explicitly unsetting RUSTUP_HOME in
compiletest. Then I realized that almost no one has RUSTUP_HOME set,
since rustup doesn't set it itself. It does set RUST_RECURSION_COUNT
whenever it launches a proxy, though - use that instead.

r? `@estebank` cc `@petrochenkov` `@kinnison`
Clear up std::env::set_var panic section.

The "K" parameter was being referred to as "key", which wasn't
introduced anywhere.
…on, r=oli-obk

Implement `AssignToDroppingUnionField` in THIR unsafeck

r? `@oli-obk` cc rust-lang/project-thir-unsafeck#7
… r=LeSeulArtichaut

DOC: remove unnecessary feature crate attribute from example code

I'm not sure whether I fully understand the stabilization process (I most likely don't), but I think this attribute isn't necessary here, right?

This was recently stabilized in rust-lang#86344.
@rustbot rustbot added the rollup A PR which is a rollup label Jul 24, 2021
@LeSeulArtichaut LeSeulArtichaut deleted the rollup-2n5gsec branch July 24, 2021 11:03
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
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants