add lint for inline asm labels that look like binary
fixes#94426
Due to a bug/feature in LLVM, labels composed of only the digits `0` and `1` can sometimes be confused with binary literals, even if a binary literal would not be valid in that position.
This PR adds detection for such labels and also as a drive-by change, adds a note to cases such as `asm!(include_str!("file"))` that the label that it found came from an expansion of a macro, it wasn't found in the source code.
I expect this PR to upset some people that were using labels `0:` or `1:` without issue because they never hit the case where LLVM got it wrong, but adding a heuristic to the lint to prevent this is not feasible - it would involve writing a whole assembly parser for every target that we have assembly support for.
[zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bweekly.5D.202024-06-20/near/445870628)
r? ``@estebank``
Implement simple, unstable lint to suggest turning closure-of-async-block into async-closure
We want to eventually suggest people to turn `|| async {}` to `async || {}`. This begins doing that. It's a pretty rudimentary lint, but I wanted to get something down so I wouldn't lose the code.
Tracking:
* #62290
Update `f16`/`f128` FIXMEs that needed `(NEG_)INFINITY`
Just a small fix to the pattern matching tests now that we can. Also contains a small unrelated comment tweak.
This is adding a migration lint for the current (in the 2021 edition and previous)
to move expr to expr_2021 from expr
Co-Developed-by: Eric Holk
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
Improve well known value check-cfg diagnostic for the standard library
This PR adjust the current logic for hidding the rustc/Cargo suggestion to add a value to a well-known name to exclude the standard library and rustc crates.
This is done in order to improve the contributor experience, in particular when adding a new target, which often requires adding some cfgs like `target_os` which may not be available yet in stage0.
<details>
The diagnostic code would look like this.
```text
error: unexpected `cfg` condition value: `blable`
--> library/core/src/lib.rs:369:7
|
369 | #[cfg(target_os = "blable")]
| ^^^^^^^^^^^^^^^^^^^^
|
= note: expected values for `target_os` are: `aix`, `android`, `cuda`, `dragonfly`, `emscripten`, `espidf`, `freebsd`, `fuchsia`, `haiku`, `hermit`, `horizon`, `hurd`, `illumos`, `ios`, `l4re`, `linux`, `macos`, `netbsd`, `none`, `nto`, `openbsd`, `psp`, `redox`, `solaris`, `solid_asp3`, `teeos`, `tvos`, `uefi`, `unknown`, `visionos`, `vita`, `vxworks`, `wasi`, `watchos`, and `windows` and 2 more
= help: consider using a Cargo feature instead
= help: or consider adding in `Cargo.toml` the `check-cfg` lint config for the lint:
[lints.rust]
unexpected_cfgs = { level = "warn", check-cfg = ['cfg(target_os, values("blable"))'] }
= help: or consider adding `println!("cargo::rustc-check-cfg=cfg(target_os, values(\"blable\"))");` to the top of the `build.rs`
= note: see <https://doc.rust-lang.org/nightly/rustc/check-cfg/cargo-specifics.html> for more information about checking conditional configuration
= note: `-D unexpected-cfgs` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(unexpected_cfgs)]`
```
</details>
Remove the `box_pointers` lint.
As the comment says, this lint "is mostly historical, and not particularly useful". It's not worth keeping it around.
r? ``@estebank``
Rename `super_predicates_of` and similar queries to `explicit_*` to note that they're not elaborated
Rename:
* `super_predicates_of` -> `explicit_super_predicates_of`
* `implied_predicates_of` -> `explicit_implied_predicates_of`
* `supertraits_containing_assoc_item` -> `explicit_supertraits_containing_assoc_item`
This makes it clearer that, unlike (for example) [`TyCtxt::super_traits_of`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.super_traits_of), we don't automatically elaborate this set of predicates.
r? ``@lcnr`` or ``@oli-obk`` or someone from t-types idc
Switch back `non_local_definitions` lint to allow-by-default
This PR switch back (again) the `non_local_definitions` lint to allow-by-default as T-lang is requesting some (major) changes in the lint inner workings in https://github.com/rust-lang/rust/issues/126768#issuecomment-2192634762.
This PR will need to be beta-backported, as the lint is currently warn-by-default in beta.
ast: Standardize visiting order for attributes and node IDs
This should only affect `macro_rules` scopes and order of diagnostics.
Also add a deprecation lint for `macro_rules` called outside of their scope, like in https://github.com/rust-lang/rust/issues/124535.
Suggest using a standalone doctest for non-local impl defs
This PR tweaks the lint output of the `non_local_definitions` lint to suggest using a standalone doctest instead of a moving the `impl` def to an impossible place as was already done with `macro_rules!` case in https://github.com/rust-lang/rust/pull/124568.
Fixes#126339
r? ```@fmease```
Resolve elided lifetimes in assoc const to static if no other lifetimes are in scope
Implements the change to elided lifetime resolution in *associated consts* subject to FCP here: https://github.com/rust-lang/rust/issues/125190#issue-2301532282
Specifically, walk the enclosing lifetime ribs in an associated const, and if we find no other lifetimes, then resolve to `'static`.
Also make it work for traits, but don't lint -- just give a hard error in that case.
Rollup of 16 pull requests
Successful merges:
- #123374 (DOC: Add FFI example for slice::from_raw_parts())
- #124514 (Recommend to never display zero disambiguators when demangling v0 symbols)
- #125978 (Cleanup: HIR ty lowering: Consolidate the places that do assoc item probing & access checking)
- #125980 (Nvptx remove direct passmode)
- #126187 (For E0277 suggest adding `Result` return type for function when using QuestionMark `?` in the body.)
- #126210 (docs(core): make more const_ptr doctests assert instead of printing)
- #126249 (Simplify `[T; N]::try_map` signature)
- #126256 (Add {{target}} substitution to compiletest)
- #126263 (Make issue-122805.rs big endian compatible)
- #126281 (set_env: State the conclusion upfront)
- #126286 (Make `storage-live.rs` robust against rustc internal changes.)
- #126287 (Update a cranelift patch file for formatting changes.)
- #126301 (Use `tidy` to sort crate attributes for all compiler crates.)
- #126305 (Make PathBuf less Ok with adding UTF-16 then `into_string`)
- #126310 (Migrate run make prefer rlib)
- #126314 (fix RELEASES: we do not support upcasting to auto traits)
r? `@ghost`
`@rustbot` modify labels: rollup
We already do this for a number of crates, e.g. `rustc_middle`,
`rustc_span`, `rustc_metadata`, `rustc_span`, `rustc_errors`.
For the ones we don't, in many cases the attributes are a mess.
- There is no consistency about order of attribute kinds (e.g.
`allow`/`deny`/`feature`).
- Within attribute kind groups (e.g. the `feature` attributes),
sometimes the order is alphabetical, and sometimes there is no
particular order.
- Sometimes the attributes of a particular kind aren't even grouped
all together, e.g. there might be a `feature`, then an `allow`, then
another `feature`.
This commit extends the existing sorting to all compiler crates,
increasing consistency. If any new attribute line is added there is now
only one place it can go -- no need for arbitrary decisions.
Exceptions:
- `rustc_log`, `rustc_next_trait_solver` and `rustc_type_ir_macros`,
because they have no crate attributes.
- `rustc_codegen_gcc`, because it's quasi-external to rustc (e.g. it's
ignored in `rustfmt.toml`).
