Remove space after negative sign in Literal to_string
Negative proc macro literal tokens used to be printed with a space between the minus sign and the magnitude. That's because `impl ToString for Literal` used to convert the Literal into a TokenStream, which splits the minus sign into a separate Punct token.
```rust
Literal::isize_unsuffixed(-10).to_string() // "- 10"
```
This PR updates the ToString impl to directly use `rustc_ast::token::Lit`'s ToString, which matches the way Rust negative numbers are idiomatically written without a space.
```rust
Literal::isize_unsuffixed(-10).to_string() // "-10"
```
Places are usually shallow and quick to visit. By contrast, computing
`is_freeze` can be much costlier, involving inference and trait
solving. Making sure to call `is_freeze` only when necessary should be
beneficial for performance in most cases.
Remove invalid suggestion involving `Fn` trait bound
This pull request closes#85735. The actual issue is a duplicate of #21974, but #85735 contains a further problem, which is an invalid suggestion if `Fn`/`FnMut`/`FnOnce` trait bounds are involved: The suggestion code checks whether the trait bound ends with `>` to determine whether it has any generic arguments, but the `Fn*` traits have a special syntax for generic arguments that doesn't involve angle brackets. The example given in #85735:
```rust
trait Foo {}
impl<'a, 'b, T> Foo for T
where
T: FnMut(&'a ()),
T: FnMut(&'b ()), {
}
```
currently produces:
```
error[E0283]: type annotations needed
--> src/lib.rs:4:8
|
4 | T: FnMut(&'a ()),
| ^^^^^^^^^^^^^ cannot infer type for type parameter `T`
|
= note: cannot satisfy `T: FnMut<(&'a (),)>`
help: consider specifying the type arguments in the function call
|
4 | T: FnMut(&'a ())::<Self, Args>,
| ^^^^^^^^^^^^^^
error: aborting due to previous error
```
which is incorrect, because there is no function call, and applying the suggestion would lead to a parse error. With my changes, I get:
```
error[E0283]: type annotations needed
--> test.rs:4:8
|
4 | T: FnMut(&'a ()),
| ^^^^^^^^^^^^^ cannot infer type for type parameter `T`
|
::: [...]/library/core/src/ops/function.rs:147:1
|
147 | pub trait FnMut<Args>: FnOnce<Args> {
| ----------------------------------- required by this bound in `FnMut`
|
= note: cannot satisfy `T: FnMut<(&'a (),)>`
error: aborting due to previous error
```
i.e. I have added a check to prevent the invalid suggestion from being issued for `Fn*` bounds, while the underlying issue #21974 remains for now.
Trait upcasting coercion (part2)
This is the second part of trait upcasting coercion implementation.
Currently this is blocked on #86264 .
The third part might be implemented using unsafety checking
r? `@bjorn3`
This commit intends to fill out some of the remaining pieces of the
C-unwind ABI. This has a number of other changes with it though to move
this design space forward a bit. Notably contained within here is:
* On `panic=unwind`, the `extern "C"` ABI is now considered as "may
unwind". This fixes a longstanding soundness issue where if you
`panic!()` in an `extern "C"` function defined in Rust that's actually
UB because the LLVM representation for the function has the `nounwind`
attribute, but then you unwind.
* Whether or not a function unwinds now mainly considers the ABI of the
function instead of first checking the panic strategy. This fixes a
miscompile of `extern "C-unwind"` with `panic=abort` because that ABI
can still unwind.
* The aborting stub for non-unwinding ABIs with `panic=unwind` has been
reimplemented. Previously this was done as a small tweak during MIR
generation, but this has been moved to a separate and dedicated MIR
pass. This new pass will, for appropriate functions and function
calls, insert a `cleanup` landing pad for any function call that may
unwind within a function that is itself not allowed to unwind. Note
that this subtly changes some behavior from before where previously on
an unwind which was caught-to-abort it would run active destructors in
the function, and now it simply immediately aborts the process.
* The `#[unwind]` attribute has been removed and all users in tests and
such are now using `C-unwind` and `#![feature(c_unwind)]`.
I think this is largely the last piece of the RFC to implement.
Unfortunately I believe this is still not stabilizable as-is because
activating the feature gate changes the behavior of the existing `extern
"C"` ABI in a way that has no replacement. My thinking for how to enable
this is that we add support for the `C-unwind` ABI on stable Rust first,
and then after it hits stable we change the behavior of the `C` ABI.
That way anyone straddling stable/beta/nightly can switch to `C-unwind`
safely.
Rollup of 8 pull requests
Successful merges:
- #87645 (Properly find owner of closure in THIR unsafeck)
- #87646 (Fix a parser ICE on invalid `fn` body)
- #87652 (Validate that naked functions are never inlined)
- #87685 (Write docs for SyncOnceCell From and Default impl)
- #87693 (Add `aarch64-apple-ios-sim` as a possible target to the manifest)
- #87708 (Add convenience method for handling ipv4-mapped addresses by canonicalizing them)
- #87711 (Correct typo)
- #87716 (Allow generic SIMD array element type)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Fix a parser ICE on invalid `fn` body
Fixes#87635
A better fix would add a check for `fn` body on `expected_one_of_not_found` but I haven't come up with a graceful way. Any idea?
r? ```@oli-obk``` ```@estebank```
Properly find owner of closure in THIR unsafeck
Previously, when encountering a closure in a constant, the THIR unsafeck gets invoked on the owner of the constant instead of the constant itself, producing cycles.
Supersedes #87492. ```@FabianWolff``` thanks for your work on that PR, I copied your test file and added you as a co-author.
Fixes#87414.
r? ```@oli-obk```
Support negative numbers in Literal::from_str
proc_macro::Literal has allowed negative numbers in a single literal token ever since Rust 1.29, using https://doc.rust-lang.org/stable/proc_macro/struct.Literal.html#method.isize_unsuffixed and similar constructors.
```rust
let lit = proc_macro::Literal::isize_unsuffixed(-10);
```
However, the suite of constructors on Literal is not sufficient for all use cases, for example arbitrary precision floats, or custom suffixes in FFI macros.
```rust
let lit = proc_macro::Literal::f64_unsuffixed(0.101001000100001000001000000100000001); // :(
let lit = proc_macro::Literal::i???_suffixed(10ulong); // :(
```
For those, macros construct the literal using from_str instead, which preserves arbitrary precision, custom suffixes, base, and digit grouping.
```rust
let lit = "0.101001000100001000001000000100000001".parse::<Literal>().unwrap();
let lit = "10ulong".parse::<Literal>().unwrap();
let lit = "0b1000_0100_0010_0001".parse::<Literal>().unwrap();
```
However, until this PR it was not possible to construct a literal token that is **both** negative **and** preserving of arbitrary precision etc.
This PR fixes `Literal::from_str` to recognize negative integer and float literals.
Implement a `explicit_generic_args_with_impl_trait` feature gate
Implements #83701
When this gate is enabled, explicit generic arguments can be specified even if `impl Trait` is used in argument position. Generic arguments can only be specified for explicit generic parameters but not for the synthetic type parameters from `impl Trait`
So code like this will be accepted:
```rust
#![feature(explicit_generic_args_with_impl_trait)]
fn foo<T: ?Sized>(_f: impl AsRef<T>) {}
fn main() {
foo::<str>("".to_string());
}
```
CTFE: throw unsupported error when partially overwriting a pointer
Currently, during CTFE, when a write to memory would overwrite parts of a pointer, we make the remaining parts of that pointer "uninitialized". This is probably not what users expect, so if this ever happens they will be quite confused about why some of the data just vanishes for seemingly no good reason.
So I propose we change this to abort CTFE when that happens, to at last avoid silently doing the wrong thing.
Cc https://github.com/rust-lang/rust/issues/87184
Our CTFE test suite still seems to pass. However, we should probably crater this, and I want to do some tests with Miri as well.
After this commit, `unsafe async fn ...` now suggests the `async unsafe` fix
instead of misunderstanding the issue.
This is not perfect for repeated keywords (`const async const`) and for
keywords that are misplaced after `extern "some abi"` because of the way
`check_fn_font_matter` works, but changing it breaks so many tests and
diagnostics it has been judged too high a cost for this PR.
rfc3052 followup: Remove authors field from Cargo manifests
Since RFC 3052 soft deprecated the authors field, hiding it from
crates.io, docs.rs, and making Cargo not add it by default, and it is
not generally up to date/useful information for contributors, we may as well
remove it from crates in this repo.
When this gate is enabled, explicit generic arguments can be specified even
if `impl Trait` is used in argument position. Generic arguments can only be
specified for explicit generic parameters but not for the synthetic type
parameters from `impl Trait`
Bump bootstrap compiler to 1.55
Changing the cfgs for stdarch is missing, but my understanding is that we don't need to do it as part of this PR?
r? `@Mark-Simulacrum`
Bail on any found recursion when expanding opaque types
Fixes#87450. More of a bandaid because it does not fix the exponential complexity of the type folding used for opaque type expansion.
Suggest `br` if the unknown string prefix `rb` is found
Currently, for the following code:
```rust
fn main() {
rb"abc";
}
```
we issue the following suggestion:
```
help: consider inserting whitespace here
|
2 | rb "abc";
| --
```
With my changes (only in edition 2021, where unknown prefixes became an error), I get:
```
help: use `br` for a raw byte string
|
2 | br"abc";
| ^^
```
Add a hint that the expressions produce a value
Fixes#85913
The second commit is semi-_unrelated_ but it allows us to run the related tests just on `src/test/ui/lint`.
Trait upcasting coercion (part1)
This revives the first part of earlier PR #60900 .
It's not very clear to me which parts of that pr was design decisions, so i decide to cut it into pieces and land them incrementally. This allows more eyes on the details.
This is the first part, it adds feature gates, adds feature gates tests, and implemented the unsize conversion part.
(I hope i have dealt with the `ExistentialTraitRef` values correctly...)
The next part will be implementing the pointer casting.
Rollup of 9 pull requests
Successful merges:
- #86072 (Cross compiling rustc_llvm on Darwin requires zlib.)
- #87385 (Make `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` warn by default)
- #87547 (Add missing examples for NonNull)
- #87557 (Fix issue with autofix for ambiguous associated function from Rust 2021 prelude when struct is generic)
- #87559 (Tweak borrowing suggestion in `for` loop)
- #87596 (Add warning when whitespace is not skipped after an escaped newline)
- #87606 (Add some TAIT-related regression tests)
- #87609 (Add docs about performance and `Iterator::map` to `[T; N]::map`)
- #87616 (Fix missing word in rustdoc book)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Add warning when whitespace is not skipped after an escaped newline
Fixes issue #87318, also simplifies issue #87319.
* Add support to the lexer to emit warnings as well as errors.
* Emit a warning when a string literal contains an escaped newline, but when (some of) the whitespace on the next line is not skipped due to it being non-ASCII.
Fix issue with autofix for ambiguous associated function from Rust 2021 prelude when struct is generic
Fixes#86940
The test cases and associated issue should make it clear what specifically this is meant to fix. The fix is slightly hacky in that we check against the literal source code of the call site for the presence of `<` in order to determine if the user has included the generics for the struct (meaning we don't need to include them for them).
r? ``@nikomatsakis``
Make `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` warn by default
This PR makes the `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` lint warn by default.
To avoid showing a large number of un-actionable warnings to users, we only enable the lint for macros defined in the same crate. This ensures that users will be able to fix the warning by simply removing a semicolon.
In the future, I'd like to enable this lint unconditionally, and eventually make it into a hard error in a future edition. This PR is a step towards that goal.
Use more precise span for E0282 in cast expressions
This pull request fixes#85586. The example code given there:
```rust
fn main() {
let a = [1, 2, 3].iter().sum();
let b = (a + 1) as usize;
}
```
currently produces
```
error[E0282]: type annotations needed
--> issue-85586.rs:3:13
|
3 | let b = (a + 1) as usize;
| ^^^^^^^^^^^^^^^^ cannot infer type
|
= note: type must be known at this point
error: aborting due to previous error
```
even though the type of the entire cast expression quite clearly should be `usize`. The error is in the cast's left-hand side, which is made explicit by the changes in this PR:
```
error[E0282]: type annotations needed
--> issue-85586.rs:3:13
|
3 | let b = (a + 1) as usize;
| ^^^^^^^ cannot infer type
|
= note: type must be known at this point
error: aborting due to previous error
```
Add feature gates for `for` and `?` in consts
These operations seems *relatively* straightforward to support, and only seem to be blocked on `impl const Trait`.
I have included a working test for `const_try`, but `const_for` is currently unusable without reimplementing *every single* defaulted `Iterator` method, so I didn't do that.
(both features still need tracking issues before this is merged)
Rollup of 10 pull requests
Successful merges:
- #87052 (Optimize fmt::PadAdapter::wrap)
- #87522 (Fix assert in diy_float)
- #87553 (Fix typo in rustc_driver::version)
- #87554 (2229: Discr should be read when PatKind is Range)
- #87564 (min_type_alias_impl_trait is going to be removed in 1.56)
- #87574 (Update the examples in `String` and `VecDeque::retain`)
- #87583 (Refactor compression cache in v0 symbol mangler)
- #87585 (Add missing links for core::char types)
- #87594 (fs File get_path procfs usage for netbsd same as linux.)
- #87602 ([backtraces]: look for the `begin` symbol only after seeing `end`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Refactor compression cache in v0 symbol mangler
* Remove redundant option around compression caches (they are always present).
* Flatten compression caches into symbol mangler to avoid dynamic memory allocation.
* Implement printer for `&mut SymbolMangler` instead of `SymbolMangler` to avoid passing now slightly larger symbol mangler by value.
min_type_alias_impl_trait is going to be removed in 1.56
#87501 removed `min_type_alias_impl_trait` but meanwhile that PR was approved in homu queue, a new beta was cut so we need to bump the version because it won't be removed in 1.55.
r? ```@oli-obk```
```@bors``` rollup=always
2229: Discr should be read when PatKind is Range
This PR fixes an issue related to pattern matching in closures when Edition 2021 is enabled.
- If any of the patterns the discr is being matched on is `PatKind::Range` then the discr should be read
r? ```@nikomatsakis```
Closes https://github.com/rust-lang/rust/issues/87426
Mir borrowck does not generate lifetime variables for 'static lifetimes during opaque type resolution
Fixes#87455
This situation was unreachable before #87287 as we used to just grab the resolved opaque type from typeck and replaced all regions with new inference vars. After #87287 we let the `InferCx` in mir borrowck figure out the opaque type all by itself (which it already did before, but it only used the result to sanity check with the typeck result).
Since RFC 3052 soft deprecated the authors field anyway, hiding it from
crates.io, docs.rs, and making Cargo not add it by default, and it is
not generally up to date/useful information, we should remove it from
crates in this repo.
The compression caches currently don't have any dedicated functionality
that would benefit from being separated. Incorporating caches directly
into the symbol manger also avoids dynamic memory allocation.
The symbol mangler, which is often passed by value, is now slightly
larger. This aspect will be addressed by a follow-up commit.
Make const panic!("..") work in Rust 2021.
During const eval, this replaces calls to core::panicking::panic_fmt and std::panicking::being_panic_fmt with a call to a new const fn: core::panicking::const_panic_fmt. That function uses fmt::Arguments::as_str() to get the str and calls panic_str with that instead.
panic!() invocations with formatting arguments are still not accepted, as the creation of such a fmt::Arguments cannot be done in constant functions right now.
r? `@RalfJung`
Create `QuerySideEffects` and use it for diagnostics
The code for saving and loading diagnostics during execution is generalized to handle a new `QuerySideEffects` struct. Currently, this struct just holds diagnostics - in a follow-up PR, I plan to add support for storing attriutes marked as used during query execution.
This is a pure refactor, with no intended behavior changes.
During const eval, this replaces calls to core::panicking::panic_fmt and
std::panicking::being_panic_fmt with a call to a new const fn:
core::panicking::const_panic_fmt. That function uses
fmt::Arguments::as_str() to get the str and calls panic_str with that
instead.
panic!() invocations with formatting arguments are still not accepted,
as the creation of such a fmt::Arguments cannot be done in constant
functions right now.
Support -Z unpretty=thir-tree again
Currently `-Z unpretty=thir-tree` is broken after some THIR refactorings. This re-implements it, making it easier to debug THIR-related issues.
We have to do analyzes before getting the THIR, since trying to create THIR from invalid HIR can ICE. But doing those analyzes requires the THIR to be built and stolen. We work around this by creating a separate query to construct the THIR tree string representation.
Closes https://github.com/rust-lang/project-thir-unsafeck/issues/8, fixes#85552.
Implement RFC 3107: `#[derive(Default)]` on enums with a `#[default]` attribute
This PR implements RFC 3107, which permits `#[derive(Default)]` on enums where a unit variant has a `#[default]` attribute. See comments for current status.
Stabilize `const_fn_transmute`, `const_fn_union`
This PR stabilizes the `const_fn_transmute` and `const_fn_union` features. It _does not_ stabilize any methods (obviously aside from `transmute`) that are blocked on only these features.
Closes#53605. Closes#51909.
Combine two loops in `check_match`
Suggested by Nadrieril in
https://github.com/rust-lang/rust/pull/79051#discussion_r548778186.
Opening to get a perf run. Hopefully this code doesn't require everything in the
first loop to be done before running the second! (It shouldn't though.)
cc `@Nadrieril`
get rid of NoMirFor error variant
The only place where we throw that error, it is very quickly caught again and turned into a different error. So raise that other error immediately.
Add flag to configure `large_assignments` lint
The `large_assignments` lints detects moves over specified limit. The
limit is configured through `move_size_limit = "N"` attribute placed at
the root of a crate. When attribute is absent, the lint is disabled.
Make it possible to enable the lint without making any changes to the
source code, through a new flag `-Zmove-size-limit=N`. For example, to
detect moves exceeding 1023 bytes in a cargo crate, including all
dependencies one could use:
```
$ env RUSTFLAGS=-Zmove-size-limit=1024 cargo build -vv
```
Lint tracking issue #83518.
Remove unstable `--pretty` flag
It doesn't do anything `--unpretty` doesn't, and due to a bug, also
didn't show up in `--help`. I don't think there's any reason to keep it
around, I haven't seen anyone using it.
Closes https://github.com/rust-lang/rust/issues/36473.
