Rollup of 8 pull requests #78350
Merged
Rollup of 8 pull requests #78350
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
allow_internal_unstable is currently used to side-step feature gate and stability checks. While it was originally only meant to be used only on macros, its use was expanded to const functions. This commit prepares stricter checks for the usage of allow_internal_unstable (only on macros) and introduces the rustc_allow_const_fn_unstable attribute for usage on functions. See rust-lang#69399
Adds a check to make sure `#[allow_internal_unstable]` can be applied only to macro definitions.
Adds a check to make sure `#[rustc_allow_const_fn_unstable]` can be applied only to functions.
Recognition for `rustc_allow_const_fn_unstable` attribute was errorneously added in 05f4a9a.
…n rustc_mir Followup rename from 05f4a9a, which introduced `#[rustc_allow_const_fn_unstable]` for `const fn`s.
The validation was introduced in 3a63bf0 without strict validation of functions, e. g. all function types were allowed. Now the validation only allows `const fn`s.
…et docs The `xargo` tool is in maintenance mode since 2018 and the `build-std` feature of cargo already works reasonably well for most use cases.
Co-authored-by: Jonas Schievink <[email protected]>
When the 'early' and 'late' visitors visit an attribute target, they
activate any lint attributes (e.g. `#[allow]`) that apply to it.
This can affect warnings emitted on sibiling attributes. For example,
the following code does not produce an `unused_attributes` for
`#[inline]`, since the sibiling `#[allow(unused_attributes)]` suppressed
the warning.
```rust
trait Foo {
#[allow(unused_attributes)] #[inline] fn first();
#[inline] #[allow(unused_attributes)] fn second();
}
```
However, we do not do this for statements - instead, the lint attributes
only become active when we visit the struct nested inside `StmtKind`
(e.g. `Item`).
Currently, this is difficult to observe due to another issue - the
`HasAttrs` impl for `StmtKind` ignores attributes for `StmtKind::Item`.
As a result, the `unused_doc_comments` lint will never see attributes on
item statements.
This commit makes two interrelated fixes to the handling of inert
(non-proc-macro) attributes on statements:
* The `HasAttr` impl for `StmtKind` now returns attributes for
`StmtKind::Item`, treating it just like every other `StmtKind`
variant. The only place relying on the old behavior was macro
which has been updated to explicitly ignore attributes on item
statements. This allows the `unused_doc_comments` lint to fire for
item statements.
* The `early` and `late` lint visitors now activate lint attributes when
invoking the callback for `Stmt`. This ensures that a lint
attribute (e.g. `#[allow(unused_doc_comments)]`) can be applied to
sibiling attributes on an item statement.
For now, the `unused_doc_comments` lint is explicitly disabled on item
statements, which preserves the current behavior. The exact locatiosn
where this lint should fire are being discussed in PR rust-lang#78306
Fixes rust-lang#75982 The direct parent of a module may not be a module (e.g. `const _: () = { #[path = "foo.rs"] mod foo; };`). To find the parent of a module for purposes of resolution, we need to walk up the tree until we hit a module or a crate root.
…t, r=petrochenkov Compute proper module parent during resolution Fixes rust-lang#75982 The direct parent of a module may not be a module (e.g. `const _: () = { #[path = "foo.rs"] mod foo; };`). To find the parent of a module for purposes of resolution, we need to walk up the tree until we hit a module or a crate root.
…nt, r=oli-obk MIR validation should check `SwitchInt` values are valid for the type Fixes rust-lang#75440
replace `#[allow_internal_unstable]` with `#[rustc_allow_const_fn_unstable]` for `const fn`s `#[allow_internal_unstable]` is currently used to side-step feature gate and stability checks. While it was originally only meant to be used only on macros, its use was expanded to `const fn`s. This pr adds stricter checks for the usage of `#[allow_internal_unstable]` (only on macros) and introduces the `#[rustc_allow_const_fn_unstable]` attribute for usage on `const fn`s. This pr does not change any of the functionality associated with the use of `#[allow_internal_unstable]` on macros or the usage of `#[rustc_allow_const_fn_unstable]` (instead of `#[allow_internal_unstable]`) on `const fn`s (see rust-lang#69399 (comment)). Note: The check for `#[rustc_allow_const_fn_unstable]` currently only validates that the attribute is used on a function, because I don't know how I would check if the function is a `const fn` at the place of the check. I therefore openend this as a 'draft pull request'. Closes rust-lang#69399 r? @oli-obk
Update `compiler_builtins` to 0.1.36
So, the libc build with cargo's `build-std` feature emits a lot of warnings like:
```
warning: a method with this name may be added to the standard library in the future
--> /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.35/src/int/udiv.rs:98:23
|
98 | q = n << (<$ty>::BITS - sr);
| ^^^^^^^^^^^
...
268 | udivmod_inner!(n, d, rem, u128)
| ------------------------------- in this macro invocation
|
= warning: once this method is added to the standard library, the ambiguity may cause an error or change in behavior!
= note: for more information, see issue rust-lang#48919 <rust-lang/issues/48919>
= help: call with fully qualified syntax `Int::BITS(...)` to keep using the current method
= help: add `#![feature(int_bits_const)]` to the crate attributes to enable `num::<impl u128>::BITS`
= note: this warning originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)
```
(You can find the full log in https://github.com/rust-lang/libc/runs/1283695796?check_suite_focus=true for example.)
0.1.36 contains rust-lang/compiler-builtins#332 so this version should remove this warning.
cc rust-lang/libc#1942
Bump backtrace-rs to enable Mach-O support on iOS. Related to rust-lang/backtrace-rs#378. Fixes backtraces on iOS that were missing in Rust v1.47.0 after switching to gimli because it only enabled Mach-O support on macOS.
…alexcrichton Link to cargo's `build-std` feature instead of `xargo` in custom target docs The `xargo` tool is in maintenance mode since 2018 and the `build-std` feature of cargo already works reasonably well for most use cases.
…vel, r=Mark-Simulacrum BTreeMap: stop mistaking node::MIN_LEN for a node level constraint Correcting rust-lang#77612 that fell into the trap of assuming that node::MIN_LEN is an imposed minimum everywhere, and trying to make it much more clear it is an offered minimum at the node level. r? @Mark-Simulacrum
…rochenkov Split out statement attributes changes from rust-lang#78306 This is the same as PR rust-lang#78306, but `unused_doc_comments` is modified to explicitly ignore statement items (which preserves the current behavior). This shouldn't have any user-visible effects, so it can be landed without lang team discussion. --------- When the 'early' and 'late' visitors visit an attribute target, they activate any lint attributes (e.g. `#[allow]`) that apply to it. This can affect warnings emitted on sibiling attributes. For example, the following code does not produce an `unused_attributes` for `#[inline]`, since the sibiling `#[allow(unused_attributes)]` suppressed the warning. ```rust trait Foo { #[allow(unused_attributes)] #[inline] fn first(); #[inline] #[allow(unused_attributes)] fn second(); } ``` However, we do not do this for statements - instead, the lint attributes only become active when we visit the struct nested inside `StmtKind` (e.g. `Item`). Currently, this is difficult to observe due to another issue - the `HasAttrs` impl for `StmtKind` ignores attributes for `StmtKind::Item`. As a result, the `unused_doc_comments` lint will never see attributes on item statements. This commit makes two interrelated fixes to the handling of inert (non-proc-macro) attributes on statements: * The `HasAttr` impl for `StmtKind` now returns attributes for `StmtKind::Item`, treating it just like every other `StmtKind` variant. The only place relying on the old behavior was macro which has been updated to explicitly ignore attributes on item statements. This allows the `unused_doc_comments` lint to fire for item statements. * The `early` and `late` lint visitors now activate lint attributes when invoking the callback for `Stmt`. This ensures that a lint attribute (e.g. `#[allow(unused_doc_comments)]`) can be applied to sibiling attributes on an item statement. For now, the `unused_doc_comments` lint is explicitly disabled on item statements, which preserves the current behavior. The exact locatiosn where this lint should fire are being discussed in PR rust-lang#78306
|
📌 Commit 0a26e4b has been approved by |
bors
added
the
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
This was referenced Oct 25, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
SwitchIntvalues are valid for the type #78085 (MIR validation should checkSwitchIntvalues are valid for the type)#[allow_internal_unstable]with#[rustc_allow_const_fn_unstable]forconst fns #78208 (replace#[allow_internal_unstable]with#[rustc_allow_const_fn_unstable]forconst fns)compiler_builtinsto 0.1.36 #78209 (Updatecompiler_builtinsto 0.1.36)build-stdfeature instead ofxargoin custom target docs #78320 (Link to cargo'sbuild-stdfeature instead ofxargoin custom target docs)Failed merges:
r? @ghost