Fix ICE in `span_extend_prev_while` with multibyte characters
Fixes https://github.com/rust-lang/rust/issues/155037
The function assumed that the character found by `rfind` was always one byte wide, using a hardcoded `1` instead of `c.len_utf8()`. When a multibyte character appeared immediately before the span, this caused the resulting span to point into the middle of a UTF-8 sequence, triggering an assertion failure in `bytepos_to_file_charpos`.
Hexagon: add scalar arch-version target features (v60-v79, audio)
Add target features corresponding to Hexagon LLVM CPU generations to complement the existing HVX vector features. These are needed for gating scalar intrinsics by architecture version.
New features: audio, v60, v62, v65, v66, v67, v68, v69, v71, v73, v75, v79
Each version implies the previous (e.g. v68 implies v67 which implies v66, etc.), matching LLVM's ArchV60-ArchV79 subtarget features.
Also adds hexagon revisions to the feature-hierarchy test to verify the implied feature chains work correctly.
Fix ICE when reporting host-effect errors for const Fn HRTBs in next trait solver
Avoid leaking bound vars into the diagnostic selection path for HRTB host-effect predicates.
Closesrust-lang/rust#151894 .
Deprioritize doc(hidden) re-exports in diagnostic paths
Fixesrust-lang/rust#153477.
This is the other half of rust-lang/rust#99698, which fixed the case where the *parent module* is `#[doc(hidden)]` but left the case where the re-export itself is `#[doc(hidden)]` as a FIXME (with a tracking test in `dont-suggest-doc-hidden-variant-for-enum/hidden-child.rs`).
The problem: when a crate does `#[doc(hidden)] pub use core::error::Error`, diagnostics pick up the hidden re-export path instead of the canonical one. For example, `snafu::Error` instead of `std::error::Error`.
Two changes:
In `visible_parent_map`, the `add_child` closure now checks whether the re-export itself is `#[doc(hidden)]` via `reexport_chain` and sends it to `fallback_map`, same treatment as doc-hidden parents and underscore re-exports.
`should_encode_attrs` now returns `true` for `DefKind::Use`. Without this, `#[doc(hidden)]` on `use` items was never written to crate metadata, so `is_doc_hidden` always returned `false` cross-crate. This was the actual root cause, the check in `visible_parent_map` alone isn't enough if the attribute isn't in the metadata.
The existing FIXME test now serves as the regression test. The `.stderr` goes from suggesting `hidden_child::__private::Some(1i32)` to just `Some(1i32)`.
cc @eggyal
add `cfg(target_object_format = "...")`
tracking issue: https://github.com/rust-lang/rust/issues/152586
I'm implementing the predicate as `target_object_format`, because that's what is useful to me (for testing `#[link_section = "..."]` where `mach-o` has some extra restrictions) and maps cleanly to the `BinaryFormat` enum that is used internally. There is still room for a future `target_executable_format` when there is a use case.
cc @joshtriplett as the lang sponsor of this feature, @workingjubilee as the author of the proposal.
r? JonathanBrouwer a sidequest from the sidequest that is https://github.com/rust-lang/rust/pull/155065
Rollup of 3 pull requests
Successful merges:
- rust-lang/rust#154827 (distinguish "expected a single argument" and "expected an argument" on attribute parsing)
- rust-lang/rust#155104 (bootstrap: auto-patch libgccjit.so for NixOS)
- rust-lang/rust#155120 (Use a linting node closer the parsing of `#[cfg_attr]`)
Use a linting node closer the parsing of `#[cfg_attr]`
The parsing of `#[cfg_attr]` unconditionally used the crate-root as a linting node to attach lints, but the `unexpected_cfgs` lint can fire when parsing the attribute and users expect to be able to allow it at places other than the crate-root.
Let's instead use the linting node id, which is unfortunately always the parent but that's better than the crate-root when you are in a sub-module.
The parsing of `#[cfg]` and other already use the expansion linting node id, so no change required there.
Related to https://github.com/rust-lang/rust/issues/155118
Suggest similar target names on unrecognized `--target`
When an unrecognized `--target` is passed check the list of available targets and suggest the closest matching built-in target as a help message.
### Before
```
error: error loading target specification: could not find specification for target "x86_64-linux-gnu"
= help: run `rustc --print target-list` for a list of built-in targets
```
### After
```
error: error loading target specification: could not find specification for target "x86_64-linux-gnu"
= help: run `rustc --print target-list` for a list of built-in targets
= help: did you mean `x86_64-unknown-linux-gnu`?
```
Regarding the expected test case in https://github.com/rust-lang/rust/issues/155085#issuecomment-4222050023 the `edit_distance_with_substrings` was used over `edit_distance` because in the case of `x86_64-linux-gnu` the `edit_distance` would return `x86_64-linux-android` instead of `x86_64-unknown-linux-gnu`
rust-lang/rust#155085
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#152901 (Introduce a `#[diagnostic::on_unknown]` attribute)
- rust-lang/rust#155078 (Reject dangling attributes in where clauses)
- rust-lang/rust#154449 (Invert dependency between `rustc_errors` and `rustc_abi`.)
- rust-lang/rust#154646 (Add suggestion to `.to_owned()` used on `Cow` when borrowing)
- rust-lang/rust#154993 (compiletest: pass -Zunstable-options for unpretty and no-codegen paths)
- rust-lang/rust#155097 (Make `rustc_attr_parsing::SharedContext::emit_lint` take a `MultiSpan` instead of a `Span`)
Add suggestion to `.to_owned()` used on `Cow` when borrowing
fixesrust-lang/rust#144792
supersedes rust-lang/rust#144925 with the review comments addressed
the tests suggested from @Kivooeo from https://github.com/rust-lang/rust/pull/144925#discussion_r2252703007 didn't work entirely, because these tests failed due to error `[E0308]` mismatched types, which actually already provides a suggestion, that actually makes the code compile:
```
$ cargo check
error[E0308]: mismatched types
--> src/main.rs:3:5
|
1 | fn test_cow_suggestion() -> String {
| ------ expected `std::string::String` because of return type
2 | let os_string = std::ffi::OsString::from("test");
3 | os_string.to_string_lossy().to_owned()
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `String`, found `Cow<'_, str>`
|
= note: expected struct `std::string::String`
found enum `std::borrow::Cow<'_, str>`
help: try using a conversion method
|
3 | os_string.to_string_lossy().to_owned().to_string()
| ++++++++++++
```
now this suggestion is of course not good or efficient code, but via clippy with `-Wclippy::nursery` lint group you can actually get to the correct code, so i don't think this is too much of an issue:
<details>
<summary>the clippy suggestions</summary>
```
$ cargo clippy -- -Wclippy::nursery
warning: this `to_owned` call clones the `Cow<'_, str>` itself and does not cause its contents to become owned
--> src/main.rs:3:5
|
3 | os_string.to_string_lossy().to_owned().to_string()
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/beta/index.html#suspicious_to_owned
= note: `#[warn(clippy::suspicious_to_owned)]` on by default
help: depending on intent, either make the `Cow` an `Owned` variant
|
3 | os_string.to_string_lossy().into_owned().to_string()
| ++
help: or clone the `Cow` itself
|
3 - os_string.to_string_lossy().to_owned().to_string()
3 + os_string.to_string_lossy().clone().to_string()
|
$ # apply first suggestion
$ cargo c -- -Wclippy::nursery
warning: redundant clone
--> src/main.rs:3:45
|
3 | os_string.to_string_lossy().into_owned().to_string()
| ^^^^^^^^^^^^ help: remove this
|
note: this value is dropped without further use
--> src/main.rs:3:5
|
3 | os_string.to_string_lossy().into_owned().to_string()
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
= help: for further information visit https://rust-lang.github.io/rust-clippy/beta/index.html#redundant_clone
= note: `-W clippy::redundant-clone` implied by `-W clippy::nursery`
= help: to override `-W clippy::nursery` add `#[allow(clippy::redundant_clone)]`
```
</details>
the actual error that we are looking for is error `[E0515]`, cannot return value referencing local variable, which was only present in the original issue due to automatic type inference assuming you want to return a cloned `Cow<'_, str>`, which is of course not possible. this is why i took the original test functions and turned them into closures, where it's less obvious that it's trying to return the wrong type.
r? davidtwco
(because you reviewed the last attempt)
(also, let me know if i should squash this down to one commit and add myself as the co-contributor)
Reject dangling attributes in where clauses
Report `attribute without where predicates` for trailing outer attributes in where clauses.
Closesrust-lang/rust#155073 .
Introduce a `#[diagnostic::on_unknown]` attribute
This PR introduces a `#[diagnostic::on_unknown]` attribute that allows crate authors to customize the error messages emitted by unresolved imports. The main usecase for this is using this attribute as part of a proc macro that expects a certain external module structure to exist or certain dependencies to be there.
For me personally the motivating use-case are several derives in diesel, that expect to refer to a `tabe` module. That is done either implicitly (via the name of the type with the derive) or explicitly by the user. This attribute would allow us to improve the error message in both cases:
* For the implicit case we could explicity call out our assumptions (turning the name into lower case, adding an `s` in the end)
+ point to the explicit variant as alternative
* For the explicit variant we would add additional notes to tell the user why this is happening and what they should look for to fix the problem (be more explicit about certain diesel specific assumptions of the module structure)
I assume that similar use-cases exist for other proc-macros as well, therefore I decided to put in the work implementing this new attribute. I would also assume that this is likely not useful for std-lib internal usage.
related rust-lang/rust#152900 and rust-lang/rust#128674
delegation: fix unelided lifetime ICE, refactoring of GenericArgPosition
This PR does two things:
- First it restores `lower_generic_args_of_path` as it was before rust-lang/rust#151864, as it turns out we should use `GenericArgPosition::Type` for generic args lowering for signature inheritance, as it will not cause lifetime inference and then ICEs during child args lowering,
- Next it refactors `GenericArgPosition` enum replacing `Value` and `MethodCall` with `Call(IsMethodCall)`, as the only place where we created `Value` or `MethodCall` variants was in `check_generic_arg_count_for_call`, where it was a match over `is_method_call`. Not sure it is needed, but seems cleaner to me.
Fixesrust-lang/rust#154178, part of rust-lang/rust#118212.
r? @petrochenkov
Fix `pattern_from_macro_note` for bit-or expr
This is a continuation of issue https://github.com/rust-lang/rust/issues/99380 (and pr https://github.com/rust-lang/rust/pull/124488) but covers bit-or pattern.
Essentially a `pat1 | pat2`, or any bit-or pattern used in a `$e:expr` was not firing the `.pattern_from_macro_note` diagnostic bc `ast::Expr::is_approximately_pattern()` did not cover bit-or.
The cover for bit-or is only added in `lower_expr_within_pat()`, otherwise doing it in `is_approximately_pattern()` would result in the suggestion `if (i + 2) = 2 => if let (i + 2) = 2` from `suggest_pattern_match_with_let()` (which is the only other place `ast::Expr::is_approximately_pattern()` is used from what i see).
resolves https://github.com/rust-lang/rust/issues/99380
refs https://github.com/rust-lang/rust/pull/124488
Fix ICE when combining #[eii] with #[core::contracts::ensures]
Fixesrust-lang/rust#153745
Builtin attribute macros like #[eii] generate AST items programmatically without collected tokens. When another attribute macro was present on the same item, the compiler would panic in TokenStream::from_ast() trying to tokenize the generated items during subsequent attribute expansion.
Generate fake token streams (via pretty-print and re-parse) for Item and ForeignItem nodes that lack collected tokens, following the existing pattern used for Crate and out-of-line modules.
Restrict EII declarations to functions at lowering time
We tighten EII declaration resolution so that `lower_path_simple_eii` only accepts function‑like items (`Fn, AssocFn, Ctor(_, Fn)`) as valid EII targets. If name resolution points at something else (like a const with the same name), we now emit a direct error (“`externally implementable items must refer to a function`”) at the declaration site, which prevents bad `DefIds` from ever reaching `compare_eii_function_types` and turning into an ICE
this is more robust and root-cause oriented fix to rust-lang/rust#152337 issue and an alternate of my more simple PR rust-lang/rust#152365
test included
Always exhaustively match on typing mode
r? @lcnr
Unimplements Eq/PartialEq for TypingMode, adds TypingModeEqWrapper for the few cases where we need it (mainly in the query system), and adds a new rustc internal lint to detect cases where we non-exhaustively match on typing mode.
Moreover, dereference `ty_layout.align` for `#[rustc_dump_layout(align)]`
to render `align: Align($N bytes)` instead of `align: AbiAlign { abi: Align($N bytes) }`
which contains the same amount of information but it more concise and legible.
This PR introduces a `#[diagnostic::on_unknown_item]` attribute that
allows crate authors to customize the error messages emitted by
unresolved imports. The main usecase for this is using this attribute as
part of a proc macro that expects a certain external module structure to
exist or certain dependencies to be there.
For me personally the motivating use-case are several derives in diesel,
that expect to refer to a `tabe` module. That is done either
implicitly (via the name of the type with the derive) or explicitly by
the user. This attribute would allow us to improve the error message in
both cases:
* For the implicit case we could explicity call out our
assumptions (turning the name into lower case, adding an `s` in the end)
+ point to the explicit variant as alternative
* For the explicit variant we would add additional notes to tell the
user why this is happening and what they should look for to fix the
problem (be more explicit about certain diesel specific assumptions of
the module structure)
I assume that similar use-cases exist for other proc-macros as well,
therefore I decided to put in the work implementing this new attribute.
I would also assume that this is likely not useful for std-lib internal
usage.
Deny `#[global_allocator]` + `#[thread_local]`
This forbids using `#[thread_local]` on `static` items that are also `#[global_allocator]`s.
Fixesrust-lang/rust#85517.
Jonathan Brouwer