Unify wording of resolve error
Remove "failed to resolve" from the main error message and use the same format we use in other resolution errors "cannot find `name`":
```
error[E0433]: cannot find `nonexistent` in `existent`
--> $DIR/custom_attr_multisegment_error.rs:5:13
|
LL | #[existent::nonexistent]
| ^^^^^^^^^^^ could not find `nonexistent` in `existent`
```
The intent behind this is to end up with all resolve errors eventually be on the form of
```
error[ECODE]: cannot find `{NAME}` in {SCOPE}
--> $DIR/file.rs:5:13
|
LL | #[existent::nonexistent]
| ^^^^^^^^^^^ {SPECIFIC LABEL}
```
A category of errors that is interest are those that involve keywords. For example:
```
error[E0433]: cannot find `Self` in this scope
--> $DIR/issue-97194.rs:2:35
|
LL | fn bget(&self, index: [usize; Self::DIM]) -> bool {
| ^^^^ `Self` is only available in impls, traits, and type definitions
```
and
```
error[E0433]: cannot find `super` in this scope
--> $DIR/keyword-super.rs:2:9
|
LL | let super: isize;
| ^^^^^ there are too many leading `super` keywords
```
For these the label provides the actual help, while the message is less informative beyond telling you "couldn't find `name`".
This is an off-shoot of https://github.com/rust-lang/rust/pull/126810 and https://github.com/rust-lang/rust/pull/128086, a subset of the intended changes there with review comments applied.
r? @petrochenkov
Support JSON target specs in bootstrap
JSON target specs were destabilized in https://github.com/rust-lang/rust/pull/150151 and https://github.com/rust-lang/rust/pull/151534. However, this broke trying to build rustc itself with a JSON target spec. This is because in a few places bootstrap is manually calling `rustc` without the ability for the user to provide additional flags (primarily, `-Zunstable-options` to enable JSON targets).
There's a few different ways to fix this. One would be to change these calls to `rustc` to include flags provided by the user (such as `RUSTFLAGS_NOT_BOOTSTRAP`). Just to keep things simple, this PR proposes to just unconditionally pass `-Zunstable-options`.
Another consideration here is how maintainable this is. A possible improvement here would be to have a function somewhere (BootstrapCommand, TargetSelection, free function) that would handle appropriately adding the `--target` flag. For example, that's what cargo does in [`CompileKind::add_target_arg`](592058c7ce/src/cargo/core/compiler/compile_kind.rs (L144-L154)).
I have only tested building the compiler and a few tools like rustdoc. I have not tested doing things like building other tools, running tests, etc.
This would be much easier if there was a Docker image for testing the use case of building rustc with a custom target spec (and even better if that ran in CI).
After the next beta branch, using target JSON specs will become more cumbersome because target specs with the `.json` extension will now require passing `-Zjson-target-spec` (from
https://github.com/rust-lang/cargo/pull/16557). This does not affect target specs without the `.json` extension (such as those from RUST_TARGET_PATH). From my testing, it should be sufficient to pass `CARGOFLAGS_NOT_BOOTSTRAP="-Zjson-target-spec"`. I think that should be fine, since this is not a particularly common use case AFAIK. We could extend bootstrap to auto-detect if the target is a file path, and pass `-Zjson-target-spec` appropriately. I tried something similar in f0bdd35483, which could be adapted if desired.
It would be nice if all of this is documented somewhere. https://rustc-dev-guide.rust-lang.org/building/new-target.html does not really say how to build the compiler with a custom json target.
Fixes https://github.com/rust-lang/rust/issues/151729
Remove "failed to resolve" and use the same format we use in other resolution errors "cannot find `name`".
```
error[E0433]: cannot find `nonexistent` in `existent`
--> $DIR/custom_attr_multisegment_error.rs:5:13
|
LL | #[existent::nonexistent]
| ^^^^^^^^^^^ could not find `nonexistent` in `existent`
```
Install LLVM DLL in the right place on Windows
Continuation of https://github.com/rust-lang/rust/pull/151795 towards https://github.com/rust-lang/rust/issues/151774.
Unlike other systems, Windows requires runtime libraries to be present in `PATH` or right next to the binary.
So, we copy the library next to the binary as the easier solution.
Tested building `rust-openssl` in debug and release modes, but the difference is within noise margin.
Fix mis-constructed `file_span` when generating scraped examples
Fixesrust-lang/rust#152601. Seemingly relative with rust-lang/rust#147399 but I could not reproduce the original ICE.
This PR removes the `file_span` logic from scraped example generation. The original implementation did not read or write items using `file_span`; it only used it to locate a source file, `context.href_from_span`. However, the span was validated against the wrong file, which could trigger ICEs on inputs such as multibyte characters due to an incorrectly constructed span. Since scraped examples do not use the span and the `url` is already given, the safest and simplest fix is to remove it.
Tested against the crate and MCVE documented in the original issue.
P.S. there seems to be some bug when rendering call sites, but since fixing mis-behavior is a change rather than a bug-fix that would be implemented in another PR.
Implement RFC 3678: Final trait methods
Tracking: https://github.com/rust-lang/rust/issues/131179
This PR is based on rust-lang/rust#130802, with some minor changes and conflict resolution.
Futhermore, this PR excludes final methods from the vtable of a dyn Trait.
And some excerpt from the original PR description:
> Implements the surface part of https://github.com/rust-lang/rfcs/pull/3678.
>
> I'm using the word "method" in the title, but in the diagnostics and the feature gate I used "associated function", since that's more accurate.
cc @joshtriplett
replace box_new with lower-level intrinsics
The `box_new` intrinsic is super special: during THIR construction it turns into an `ExprKind::Box` (formerly known as the `box` keyword), which then during MIR building turns into a special instruction sequence that invokes the exchange_malloc lang item (which has a name from a different time) and a special MIR statement to represent a shallowly-initialized `Box` (which raises [interesting opsem questions](https://github.com/rust-lang/rust/issues/97270)).
This PR is the n-th attempt to get rid of `box_new`. That's non-trivial because it usually causes a perf regression: replacing `box_new` by naive unsafe code will incur extra copies in debug builds, making the resulting binaries a lot slower, and will generate a lot more MIR, making compilation measurably slower. Furthermore, `vec!` is a macro, so the exact code it expands to is highly relevant for borrow checking, type inference, and temporary scopes.
To avoid those problems, this PR does its best to make the MIR almost exactly the same as what it was before. `box_new` is used in two places, `Box::new` and `vec!`:
- For `Box::new` that is fairly easy: the `move_by_value` intrinsic is basically all we need. However, to avoid the extra copy that would usually be generated for the argument of a function call, we need to special-case this intrinsic during MIR building. That's what the first commit does.
- `vec!` is a lot more tricky. As a macro, its details leak to stable code, so almost every variant I tried broke either type inference or the lifetimes of temporaries in some ui test or ended up accepting unsound code due to the borrow checker not enforcing all the constraints I hoped it would enforce. I ended up with a variant that involves a new intrinsic, `fn write_box_via_move<T>(b: Box<MaybeUninit<T>>, x: T) -> Box<MaybeUninit<T>>`, that writes a value into a `Box<MaybeUninit<T>>` and returns that box again. In exchange we can get rid of somewhat similar code in the lowering for `ExprKind::Box`, and the `exchange_malloc` lang item. (We can also get rid of `Rvalue::ShallowInitBox`; I didn't include that in this PR -- I think @cjgillot has a commit for this somewhere [around here](https://github.com/rust-lang/rust/pull/147862/commits).)
See [here](https://github.com/rust-lang/rust/pull/148190#issuecomment-3457454814) for the latest perf numbers. Most of the regressions are in deep-vector which consists entirely of an invocation of `vec!`, so any change to that macro affects this benchmark disproportionally.
This is my first time even looking at MIR building code, so I am very low confidence in that part of the patch, in particular when it comes to scopes and drops and things like that.
I also had do nerf some clippy tests because clippy gets confused by the new expansion of `vec!` so it makes fewer suggestions when `vec!` is involved.
### `vec!` FAQ
- Why does `write_box_via_move` return the `Box` again? Because we need to expand `vec!` to a bunch of method invocations without any blocks or let-statements, or else the temporary scopes (and type inference) don't work out.
- Why is `box_assume_init_into_vec_unsafe` (unsoundly!) a safe function? Because we can't use an unsafe block in `vec!` as that would necessarily also include the `$x` (due to it all being one big method invocation) and therefore interpret the user's code as being inside `unsafe`, which would be bad (and 10 years later, we still don't have safe blocks for macros like this).
- Why does `write_box_via_move` use `Box` as input/output type, and not, say, raw pointers? Because that is the only way to get the correct behavior when `$x` panics or has control effects: we need the `Box` to be dropped in that case. (As a nice side-effect this also makes the intrinsic safe, which is imported as explained in the previous bullet.)
- Can't we make it safe by having `write_box_via_move` return `Box<T>`? Yes we could, but there's no easy way for the intrinsic to convert its `Box<MaybeUninit<T>>` to a `Box<T>`. Transmuting would be unsound as the borrow checker would no longer properly enforce that lifetimes involved in a `vec!` invocation behave correctly.
- Is this macro truly cursed? Yes, yes it is.
JSON target specs were destabilized in
https://github.com/rust-lang/rust/pull/150151 and
https://github.com/rust-lang/rust/pull/151534. However, this broke
trying to build rustc itself with a JSON target spec. This is because in
a few places bootstrap is manually calling `rustc` without the ability
for the user to provide additional flags (primarily,
`-Zunstable-options` to enable JSON targets).
There's a few different ways to fix this. One would be to change these
calls to `rustc` to include flags provided by the user (such as
`RUSTFLAGS_NOT_BOOTSTRAP`). Just to keep things simple, this PR proposes
to just unconditionally pass `-Zunstable-options`.
Another consideration here is how maintainable this is. A possible
improvement here would be to have a function somewhere
(BootstrapCommand, TargetSelection, free function) that would handle
appropriately adding the `--target` flag. For example, that's what cargo
does in
[`CompileKind::add_target_arg`](592058c7ce/src/cargo/core/compiler/compile_kind.rs (L144-L154)).
I have only tested building the compiler and a few tools like rustdoc. I
have not tested doing things like building other tools, running tests,
etc.
This would be much easier if there was a Docker image for testing the
use case of building rustc with a custom target spec (and even better if
that ran in CI).
After the next beta branch, using target JSON specs will become more
cumbersome because target specs with the `.json` extension will now
require passing `-Zjson-target-spec` (from
https://github.com/rust-lang/cargo/pull/16557). This does not affect
target specs without the `.json` extension (such as those from
RUST_TARGET_PATH). From my testing, it should be sufficient to pass
`CARGOFLAGS_NOT_BOOTSTRAP="-Zjson-target-spec"`. I think that should be
fine, since this is not a particularly common use case AFAIK. We could
extend bootstrap to auto-detect if the target is a file path, and pass
`-Zjson-target-spec` appropriately. I tried something similar in
f0bdd35483,
which could be adapted if desired.
It would be nice if all of this is documented somewhere.
https://rustc-dev-guide.rust-lang.org/building/new-target.html does not
really say how to build the compiler with a custom json target.
Fixes https://github.com/rust-lang/rust/issues/151729
bootstrap: Inline the `is_tool` check for setting `-Zforce-unstable-if-unmarked`
`Mode::is_tool` is the sort of method that looks general-purpose, but is only actually used for a very specific purpose, to control the setting of `-Zforce-unstable-if-unmarked`.
It is therefore clearer to inline the mode check, which makes it easier to see how the condition affects the result.
I have tried to add some comments explaining why we set that flag, but they are based on my own recent investigations, so I'm not 100% confident that they're accurate.
support c-variadic functions in `rustc_const_eval`
tracking issue: https://github.com/rust-lang/rust/issues/44930
The new `GlobalAlloc::VaList` is used to create an `AllocId` that represents the variable argument list of a frame. The allocation itself does not store any data, all we need is the unique identifier.
The actual variable argument list is stored in `Memory`, and keyed by the `AllocId`. The `Frame` also stores this `AllocId`, so that when a frame is popped, it can deallocate the variable arguments.
At "runtime" a `VaList` value stores a pointer to the global allocation in its first bytes. The provenance on this pointer can be used to retrieve its `AllocId`, and the offset of the pointer is used to store the index of the next argument to read from the variable argument list.
Miri does not yet support `va_arg`, but I think that can be done separetely?
r? @RalfJung
cc @workingjubilee
Unlike other systems, Windows requires runtime libraries to be present
in `PATH` or right next to the binary.
So, we copy the library next to the binary as the easier solution.
the rhs of an ordinary assignment `x = *never_ptr` was inferred with
`ExprIsRead::No`, which prevented `NeverToAny` coercion for place
expressions of type `!`. this caused false type mismatches and missing
divergence detection. the destructuring assignment path and let binding
path both correctly use `ExprIsRead::Yes` for the rhs value, since the
value is always consumed (read). this makes the ordinary assignment path
consistent with both.
Include `library/stdarch` for `CURRENT_RUSTC_VERSION` updates
Our tool `replace-version-placeholder` uses the `tidy` file walker and its
directory filter, but that skips `library/stdarch` which we do need for public
stability markers. This PR adds a local filter function that explicitly allows
that path.
The commit for 1.94 `stdarch` updates is coming from beta rust-lang/rust#152187.
ci: Lock cross toolchain version and update docs
This PR locks the cross-toolchain component version to avoid unexpected changes when bumping crosstool-ng, and updates the toolchain configuration in the docs to match the actual setup.
try-job: dist-arm-linux-musl
try-job: dist-loongarch64-linux
try-job: dist-loongarch64-musl
try-job: dist-powerpc64-linux-musl
try-job: dist-powerpc64le-linux-gnu
try-job: dist-powerpc64le-linux-musl
the standalone `contains_explicit_ref_binding` function only checked for
`BindingAnnotation::Ref`, missing `BindingAnnotation::RefMut`. this caused
`let ref mut x = expr` to incorrectly take the coercion path instead of
preserving the exact type of the rhs expression. the method version used
for match arms already handles both `Ref` and `RefMut` correctly.
UnsafePinned: implement opsem effects of UnsafeUnpin
This implements the next step for https://github.com/rust-lang/rust/issues/125735: actually making `UnsafePinned` have special opsem effects by suppressing the `noalias` *even if* the type is wrapped in an `Unpin` wrapper.
For backwards compatibility we also still keep the `Unpin` hack, i.e. a type must be both `Unpin` and `UnsafeUnpin` to get `noalias`.
the command 'cargo build --no-default-features --features borsh' failed with:
error[E0599]: no function or associated item named 'other' found for struct 'borsh::io::Error' in the current scope
--> lib/smol_str/src/borsh.rs:33:39
|
33 | .ok_or_else(|| Error::other("u8::vec_from_reader unexpectedly returned None"))?;
| ^^^^^ function or associated item not found in 'borsh::io::Error'
|
