| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Migrate `generate new` assist to use `SyntaxEditor`
|
|
|
|
The previous manual parsing of `serde_json::Value` was a lot of
complicated code and extremely error-prone. It was full of janky
behavior like sometimes ignoring type errors, sometimes erroring for
type errors, sometimes warning for type errors, and sometimes just
ICEing for type errors (the icing on the top).
Additionally, many of the error messages about allowed values were out
of date because they were in a completely different place than the
FromStr impls. Overall, the system caused confusion for users.
I also found the old deserialization code annoying to read. Whenever a
`key!` invocation was found, one had to first look for the right macro
arm, and no go to definition could help.
This PR replaces all this manual parsing with a 2-step process involving
serde.
First, the string is parsed into a `TargetSpecJson` struct. This struct
is a 1:1 representation of the spec JSON. It already parses all the
enums and is very simple to read and write.
Then, the fields from this struct are copied into the actual `Target`.
The reason for this two-step process instead of just serializing into a
`Target` is because of a few reasons
1. There are a few transformations performed between the two formats
2. The default logic is implemented this way. Otherwise all the default
field values would have to be spelled out again, which is
suboptimal. With this logic, they fall out naturally, because
everything in the json struct is an `Option`.
Overall, the mapping is pretty simple, with the vast majority of fields
just doing a 1:1 mapping that is captured by two macros. I have
deliberately avoided making the macros generic to keep them simple.
All the `FromStr` impls now have the error message right inside them,
which increases the chance of it being up to date. Some "`from_str`"
impls were turned into proper `FromStr` impls to support this.
The new code is much less involved, delegating all the JSON parsing
logic to serde, without any manual type matching.
This change introduces a few breaking changes for consumers. While it is
possible to use this format on stable, it is very much subject to
change, so breaking changes are expected. The hope is also that because
of the way stricter behavior, breaking changes are easier to deal with,
as they come with clearer error messages.
1. Invalid types now always error, everywhere. Previously, they would
sometimes error, and sometimes just be ignored (which meant the users
JSON was still broken, just silently!)
2. This now makes use of `deny_unknown_fields` instead of just warning
on unused fields, which was done previously. Serde doesn't make it
easy to get such warning behavior, which was the primary reason that
this now changed. But I think error behavior is very reasonable too.
If someone has random stale fields in their JSON, it is likely
because these fields did something at some point but no longer do,
and the user likely wants to be informed of this so they can figure
out what to do.
This is also relevant for the future. If we remove a field but
someone has it set, it probably makes sense for them to take a look
whether they need this and should look for alternatives, or whether
they can just delete it. Overall, the JSON is made more explicit.
This is the only expected breakage, but there could also be small
breakage from small mistakes. All targets roundtrip though, so it can't
be anything too major.
|
|
opt-dist: make `artifact-dir` an absolute path for `opt-dist local`
...like for CI environments. the same logic applied as for `build_dir`. fixes the issue where some intermediate steps fail due to path being relative to an active directory
r? Kobzol
try-job: dist-x86_64-msvc
try-job: dist-x86_64-linux
|
|
Subtree update of `rust-analyzer`
r? ```@ghost```
|
|
fix handling of base address for TypeId allocations
This fixes the problems discovered by ````@theemathas```` in https://github.com/rust-lang/rust/pull/142789:
- const-eval would sometimes consider TypeId pointers to be null
- the type ID is different in Miri than in regular executions
Both boil down to the same issue: the TypeId "allocation" has a guaranteed 0 base address, but const-eval assumes it was non-zero (like normal allocations) and Miri randomized it (like normal allocations).
r? ````@oli-obk````
|
|
Mitigate `#[align]` name resolution ambiguity regression with a rename
Mitigates beta regression rust-lang/rust#143834 after a beta backport.
### Background on the beta regression
The name resolution regression arises due to rust-lang/rust#142507 adding a new feature-gated built-in attribute named `#[align]`. However, unfortunately even [introducing new feature-gated unstable built-in attributes can break user code](https://www.github.com/rust-lang/rust/issues/134963) such as
```rs
macro_rules! align {
() => {
/* .. */
};
}
pub(crate) use align; // `use` here becomes ambiguous
```
### Mitigation approach
This PR renames `#[align]` to `#[rustc_align]` to mitigate the beta regression by:
1. Undoing the introduction of a new built-in attribute with a common name, i.e. `#[align]`.
2. Renaming `#[align]` to `#[rustc_align]`. The renamed attribute being `rustc_align` will not introduce new stable breakages, as attributes beginning with `rustc` are reserved and perma-unstable. This does mean existing nightly code using `fn_align` feature will additionally need to specify `#![feature(rustc_attrs)]`.
This PR is very much a short-term mitigation to alleviate time pressure from having to fully fix the current limitation of inevitable name resolution regressions that would arise from adding any built-in attributes. Long-term solutions are discussed in [#t-lang > namespacing macro attrs to reduce conflicts with new adds](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/namespacing.20macro.20attrs.20to.20reduce.20conflicts.20with.20new.20adds/with/529249622).
### Alternative mitigation options
[Various mitigation options were considered during the compiler triage meeting](https://github.com/rust-lang/rust/issues/143834#issuecomment-3084415277), and those consideration are partly reproduced here:
- Reverting the PR doesn't seem very minimal/trivial, and carries risks of its own.
- Rename to a less-common but aim-to-stabilization name is itself not safe nor convenient, because (1) that risks introducing new regressions (i.e. ambiguity against the new name), and (2) lang would have to FCP the new name hastily for the mitigation to land timely and have a chance to be backported. This also makes the path towards stabilization annoying.
- Rename the attribute to a rustc attribute, which will be perma-unstable and does not cause new ambiguities in stable code.
- This alleviates the time pressure to address *this* regression, or for lang to have to rush an FCP for some new name that can still break user code.
- This avoids backing out a whole implementation.
### Review advice
This PR is best reviewed commit-by-commit.
- Commit 1 adds a test `tests/ui/attributes/fn-align-nameres-ambiguity-143834.rs` which demonstrates the current name resolution regression re. `align`. This test fails against current master.
- Commit 2 carries out the renames and test reblesses. Notably, commit 2 will cause `tests/ui/attributes/fn-align-nameres-ambiguity-143834.rs` to change from fail (nameres regression) to pass.
This PR, if the approach still seems acceptable, will need a beta-backport to address the beta regression.
|
|
clippy: make tests work in stage 1
This finally fixes https://github.com/rust-lang/rust/issues/78717 :)
Similar to what Miri already does, the clippy test step needs to carefully consider which compiler is used to build clippy and which compiler is linked into clippy (and thus must be used to build the test dependencies). On top of that we have some extra complications that Miri avoided by using `cargo-miri` for building its test dependencies: we need cargo to use the right rustc and the right sysroot, but https://github.com/rust-lang/cargo/issues/4423 makes this quite hard to do. See the long comment in `src/tools/clippy/tests/compile-test.rs` for details.
Some clippy tests tried to import rustc crates; that fundamentally requires a full bootstrap loop so it cannot work in stage 1. I had to kind of guess what those tests were doing so I don't know if my changes there make any sense.
Cc ```@flip1995``` ```@Kobzol```
|
|
gpu offload host code generation
r? ghost
This will generate most of the host side code to use llvm's offload feature.
The first PR will only handle automatic mem-transfers to and from the device.
So if a user calls a kernel, we will copy inputs back and forth, but we won't do the actual kernel launch.
Before merging, we will use LLVM's Info infrastructure to verify that the memcopies match what openmp offloa generates in C++. `LIBOMPTARGET_INFO=-1 ./my_rust_binary` should print that a memcpy to and later from the device is happening.
A follow-up PR will generate the actual device-side kernel which will then do computations on the GPU.
A third PR will implement manual host2device and device2host functionality, but the goal is to minimize cases where a user has to overwrite our default handling due to performance issues.
I'm trying to get a full MVP out first, so this just recognizes GPU functions based on magic names. The final frontend will obviously move this over to use proper macros, like I'm already doing it for the autodiff work.
This work will also be compatible with std::autodiff, so one can differentiate GPU kernels.
Tracking:
- https://github.com/rust-lang/rust/issues/131513
|
|
fix: Apply adjusts to pats and exprs when doing pat analysis
|
|
|
|
This fixes the rustc build on x32 for which struct sizes differ.
|
|
fix: Disable tests in flycheck if `cfg.setTest` is set to false
|
|
|
|
non-deterministically truncate reads/writes
|
|
in MSYS2 we have problems with stage0 for *-gnullvm hosts because prebuilt dist tarballs will be
available starting from 1.90.0-beta. also this change helps to match bootstrap.toml config
|
|
...like for CI environments. the same logic applied as for `build_dir`. fixes the issue where some
intermediate steps fail due to path being relative to an active directory
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#144144 (tests: Skip supported-crate-types test on musl hosts)
- rust-lang/rust#144159 (opt-dist: change build_dir field to be an actual build dir)
- rust-lang/rust#144162 (Debug impls for DropElaborators)
- rust-lang/rust#144189 (Add non-regression test for rust-lang/rust#144168)
- rust-lang/rust#144216 (Don't consider unstable fields always-inhabited)
- rust-lang/rust#144229 (Miri subtree update)
- rust-lang/rust#144230 (Option::as_slice: fix comment)
- rust-lang/rust#144235 (Fix run-make tests on musl hosts)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
This reverts commit 9f3adc540b51a4c2d0472d94033f6d9147b36f6e.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add Deref -> DerefMut for generate_mut_trait_impl
|
|
fix: Fix search of raw labels and lifetimes
|
|
Fix run-make tests on musl hosts
On musl hosts, we already set `-Ctarget-feature=-crt-static` and `IS_MUSL_HOST=1` in compiletest. However, in order for the run-make tests to compile fine on musl hosts, we need to propagate this flag in our rustc invocations to ensure we can generate cdylibs.
|
|
Miri subtree update
r? `@ghost`
|
|
opt-dist: change build_dir field to be an actual build dir
make it configurable so users can set build.build-dir option in bootstrap.toml
r? Kobzol
try-job: dist-x86_64-msvc
try-job: dist-x86_64-linux
|
|
Ban projecting into SIMD types [MCP838]
Closes https://github.com/rust-lang/compiler-team/issues/838
The actual compiler change here is tiny; there's just a bazillion tests to update.
~~Since I'm sure I've missed some, for now~~
~~r ghost~~
try-job: test-various
try-job: x86_64-gnu-nopt
|
|
On musl hosts, we already set -Ctarget-feature=-crt-static and
IS_MUSL_HOST=1 in compiletest. However, in order for the run-make tests
to compile fine on musl hosts, we need to propagate this flag in our
rustc invocations to ensure we can generate cdylibs.
Signed-off-by: Jens Reidel <adrian@travitia.xyz>
|
|
|
|
|
|
make it configurable so users can set build.build-dir option in bootstrap.toml
|
|
|
|
Weekly `cargo update`
Automation to keep dependencies in `Cargo.lock` current.
r? dep-bumps
The following is the output from `cargo update`:
```txt
compiler & tools dependencies:
Locking 15 packages to latest compatible versions
Updating chrono-tz v0.10.3 -> v0.10.4
Removing chrono-tz-build v0.4.1
Updating clap v4.5.40 -> v4.5.41
Updating clap_builder v4.5.40 -> v4.5.41
Updating clap_derive v4.5.40 -> v4.5.41
Updating crc32fast v1.4.2 -> v1.5.0
Updating derive_setters v0.1.7 -> v0.1.8
Updating libredox v0.1.4 -> v0.1.6
Updating measureme v12.0.1 -> v12.0.3
Removing parse-zoneinfo v0.3.1
Adding phf v0.12.1
Adding phf_shared v0.12.1
Updating rustix v1.0.7 -> v1.0.8
Updating serde_json v1.0.140 -> v1.0.141
Updating sysinfo v0.36.0 -> v0.36.1
Updating wasi-preview1-component-adapter-provider v34.0.1 -> v34.0.2
Updating winnow v0.7.11 -> v0.7.12
note: pass `--verbose` to see 39 unchanged dependencies behind latest
library dependencies:
Locking 0 packages to latest compatible versions
note: pass `--verbose` to see 3 unchanged dependencies behind latest
rustbook dependencies:
Locking 13 packages to latest compatible versions
Updating ammonia v4.1.0 -> v4.1.1
Updating cc v1.2.29 -> v1.2.30
Updating clap v4.5.40 -> v4.5.41
Updating clap_builder v4.5.40 -> v4.5.41
Updating clap_complete v4.5.54 -> v4.5.55
Updating clap_derive v4.5.40 -> v4.5.41
Updating crc32fast v1.4.2 -> v1.5.0
Updating html5ever v0.31.0 -> v0.35.0
Updating markup5ever v0.16.2 -> v0.35.0
Updating match_token v0.1.0 -> v0.35.0
Updating rustix v1.0.7 -> v1.0.8
Updating serde_json v1.0.140 -> v1.0.141
Updating winnow v0.7.11 -> v0.7.12
```
|
|
Give a message with a span on MIR validation error
It was handy to get a source+line link for rust-lang/rust#143833, even if it's just to the function and not necessarily to the statement.
r? mir
|
|
Add new `ignore-backends` and `needs-backends` tests annotations
Part of https://github.com/rust-lang/compiler-team/issues/891.
Next step will be to add these annotations in the files where either the output is different based on the codegen (like `asm` tests) or that are known to fail in the GCC backend.
cc `@oli-obk` `@antoyo`
r? `@Kobzol`
|
|
|
|
|
|
|
|
Fix ide-assist: generate Deref transitive
|
|
|
|
interpret: fix TypeId pointers being considered data pointers
Fixes https://github.com/rust-lang/miri/issues/4477
r? ````@oli-obk````
|
|
Cleanup unicode table gen
Fixing clippy warnings and moving to edition 2024.
|
