| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#146111 (Migrate more things in the new solver to specific `DefId`s)
- rust-lang/rust#146298 (GVN: Ensure indirect is first projection in try_as_place.)
- rust-lang/rust#146299 (docs(std): add error docs for path canonicalize)
- rust-lang/rust#146310 (Allow static regions in `type_name`.)
- rust-lang/rust#146313 (Some `rustc_middle` cleanups)
- rust-lang/rust#146319 (Fix typo in default.rs)
- rust-lang/rust#146320 (rustc-dev-guide subtree update)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
That test causes a large amount of crashes. If a system
has a /proc/sys/kernel/core_pattern that uploads core dumps enabled,
it will take a long time to complete. Set dumpable to 0 to avoid that.
Before:
$ time ./panic-uninitialized-zeroed
real 0m47.457s
user 0m0.023s
sys 0m0.021s
After:
$ ./panic-uninitialized-zeroed
real 0m0.029s
user 0m0.019s
sys 0m0.010s
|
|
improve c-variadic error reporting
tracking issue: https://github.com/rust-lang/rust/issues/44930
The parts of https://github.com/rust-lang/rust/pull/143546 that don't require any particular knowledge about c-variadic functions.
This prepares the way for rejecting c-variadic functions that are also coroutines, safe functions, or associated functions.
|
|
|
|
|
|
|
|
|
|
|
|
Fixes #146249.
|
|
|
|
lint ImproperCTypes: refactor linting architecture (part 1)
This is the first PR in an effort to split rust-lang/rust#134697 into individually-mergeable parts.
This one focuses on properly packaging the lint and its tests, as well as properly separate the "linting" and "type-checking" code.
There is exactly one user-visible change: the safety of `Option<Box<FFISafePointee>>` is now the same in `extern` blocks and function definitions: it is safe.
r? `@tgross35` because you are already looking at the original
|
|
Mainly, we realise that the non-null assumption on a Box<_> argument
does not depend on what side of the FFI boundary the function is on.
And anyway, this is not the way to deal with this assumption being maybe violated.
|
|
|
|
identity uses are ok, even if there are no defining uses
fix rust-lang/rust#146191
I've tried moving the "is this an identity use" check to `fn clone_and_resolve_opaque_types` and this would allow the following code to compile as it now ignores `Opaque<'!a> = Opaque<'!a>` while they previously resulted in errors https://github.com/rust-lang/rust/blob/71289c378d0a406a4f537fe4001282d19362931f/tests/ui/type-alias-impl-trait/hkl_forbidden.rs#L42-L46
The closure signature gets inferred to `for<'a> fn(&'a ()) -> Inner<'a>`. The closure then has a defining use `Inner<'a_latbound> = &'a_latebound ()` while the parent function has a non-defining `Inner<'!a> = Inner<'!a>`. By eagerly discarding identity uses we don't error on the non-defining use in the parent.
r? `@BoxyUwU`
|
|
Make the allocator shim participate in LTO again
This is likely the cause of the perf regression in https://github.com/rust-lang/rust/pull/145955. It also caused some functional regressions.
Fixes https://github.com/rust-lang/rust/issues/146235
Fixes https://github.com/rust-lang/rust/issues/146239
|
|
|
|
Co-Authored-By: Rémy Rakic <remy.rakic+github@gmail.com>
|
|
Suggest bounds in more cases, accounting for type parameters referenced in predicate
Use a `ty::Visitor` to see if the failed predicate references a type parameter. If it does, then we only suggest adding a bound to an (associated) item only if the referenced parameter is present in its generics.
Provide adding bound suggestion in trait and impl associated functions in cases we previously weren't:
```
error[E0277]: `?` couldn't convert the error to `ApplicationError`
--> $DIR/suggest-complex-bound-on-method.rs:18:16
|
LL | t.run()?;
| -----^ the trait `From<<T as Trait>::Error>` is not implemented for `ApplicationError`
| |
| this can't be annotated with `?` because it has type `Result<_, <T as Trait>::Error>`
|
note: `ApplicationError` needs to implement `From<<T as Trait>::Error>`
--> $DIR/suggest-complex-bound-on-method.rs:12:1
|
LL | enum ApplicationError {
| ^^^^^^^^^^^^^^^^^^^^^
= note: the question mark operation (`?`) implicitly performs a conversion on the error value using the `From` trait
help: consider introducing a `where` clause, but there might be an alternative better way to express this requirement
|
LL | fn thing<T: Trait>(&self, t: T) -> Result<(), ApplicationError> where ApplicationError: From<<T as Trait>::Error> {
| +++++++++++++++++++++++++++++++++++++++++++++++++
```
Fix rust-lang/rust#144734.
|
|
|
|
Suggest parentheses when `match` or `if` expression in binop is parsed as statement
```
error[E0308]: mismatched types
--> $DIR/expr-as-stmt.rs:81:5
|
LL | match () { _ => true } && match () { _ => true };
| ^^^^^^^^^^^^^^^^^^^^^^ expected `()`, found `bool`
|
help: parentheses are required to parse this as an expression
|
LL | (match () { _ => true }) && match () { _ => true };
| + +
```
Address the common case from rust-lang/rust#88727. The original parse error is still outstanding, but the cases brought up in the thread are resolved.
|
|
Rollup of 5 pull requests
Successful merges:
- rust-lang/rust#144342 (add exact bitshifts)
- rust-lang/rust#145709 (Fix LoongArch C function ABI when passing/returning structs containing floats)
- rust-lang/rust#146152 (Unify and deduplicate algebraic float tests)
- rust-lang/rust#146207 (std: Implement WASIp2-specific stdio routines)
- rust-lang/rust#146217 (fix ICE when suggesting `::new`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
fix ICE when suggesting `::new`
fixes https://github.com/rust-lang/rust/issues/146174
This code suggests to write `Foo::new(...)` when the user writes `Foo(...)` or `Foo { ... }` and the constructor is private, where `new` is some associated function that returns `Self`.
When checking that the return type of `new` is `Self`, we need to instantiate the parameters of `new` with infer vars, so we don't end up with a type like `Box<$param(0)>` in a context that doesn't have any parameters. But then we can't use `normalize_erasing_late_bound_regions` anymore because that goes though a query that can't deal with infer vars.
Since this is diagnostic-only code that is supposed to check for exactly `-> Self`, I think it's fine to just skip normalizing here, especially since The Correct Way<sup>TM</sup> would involve a probe and make this code even more complicated.
Also, the code here does almost the same thing, and these suggestions can probably be unified in the future: https://github.com/rust-lang/rust/blob/4ca8078d37c53ee4ff8fb32b4453b915116f25b8/compiler/rustc_hir_typeck/src/method/suggest.rs#L2123-L2129
r? ````@compiler-errors````
cc ````@Qelxiros```` -- this should unblock https://github.com/rust-lang/rust/pull/144420
|
|
resolve: Avoid finalizing extern prelude entries more than once
|
|
r=rcvalle
Sanitizers target modificators
Depends on bool flag fix: https://github.com/rust-lang/rust/pull/138483.
Some sanitizers need to be target modifiers, and some do not. For now, we should mark all sanitizers as target modifiers except for these: AddressSanitizer, LeakSanitizer
For kCFI, the helper flag -Zsanitizer-cfi-normalize-integers should also be a target modifier.
Many test errors was with sanizer flags inconsistent with std deps. Tests are fixed with `-C unsafe-allow-abi-mismatch`.
|
|
|
|
Co-authored-by: Travis Cross <tc@traviscross.com>
|
|
|
|
don't uppercase error messages
|
|
Ensure we emit an allocator shim when only some crate types need one
Found this while trying to write a test for https://github.com/rust-lang/rust/pull/145955.
|
|
Allow `inline(always)` with a target feature behind a unstable feature `target_feature_inline_always`.
Rather than adding the inline always attribute to the function definition, we add it to the callsite. We can then check that the target features match and that the call would be safe to inline. If the function isn't inlined due to a mismatch, we emit a warning informing the user that the function can't be inlined due to the target feature mismatch.
See tracking issue rust-lang/rust#145574
|
|
On unused binding or binding not present in all patterns, suggest potential typo of unit struct/variant or const
When encountering an or-pattern with a binding not available in all patterns, look for consts and unit struct/variants that have similar names as the binding to detect typos.
```
error[E0408]: variable `Ban` is not bound in all patterns
--> $DIR/binding-typo.rs:22:9
|
LL | (Foo, _) | (Ban, Foo) => {}
| ^^^^^^^^ --- variable not in all patterns
| |
| pattern doesn't bind `Ban`
|
help: you might have meant to use the similarly named unit variant `Bar`
|
LL - (Foo, _) | (Ban, Foo) => {}
LL + (Foo, _) | (Bar, Foo) => {}
|
```
For items that are not in the immedate scope, suggest the full path for them:
```
error[E0408]: variable `Non` is not bound in all patterns
--> $DIR/binding-typo-2.rs:51:16
|
LL | (Non | Some(_))=> {}
| --- ^^^^^^^ pattern doesn't bind `Non`
| |
| variable not in all patterns
|
help: you might have meant to use the similarly named unit variant `None`
|
LL - (Non | Some(_))=> {}
LL + (core::option::Option::None | Some(_))=> {}
|
```
When encountering a typo in a pattern that gets interpreted as an unused binding, look for unit struct/variant of the same type as the binding:
```
error: unused variable: `Non`
--> $DIR/binding-typo-2.rs:36:9
|
LL | Non => {}
| ^^^
|
help: if this is intentional, prefix it with an underscore
|
LL | _Non => {}
| +
help: you might have meant to pattern match on the similarly named variant `None`
|
LL - Non => {}
LL + std::prelude::v1::None => {}
|
```
Suggest constant on unused binding in a pattern
```
error: unused variable: `Batery`
--> $DIR/binding-typo-2.rs:110:9
|
LL | Batery => {}
| ^^^^^^
|
help: if this is intentional, prefix it with an underscore
|
LL | _Batery => {}
| +
help: you might have meant to pattern match on the similarly named constant `Battery`
|
LL | Battery => {}
| +
```
Fix rust-lang/rust#51976.
|
|
fix drop scope for `super let` bindings within `if let`
Fixes rust-lang/rust#145328 by making non-lifetime-extended `super let` reuse the logic used to compute drop scopes for non-lifetime-extended temporaries.
Also fixes rust-lang/rust#145374, which regressed due to rust-lang/rust#143376 introducing `if let`-like scopes for match arms with guards.
Tracking issue for `super let`: rust-lang/rust#139076
This is a regression fix / breaking change for macros stably exposing `super let`, including `pin!` and `format_args!`.
Nominating to be discussed alongside rust-lang/rust#145328: ```@rustbot``` label +I-lang-nominated +I-libs-api-nominated
|
|
Revert "Make `lto` and `linker-plugin-lto` work the same for `compiler_builtins`
This reverts commit cf8753e4f9c3597f04cd5d3aa261e4561d5378a6 (PR https://github.com/rust-lang/rust/pull/145368) and fix the regressions reported at rust-lang/rust#145981, rust-lang/rust#146109, and rust-lang/rust#146145.
|
|
|
|
|
|
a more general version of https://github.com/rust-lang/rust/pull/146080.
after a bit of hacking in [`fluent.rs`](https://github.com/rust-lang/rust/blob/master/compiler/rustc_fluent_macro/src/fluent.rs), i discovered that i'm not the only one that is bad at following guidelines :sweat_smile:. this pr lowercases the first letter of all the error messages in the codebase.
(i did not change things that are traditionally uppercased such as _MIR_, _ABI_ or _C_)
i think it's reasonable to run a `@bors try` so all the test suite is checked, as i cannot run some of the tests on my machine. i double checked (and replaced manually) all the old error messages, but better be safe than sorry.
in the future i will try to add a check in `x test tidy` that errors if an error message starts with an uppercase letter.
|
|
fix(lexer): Only allow horizontal whitespace in frontmatter
In writing up the reference for frontmatter, I realized that we probably
shouldn't be accepting Unicode Line Ending characters between the code
fence and infostring or trailing after the infostring or a code fence.
In digging into the unicode specification we use for Whitespace, it
divides it up into categories, so I'm deferring to what it says for
horizontal whitespace for what should be used within a line.
Note, I am leaving out support for Unicode Default Ignorable characters.
I figure that can be discussed outside of this change within the
reference and tracking issue.
Fixes rust-lang/rust#145971
Frontmatter tracking issue: rust-lang/rust#136889
|
|
resolve: Avoid a regression from splitting prelude into two scopes
Fixes https://github.com/rust-lang/rust/issues/145575.
|
|
Constify conversion traits (part 1)
This is the first part of rust-lang/rust#144289 being split into smaller pieces. It adds/moves constness of several traits under the `const_convert` feature:
* `From`
* `Into`
* `TryFrom`
* `TryInto`
* `FromStr`
* `AsRef`
* `AsMut`
* `Borrow`
* `BorrowMut`
* `Deref`
* `DerefMut`
There are a few methods that are intrinsically tied to these traits which I've included in the feature. Particularly, those which are wrappers over `AsRef`:
* `ByteStr::new` (unstable under `bstr` feature)
* `OsStr::new`
* `Path::new`
Those which directly use `Into`:
* `Result::into_ok`
* `Result::into_err`
And those which use `Deref` and `DerefMut`:
* `Pin::as_ref`
* `Pin::as_mut`
* `Pin::as_deref_mut`
* `Option::as_deref`
* `Option::as_deref_mut`
* `Result::as_deref`
* `Result::as_deref_mut`
(note: the `Option` and `Result` methods were suggested by ``@npmccallum`` initially as rust-lang/rust#146101)
The parts which are missing from this PR are:
* Anything that involves heap-allocated types
* Making any method const than the ones listed above
* Anything that could rely on the above, *or* could rely on system-specific code for `OsStr` or `Path` (note: this mostly makes these methods useless since `str` doesn't implement `AsRef<OsStr>` yet, but it's better to track the method for now and add impls later, IMHO)
r? ``@tgross35`` (who mostly already reviewed this)
|
|
`compiler_builtins`"
This reverts commit cf8753e4f9c3597f04cd5d3aa261e4561d5378a6 and fixes the
regressions reported.
|
|
Add compiler error when trying to use concat metavar expr in repetitions
## Disclaimer
This is my first PR to rust, so if I missed/could improve something about this PR, please excuse and tell me!
## The improvement
The [metavar_expr_concat feature](https://github.com/rust-lang/rust/issues/124225) currently does not seem to support nested repetitions, and throws an ICE without much explanation if the relevant code path is hit.
This PR adds a draft compiler error that attempts to explain the issue. I am not 100% sure what all the ways of triggering this error are, so the message is currently pretty generic, please do correct me if there's something wrong with it or it could be improved.
Thank you for you time!
Fixes rust-lang/rust#140479.
|
|
add span to struct pattern rest (..)
Struct pattern rest (`..`) did not retain span information compared to normal fields. This patch adds span information for it.
The motivation of this patch comes from when I implemented this PR for Clippy: https://github.com/rust-lang/rust-clippy/pull/15000#discussion_r2134145163
It is possible to get the span of the Et cetera in a bit roundabout way, but I thought this would be nicer.
|
|
stabilize c-style varargs for sysv64, win64, efiapi, aapcs
This has been split up so the PR now only contains the extended_varargs_abi_support stabilization; "system" has been moved to https://github.com/rust-lang/rust/pull/145954.
**Previous (combined) PR description:**
This stabilizes extern block declarations of variadic functions with the system, sysv64, win64, efiapi, aapcs ABIs. This corresponds to the extended_varargs_abi_support and extern_system_varargs feature gates.
The feature gates were split up since it seemed like there might be further discussion needed for what exactly "system" ABI variadic functions should do, but a [consensus](https://github.com/rust-lang/rust/issues/136946#issuecomment-2967847553) has meanwhile been reached: they shall behave like "C" functions. IOW, the ABI of a "system" function is (bold part is new in this PR):
- "stdcall" for win32 targets **for non-variadic functions**
- "C" for everything else
This had been previously stabilized *without FCP* in https://github.com/rust-lang/rust/pull/116161, which got reverted in https://github.com/rust-lang/rust/pull/136897. There was also a "fun" race condition involved with the system ABI being [added](https://github.com/rust-lang/rust/pull/119587) to the list of variadic-supporting ABIs between the creation and merge of rust-lang/rust#116161.
There was a question raised [here](https://github.com/rust-lang/rust/pull/116161#issuecomment-1983829513) whether t-lang even needs to be involved for a change like this. Not sure if that has meanwhile been clarified? The behavior of the "system" ABI (a Rust-specific ABI) definitely feels like t-lang territory to me.
Fixes rust-lang/rust#100189
Cc `@rust-lang/lang`
# Stabilization report
> ## General design
> ### What is the RFC for this feature and what changes have occurred to the user-facing design since the RFC was finalized?
AFAIK there is no RFC. The tracking issues are
- https://github.com/rust-lang/rust/issues/100189
- https://github.com/rust-lang/rust/issues/136946
> ### What behavior are we committing to that has been controversial? Summarize the major arguments pro/con.
The only controversial point is whether "system" ABI functions should support variadics.
- Pro: This allows crates like windows-rs to consistently use "system", see e.g. https://github.com/microsoft/windows-rs/issues/3626.
- Cons: `@workingjubilee` had some implementation concerns, but I think those have been [resolved](https://github.com/rust-lang/rust/issues/136946#issuecomment-2967847553). EDIT: turns out Jubilee still has concerns (she mentioned that in a DM); I'll let her express those.
Note that "system" is already a magic ABI we introduced to "do the right thing". This just makes it do the right thing in more cases. In particular, it means that on Windows one can almost always just do
```rust
extern "system" {
// put all the things here
}
```
and it'll do the right thing, rather than having to split imports into non-varargs and varargs, with the varargs in a separate `extern "C"` block (and risking accidentally putting a non-vararg there).
(I am saying "almost" always because some Windows API functions actually use cdecl, not stdcall, on x86. Those of course need to go in `extern "C"` blocks.)
> ### Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those?
Actually defining variadic functions in Rust remains unstable, under the [c_variadic feature gate](https://github.com/rust-lang/rust/issues/44930).
> ## Has a Call for Testing period been conducted? If so, what feedback was received?
>
> Does any OSS nightly users use this feature? For instance, a useful indication might be "search <grep.app> for `#![feature(FEATURE_NAME)]` and had `N` results".
There was no call for testing.
A search brings up https://github.com/rust-osdev/uefi-rs/blob/main/uefi-raw/src/table/boot.rs using this for "efiapi". This doesn't seem widely used, but it is an "obvious" gap in our support for c-variadics.
> ## Implementation quality
All rustc does here is forward the ABI to LLVM so there's lot a lot to say here...
> ### Summarize the major parts of the implementation and provide links into the code (or to PRs)
>
> An example for async closures: <https://rustc-dev-guide.rust-lang.org/coroutine-closures.html>.
The check for allowed variadic ABIs is [here](https://github.com/rust-lang/rust/blob/9c870d30e2d6434c9e9a004b450c5ccffdf3d844/compiler/rustc_hir_analysis/src/lib.rs#L109-L126).
The special handling of "system" is [here](https://github.com/rust-lang/rust/blob/c24914ec8329b22ec7bcaa6ab534a784b2bd8ab9/compiler/rustc_target/src/spec/abi_map.rs#L82-L85).
> ### Summarize existing test coverage of this feature
>
> Consider what the "edges" of this feature are. We're particularly interested in seeing tests that assure us about exactly what nearby things we're not stabilizing.
>
> Within each test, include a comment at the top describing the purpose of the test and what set of invariants it intends to demonstrate. This is a great help to those reviewing the tests at stabilization time.
>
> - What does the test coverage landscape for this feature look like?
> - Tests for compiler errors when you use the feature wrongly or make mistakes?
> - Tests for the feature itself:
> - Limits of the feature (so failing compilation)
> - Exercises of edge cases of the feature
> - Tests that checks the feature works as expected (where applicable, `//@ run-pass`).
> - Are there any intentional gaps in test coverage?
>
> Link to test folders or individual tests (ui/codegen/assembly/run-make tests, etc.).
Prior PRs add a codegen test for all ABIs and tests actually calling extern variadic functions for sysv64 and win64:
- https://github.com/rust-lang/rust/pull/144359
- https://github.com/rust-lang/rust/pull/144379
We don't have a way of executing uefi target code in the test suite, so it's unclear how to fully test efiapi. aapcs could probably be done? (But note that we have hardly an such actually-calling-functions tests for ABI things, we almost entirely rely on codegen tests.)
The test ensuring that we do *not* stabilize *defining* c-variadic functions is `tests/ui/feature-gates/feature-gate-c_variadic.rs`.
> ### What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking?
None that I am aware of.
> ### What FIXMEs are still in the code for that feature and why is it ok to leave them there?
None that I am aware of.
> ### Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization
`@Soveu` added sysv64, win64, efiapi, aapcs to the list of ABIs that allow variadics, `@beepster4096` added system. `@workingjubilee` recently refactored the ABI handling in the compiler, also affecting this feature.
> ### Which tools need to be adjusted to support this feature. Has this work been done?
>
> Consider rustdoc, clippy, rust-analyzer, rustfmt, rustup, docs.rs.
Maybe RA needs to be taught about the new allowed ABIs? No idea how precisely they mirror what exactly rustc accepts and rejects here.
> ## Type system and execution rules
> ### What compilation-time checks are done that are needed to prevent undefined behavior?
>
> (Be sure to link to tests demonstrating that these tests are being done.)
Nothing new here, this just expands the existing support for calling variadic functions to more ABIs.
> ### Does the feature's implementation need checks to prevent UB or is it sound by default and needs opt in in places to perform the dangerous/unsafe operations? If it is not sound by default, what is the rationale?
Nothing new here, this just expands the existing support for calling variadic functions to more ABIs.
> ### Can users use this feature to introduce undefined behavior, or use this feature to break the abstraction of Rust and expose the underlying assembly-level implementation? (Describe.)
Nothing new here, this just expands the existing support for calling variadic functions to more ABIs.
> ### What updates are needed to the reference/specification? (link to PRs when they exist)
- https://github.com/rust-lang/reference/pull/1936
> ## Common interactions
> ### Does this feature introduce new expressions and can they produce temporaries? What are the lifetimes of those temporaries?
No.
> ### What other unstable features may be exposed by this feature?
None.
|
|
|
|
|
|
|
|
|
|
|
