| Age | Commit message (Collapse) | Author | Lines |
|---|
|
more strongly dissuade use of `skip_binder`
People unfortunately encounter `Binder` and `EarlyBinder` very early on when starting out. In these cases its often very easy to use `skip_binder` incorrectly. This makes it more explicit that it should generally not be used and points to the relevant `rustc-dev-guide` chapters.
r? `@BoxyUwU`
|
|
Account for bare tuples and `Pin` methods in field searching logic
When looking for the field names and types of a given type, account for tuples. This allows suggestions for incorrectly nested field accesses and field name typos to trigger as intended. Previously these suggestions only worked on `ty::Adt`, including tuple structs which are no different to tuples, so they should behave the same in suggestions.
When suggesting field access which would encounter a method not found, do not suggest pinning when those methods are on `impl Pin` itself.
```
error[E0599]: no method named `get_ref` found for tuple `(BufReader<File>,)` in the current scope
--> $DIR/missing-field-access.rs:11:15
|
LL | let x = f.get_ref();
| ^^^^^^^ method not found in `(BufReader<File>,)`
|
help: one of the expressions' fields has a method of the same name
|
LL | let x = f.0.get_ref();
| ++
```
instead of
```
error[E0599]: no method named `get_ref` found for tuple `(BufReader<File>,)` in the current scope
--> $DIR/missing-field-access.rs:11:15
|
LL | let x = f.get_ref();
| ^^^^^^^ method not found in `(BufReader<File>,)`
|
help: consider pinning the expression
|
LL ~ let mut pinned = std::pin::pin!(f);
LL ~ let x = pinned.as_ref().get_ref();
|
```
Fix rust-lang/rust#144602.
|
|
Implement declarative (`macro_rules!`) attribute macros (RFC 3697)
This implements [RFC 3697](https://github.com/rust-lang/rust/issues/143547), "Declarative (`macro_rules!`) attribute macros".
I would suggest reading this commit-by-commit. This first introduces the
feature gate, then adds parsing for attribute rules (doing nothing with them),
then adds the ability to look up and apply `macro_rules!` attributes by path,
then adds support for local attributes, then adds a test, and finally makes
various improvements to errors.
|
|
atomicrmw on pointers: move integer-pointer cast hacks into backend
Conceptually, we want to have atomic operations on pointers of the form `fn atomic_add(ptr: *mut T, offset: usize, ...)`. However, LLVM does not directly support such operations (https://github.com/llvm/llvm-project/issues/120837), so we have to cast the `offset` to a pointer somewhere.
This PR moves that hack into the LLVM backend, so that the standard library, intrinsic, and Miri all work with the conceptual operation we actually want. Hopefully, one day LLVM will gain a way to represent these operations without integer-pointer casts, and then the hack will disappear entirely.
Cc ```@nikic``` -- this is the best we can do right now, right?
Fixes https://github.com/rust-lang/rust/issues/134617
|
|
In rustc_pattern_analysis, put `true` witnesses before `false` witnesses
In rustc it doesn't really matter what the order of the witnesses is, but I'm planning to use the witnesses for implementing the "add missing match arms" assist in rust-analyzer, and there `true` before `false` is the natural order (like `Some` before `None`), and also what the current assist does.
The current order doesn't seem to be intentional; the code was created when bool ctors became their own thing, not just int ctors, but for integer, 0 before 1 is indeed the natural order.
r? `@Nadrieril`
|
|
atomicrmw on pointers: move integer-pointer cast hacks into backend
Conceptually, we want to have atomic operations on pointers of the form `fn atomic_add(ptr: *mut T, offset: usize, ...)`. However, LLVM does not directly support such operations (https://github.com/llvm/llvm-project/issues/120837), so we have to cast the `offset` to a pointer somewhere.
This PR moves that hack into the LLVM backend, so that the standard library, intrinsic, and Miri all work with the conceptual operation we actually want. Hopefully, one day LLVM will gain a way to represent these operations without integer-pointer casts, and then the hack will disappear entirely.
Cc ```@nikic``` -- this is the best we can do right now, right?
Fixes https://github.com/rust-lang/rust/issues/134617
|
|
Use `tcx.short_string()` in more diagnostics
`TyCtxt::short_string` ensures that user visible type paths aren't overwhelming on the terminal output, and properly saves the long name to disk as a side-channel. We already use these throughout the compiler and have been using them as needed when users find cases where the output is verbose. This is a proactive search of some cases to use `short_string`.
We add support for shortening the path of "trait path only".
Every manual use of `short_string` is a bright marker that that error should be using structured diagnostics instead (as they have proper handling of long types without the maintainer having to think abou tthem).
|
|
Add `target_env = "macabi"` and `target_env = "sim"`
[RFC 2992](https://github.com/rust-lang/rfcs/pull/2992) ([tracking issue](https://github.com/rust-lang/rust/issues/80970)) introduced `cfg(target_abi = ...)` with the original motivation being Mac Catalyst and Apple Simulator targets. These do not actually have a changed calling convention in the same sense that e.g. `cfg(target_abi = "eabihf")` or pointer authentication (`arm64e`) does, see https://github.com/rust-lang/rust/issues/133331.
Specifically, for Apple Simulator targets, the binary runs under the following conditions:
- Runs with the host macOS kernel (but in a mode configured for iOS/tvOS/...).
- Uses frameworks for the specific simulator version being targetted.
- System file accesses need to be made relative to the `IPHONE_SIMULATOR_ROOT` environment variable.
- Uses host GPUs directly.
And for Mac Catalyst:
- Runs with the host macOS kernel (but in a mode configured for iOS).
- Uses mostly host macOS frameworks (though with a few things changed, e.g. the [`NSImageResizingModeStretch`](https://developer.apple.com/documentation/appkit/nsimage/resizingmode-swift.enum/stretch?language=objc) enum has a different value).
- Uses host GPUs, camera and other peripherals directly.
As can be seen, these seem better suited as `target_env`s, since it really is the environment that the binary is running under that's changed (regardless of the Mac Catalyst "macabi" having "abi" in the name). So this PR adds `target_env = "sim"` and `target_env = "macabi"`, with the idea of possibly deprecating `target_abi = "sim"` and `target_abi = "macabi"` in the far future.
This affects iOS Tier 2 targets (`aarch64-apple-ios-sim`, `x86_64-apple-ios`, `aarch64-apple-ios-macabi` and `x86_64-apple-ios-macabi`), and probably needs a compiler FCP.
Fixes https://github.com/rust-lang/rust/issues/133331.
Reference PR: https://github.com/rust-lang/reference/pull/1781.
Cargo doc PR: https://github.com/rust-lang/cargo/pull/15404.
r? compiler
CC `@workingjubilee`
CC target maintainers `@deg4uss3r` `@thomcc` `@badboy` `@BlackHoleFox` `@madsmtm` `@agg23`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This allows a macro attribute to implement default arguments by
reapplying itself with the defaults filled in, for instance.
|
|
|
|
|
|
|
|
Test macros via path and local macros.
|
|
Teach the resolver to consider `macro_rules` macros when looking for a
local attribute. When looking for an attribute and considering a
`macro_rules` macro, load the macro in order to see if it has attribute
rules.
Include a FIXME about tracking multiple macro kinds for a Def instead.
|
|
Add infrastructure to apply an attribute macro given argument tokens and
body tokens.
Teach the resolver to consider `macro_rules` macros when looking for an
attribute via a path.
This does not yet handle local `macro_rules` attributes.
|
|
Add a FIXME for moving this error earlier.
|
|
Avoid saying "a declarative macro cannot be used as an attribute macro";
instead, say that the macro has no `attr` rules.
|
|
This handles various kinds of errors, but does not allow applying the
attributes yet.
This adds the feature gate `macro_attr`.
|
|
|
|
|
|
Now that `macro_rules` macros can define attribute rules, make sure
error messages account for that.
|
|
Revert #143906
This reverts commit 71f04692c32e181ab566c01942f1418dec8662d4, reversing changes made to 995ca3e532b48b689567533e6b736675e38b741e.
Reverts https://github.com/rust-lang/rust/pull/143906, which was merged in https://github.com/rust-lang/rust/pull/145043.
It seems like it is causing test failures on CI that block merges (https://github.com/rust-lang/rust/pull/144787#issuecomment-3168738836.
try-job: x86_64-gnu-aux
|
|
|
|
LorrensP-2158466:miri-float-nondet-foreign-items, r=RalfJung"
This reverts commit 71f04692c32e181ab566c01942f1418dec8662d4, reversing
changes made to 995ca3e532b48b689567533e6b736675e38b741e.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- linked-list cursor-like patterns
- issue-46589
These are known-bugs for the polonius alpha, where they show the same
imprecision as NLLs, but are supported by the old datalog
implementation.
|
|
This is an example similar to the linked-list cursor examples
where the alpha shows the same imprecision as NLLs, but that can work due to
the loans not being live after the loop, or the constraint graph being
simple enough that the cfg/subset relationships are the same for
reachability and liveness.
|
|
This test showcases the same imprecision as NLLs, unlike the datalog
implementation, when using reachability as a liveness approximation.
|
|
These are just some sanity checks to ensure NLLs, the polonius alpha
analysis, and the datalog implementation behave the same on these common
examples.
|
|
|
|
|
|
Remove incomplete handling of kills during traversal for loan liveness
to get to a simpler and actionable prototype.
This handles the cases, on sufficiently simple examples, that were
deferred from NLLs (NLL problem case 3, lending iterators), and is still
a good step to put in people's hands without needing to wait for another
full implementation. This is a practical cut in scope, but it also
shows where are the areas of improvement, that we will explore in the
future.
|
|
|
|
|
|
|
