The issue cannot be reproduced with the former testcase of creating external crates because
rust refuses to use "external crate 28_找出字符串中第一个匹配项的下标"
because it is not a valid indentifier (starts with number, and contain non ascii chars)
But still using 28_找出字符串中第一个匹配项的下标.rs as a filename is accepted by previous rustc releases
So we consider it valid, and add an integration test for it to catch any regression on other code related to non ascii filenames.
(cherry picked from commit c6acffeb78)
[beta-1.91] Warn on future errors from temporary lifetimes shortening in Rust 1.92
Pursuant to [discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/474880-t-compiler.2Fbackports/topic/.23145838.3A.20beta-nominated/near/540530631), this implements a future-compatibility warning lint `macro_extended_temporary_scopes` for errors in Rust 1.92 caused by rust-lang/rust#145838:
```
warning: temporary lifetime shortening in Rust 1.92
--> $DIR/macro-extended-temporary-scopes.rs:54:14
|
LL | &struct_temp().field
| ^^^^^^^^^^^^^ this expression creates a temporary value...
...
LL | } else {
| - ...which will be dropped at the end of this block in Rust 1.92
|
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see <https://doc.rust-lang.org/rustc/lints/listing/warn-by-default.html#macro-extended-temporary-scopes>
= note: consider using a `let` binding to create a longer lived value
```
Implementation-wise, this reuses the existing temporary scoping FCW machinery introduced for the `tail_expr_drop_order` edition lint: this adds `BackwardIncompatibleDropHint` statements to the MIR at the end of the shortened scopes for affected temporaries; these are then checked in borrowck to warn if the temporary is used after the future drop hint. There are trade-offs here: on one hand, I believe this gives some assurance over ad-hoc pattern-recognition that there are no false positives[^1]. On the other hand, this fails to lint on future dangling raw pointers and it complicates the potential addition of explanatory diagnostics or suggestions[^2]. I'm hopeful that the limitation around dangling pointers won't be relevant in real code, though; the only real instance we've seen of breakage so far is future errors in formatting macro invocations, which this should be able to catch.
Release logistics notes:
- This PR targets the beta branch directly, since the breakage it's a FCW for is landing in the next Rust version.
- rust-lang/rust#146098 undoes the breakage this is a FCW for. If that behavior is merged and stabilizes in Rust 1.92, this PR should be reverted (or shouldn't be merged) in order to avoid spurious warnings.
cc `@traviscross`
`@rustbot` label +T-lang
[^1]: In particular, more syntactic approaches are complicated by having to avoid warning on promoted constants; they'd either be full of holes, they'd need a lot of extra logic, or they'd need to hack more MIR-to-HIR mapping into `PromoteTemps`.
[^2]: It's definitely possible to add more context and a suggestion, but the ways I've thought of to do so are either too hacky or too complex to feel appropriate for a last-minute direct-to-beta lint.
When building with `rust.rpath = false`, every `rustc` invocation needs
to include the library path as well. I particularly ran into this in
`generate_target_spec_json_schema` when testing 1.91-beta in Fedora,
where we do disable rpath for our system builds. The new helper function
will hopefully encourage the right thing going forward.
(cherry picked from commit 03cdcb5cd5)
document `core::ffi::VaArgSafe`
tracking issue: https://github.com/rust-lang/rust/issues/44930
A modification of https://github.com/rust-lang/rust/pull/146454, keeping just the documentation changes, but not unsealing the trait.
Although conceptually we'd want to unseal the trait, there are many edge cases to supporting arbitrary types. We'd need to exhaustively test that all targets/calling conventions support all types that rust might generate (or generate proper error messages for unsupported cases). At present, many of the `va_arg` implementations assume that the argument is a scalar, and has an alignment of at most 8. That is totally sufficient for an MVP (accepting all of the "standard" C types), but clearly does not cover all rust types.
This PR also adds some various other tests for edge cases of c-variadic:
- the `#[inline]` attribute in its various forms. At present, LLVM is unable to inline c-variadic functions, but the attribute should still be accepted. `#[rustc_force_inline]` already rejects c-variadic functions.
- naked functions should accept and work with a C variable argument list. In the future we'd like to allow more ABIs with naked functions (basically, any ABI for which we accept defining foreign c-variadic functions), but for now only `"C"` and `"C-unwind` are supported
- guaranteed tail calls: c-variadic functions cannot be tail-called. That was already rejected, but there was not test for it.
r? `@workingjubilee`
Pierre Tardy