| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Fix borrowck mentioning a name from an external macro we (deliberately) don't save
Most of the info is already in the title :shrug:
Closes rust-lang/rust#141764
|
|
Add missing `dyn` keywords to tests that do not test for them
This ensures that these tests can be run on editions other than 2015
|
|
r=compiler-errors
Add missing 2015 edition directives
These tests specifically test 2015 edition behavior, so ensure that they can only be run with this edition
|
|
Don't declare variables in `ExprKind::Let` in invalid positions
Handle `let` expressions in invalid positions specially during resolve in order to avoid making destructuring-assignment expressions that reference (invalid) variables that have not yet been delcared yet.
See further explanation in test and comment in the source.
Fixes rust-lang/rust#141844
|
|
azhogin:azhogin/async-drop-unexpected-type-instead-of-drop-fn-fix, r=oli-obk
Async drop - type instead of async drop fn, fixes #140484
Fixes: rust-lang/rust#140484
Fixes: rust-lang/rust#140500
Fixes ICE, when type is provided in AsyncDrop trait instead of `async fn drop()`.
Fixes ICE, when async drop fn has wrong signature.
|
|
They're very little value, because they only measure the top-level
`main.rs` or `lib.rs` file. (Other `.rs` files don't get read and parsed
until expansion occurs.)
I saw an example recently where the pre-expansion AST was 3KB in size
and the post-expansion AST was 66MB.
I kept the "POST EXPANSION" in the output header, I think that's useful
information to avoid possible confusion about when the measurement
happens.
|
|
|
|
|
|
|
|
|
|
r=petrochenkov
Fix false positive lint error from no_implicit_prelude attr
Fixes rust-lang/rust#141785
r? `@petrochenkov`
|
|
order of declaration.
|
|
|
|
|
|
|
|
|
|
This ensures that these tests can be run on editions other than 2015
|
|
These tests specifically test 2015 edition behavior, so ensure that they can only be run with this edition
|
|
|
|
|
|
|
|
terminology: allocated object → allocation
Rust does not have "objects" in memory so "allocated object" is a somewhat odd name. I am not sure where the term comes from. "object" has been used to refer to allocations already [in 1.0 docs](https://doc.rust-lang.org/1.0.0/std/primitive.pointer.html#method.offset); this was apparently later changed to "allocated object".
"Allocation" is already the terminology used in Miri and in the [UCG](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#allocation). We should properly move to that terminology, and avoid any confusion about whether Rust has an object memory model. (It does not. Memory contains untyped bytes.)
Cc ``@rust-lang/opsem`` ``@rust-lang/lang``
|
|
Improve diagnostics for usage of qualified paths within tuple struct exprs/pats
For patterns the old diagnostic was just incorrect, but I also added machine applicable suggestions.
For context, this special cases errors for `<T as Trait>::Assoc(..)` patterns and expressions (latter is just a call). Tuple struct patterns and expressions both live in the value namespace, so they are not forwarded through associated *types*.
r? ``@jdonszelmann``
cc ``@petrochenkov`` in https://github.com/rust-lang/rust/pull/80080#issuecomment-800630582 you were wondering why it doesn't work for types, that's why — tuple patterns are resolved in the value namespace.
|
|
don't ICE now
|
|
Avoid over-counting of `UsePath` in the HIR stats.
Currently we over-count. Details in the individual commits.
r? `@BoxyUwU`
|
|
Fix "consider borrowing" for else-if
Fixes rust-lang/rust#141810
When trying to suggest a borrow on a `if` or `block` expression, instead we now recurse into the `if` or `block`.
The comments in the code should explain the goal of the new code.
r? ``@jdonszelmann``
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#140787 (Note expr being cast when encounter NonScalar cast error)
- rust-lang/rust#141112 (std: note that `std::str::from_utf8*` functions are aliases to `<str>::from_utf8*` methods)
- rust-lang/rust#141646 (Document what `distcheck` is intended to exercise)
- rust-lang/rust#141740 (Hir item kind field order)
- rust-lang/rust#141793 (`tests/ui`: A New Order [1/N])
- rust-lang/rust#141805 (Update `compiler-builtins` to 0.1.160)
- rust-lang/rust#141815 (Enable non-leaf Frame Pointers for mingw-w64 Arm64 Windows)
- rust-lang/rust#141819 (Fixes for building windows-gnullvm hosts)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
`tests/ui`: A New Order [1/N]
not sure if i should say something about changes here, just part of rust-lang/rust#133895
but this is my very first time doing something like this, id love to keep contributing in this area later on, so any feedback is appreciated
also should say that im going to squash it after agreement on changes
r? `@jieyouxu`
mind if i name this PR series like "`tests/ui`: A New Order [N/N]", im not sure if it fits the project tone, so id like your approval first — but i think it sounds really neat (Star Wars reference)
this could be a first part :)
|
|
Note expr being cast when encounter NonScalar cast error
Fixes #140491
I added note for `expr` so that it doesn't treat `&x as T` as `&(x as T)` but `(&x) as T`. But I'm not sure if I want to add note for all NonScalar, maybe for specific `expr_ty`?
r? compiler
|
|
|
|
|
|
Do not move thread-locals before dropping
Fixes rust-lang/rust#140816. I also (potentially) improved the speed of `get_or_init` a bit by having an explicit hot/cold path.
We still move the value before dropping in the event of a recursive initialization (leading to double-initialization with one value being silently dropped). This is the old behavior, but changing this to panic instead would involve changing tests and also the other OS-specific `thread_local/os.rs` implementation, which is more than I'd like in this PR.
|
|
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
r=compiler-errors
Fix spans for unsafe binders
closes rust-lang/rust#141758
r? ``@compiler-errors``
|
|
Fix the issue of typo of comma in arm parsing
Fixes #140991
I also checked is it a '/', since it's near from ',' from keyboard.
|
|
Add Range parameter to `BTreeMap::extract_if` and `BTreeSet::extract_if`
This new parameter was requested in the btree_extract_if tracking issue: https://github.com/rust-lang/rust/issues/70530#issuecomment-2486566328
I attempted to follow the style used by `Vec::extract_if`.
Before:
```rust
impl<K, V, A: Allocator + Clone> BTreeMap<K, V, A> {
#[unstable(feature = "btree_extract_if", issue = "70530")]
pub fn extract_if<F>(&mut self, pred: F) -> ExtractIf<'_, K, V, F, A>
where
K: Ord,
F: FnMut(&K, &mut V) -> bool;
}
```
After:
```rust
impl<K, V, A: Allocator + Clone> BTreeMap<K, V, A> {
#[unstable(feature = "btree_extract_if", issue = "70530")]
pub fn extract_if<F, R>(&mut self, range: R, pred: F) -> ExtractIf<'_, K, V, R, F, A>
where
K: Ord,
R: RangeBounds<K>,
F: FnMut(&K, &mut V) -> bool;
}
```
Related: #70530
—
While I believe I have adjusted all of the necessary bits, as this is my first attempt to contribute to Rust, I may have overlooked something out of ignorance, but if you can point out any oversight, I shall attempt to remedy it.
|
|
|
|
Structurally normalize types as needed in `projection_ty_core`
Introduce a `structurally_normalize` callback to `projection_ty_core`, and then use it before we match on the ty kind in `projection_ty_core`.
Previously we were only structurally normalizing the return type of the `handle_field` struct, but if we were to (e.g.) apply a deref projection to that type, then the resulting type is not guaranteed to be structurally normalized and any subsequent projections applied would ICE.
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/221
I'll leave a few comments inline to explain the changes.
r? lcnr
---
Also fixes rust-lang/rust#141708
|
|
|
|
atomic_load intrinsic: use const generic parameter for ordering
We have a gazillion intrinsics for the atomics because we encode the ordering into the intrinsic name rather than making it a parameter. This is particularly bad for those operations that take two orderings. Let's fix that!
This PR only converts `load`, to see if there's any feedback that would fundamentally change the strategy we pursue for the const generic intrinsics.
The first two commits are preparation and could be a separate PR if you prefer.
`@BoxyUwU` -- I hope this is a use of const generics that is unlikely to explode? All we need is a const generic of enum type. We could funnel it through an integer if we had to but an enum is obviously nicer...
`@bjorn3` it seems like the cranelift backend entirely ignores the ordering?
|
|
Refactor the two-phase check for impls and impl items
Refactor the two-phase dead code check to make the logic clearer and simpler:
1. adding assoc fn and impl into `unsolved_items` directly during the initial construction of the worklist
2. converge the logic of checking whether assoc fn and impl are used to `item_should_be_checked`, and the item is considered used only when its corresponding trait and Self adt are used
This PR only refactors as much as possible to avoid affecting the original functions. However, due to the adjustment of the order of checks, the test results are slightly different, but overall, there is no regression problem
Fixes rust-lang/rust#127911
Fixes rust-lang/rust#128839
Extracted from https://github.com/rust-lang/rust/pull/128637.
r? petrochenkov
try-job: dist-aarch64-linux
|
|
Report text_direction_codepoint_in_literal when parsing
The lint is now reported in code that gets removed/modified/duplicated by macro expansion, and spans are more accurate so we don't get ICEs from trying to split a span in the middle of a character.
This removes support for lint level attributes for `text_direction_codepoint_in_literal` except at the crate level, I don't think that there's an easy way around this when the lint can be reported on code that's removed by `cfg` or that is only in the input of a macro.
Fixes #140281
|
|
Use `cfg_attr_trace` in AST with a placeholder attribute for accurate suggestion
In rust-lang/rust#138515, we insert a placeholder attribute so that checks for attributes can still know about the placement of `cfg` attributes. When we suggest removing items with `cfg_attr`s (fix rust-lang/rust#56328) and make them verbose. We tweak the wording of the existing "unused `extern crate`" lint.
```
warning: unused `extern crate`
--> $DIR/removing-extern-crate.rs:9:1
|
LL | extern crate removing_extern_crate as foo;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ unused
|
note: the lint level is defined here
--> $DIR/removing-extern-crate.rs:6:9
|
LL | #![warn(rust_2018_idioms)]
| ^^^^^^^^^^^^^^^^
= note: `#[warn(unused_extern_crates)]` implied by `#[warn(rust_2018_idioms)]`
help: remove the unused `extern crate`
|
LL - #[cfg_attr(test, macro_use)]
LL - extern crate removing_extern_crate as foo;
|
```
r? `@petrochenkov`
try-job: x86_64-gnu-aux
|
|
Rust's 128-bit integers have historically been incompatible with C [1].
However, there have been a number of changes in Rust and LLVM that
mean this is no longer the case:
* Incorrect alignment of `i128` on x86 [1]: adjusting Rust's alignment
proposed at https://github.com/rust-lang/compiler-team/issues/683,
implemented at https://github.com/rust-lang/rust/pull/116672.
* LLVM version of the above: resolved in LLVM, including ABI fix.
Present in LLVM18 (our minimum supported version).
* Incorrect alignment of `i128` on 64-bit PowerPC, SPARC, and MIPS [2]:
Rust's data layouts adjusted at
https://github.com/rust-lang/rust/pull/132422,
https://github.com/rust-lang/rust/pull/132741,
https://github.com/rust-lang/rust/pull/134115.
* LLVM version of the above: done in LLVM 20
https://github.com/llvm/llvm-project/issues/102783.
* Incorrect return convention of `i128` on Windows: adjusted to match
GCC and Clang at https://github.com/rust-lang/rust/pull/134290.
At [3], the lang team considered it acceptable to remove `i128` from
`improper_ctypes_definitions` if the LLVM version is known to be
compatible. Time has elapsed since then and we have dropped support for
LLVM versions that do not have the x86 fixes, meaning a per-llvm-version
lint should no longer be necessary. The PowerPC, SPARC, and MIPS changes
only came in LLVM 20 but since Rust's datalayouts have also been updated
to match, we will be using the correct alignment regardless of LLVM
version.
`repr(i128)` was added to this lint in [4], but is also removed here.
Part of the decision is that `i128` should match `__int128` in C on
platforms that provide it, which documentation is updated to indicate.
We will not guarantee that `i128` matches `_BitInt(128)` since that can
be different from `__int128`. Some platforms (usually 32-bit) do not
provide `__int128`; if any ABIs are extended in the future to define it,
we will need to make sure that our ABI matches.
Closes: https://github.com/rust-lang/rust/issues/134288
Closes: https://github.com/rust-lang/rust/issues/128950
[1]: https://github.com/rust-lang/rust/issues/54341
[2]: https://github.com/rust-lang/rust/issues/128950
[3]: https://github.com/rust-lang/lang-team/issues/255#issuecomment-2088855084
[4]: https://github.com/rust-lang/rust/pull/138282
|
|
|
|
|
|
|
|
PR 138515, we insert a placeholder attribute so that checks for attributes can still know about the placement of `cfg` attributes. When we suggest removing items with `cfg_attr`s (fix Issue 56328) and make them verbose. We tweak the wording of the existing "unused `extern crate`" lint.
```
warning: unused extern crate
--> $DIR/removing-extern-crate.rs:9:1
|
LL | extern crate removing_extern_crate as foo;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ unused
|
note: the lint level is defined here
--> $DIR/removing-extern-crate.rs:6:9
|
LL | #![warn(rust_2018_idioms)]
| ^^^^^^^^^^^^^^^^
= note: `#[warn(unused_extern_crates)]` implied by `#[warn(rust_2018_idioms)]`
help: remove the unused `extern crate`
|
LL - #[cfg_attr(test, macro_use)]
LL - extern crate removing_extern_crate as foo;
LL +
|
```
|
