| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
before_terminator: add some minor clarifying comments
|
|
|
|
fix test running by invoking cargo per package
remove hack_recover_crate_name
make clippy happy
fix testing for packages with multiple targets
fix test running by invoking cargo per package
remove hack_recover_crate_name
make clippy happy
fix testing for packages with multiple targets
fix bad merge
replace TargetKind::fmt with TargetKind::as_cargo_target to clarify intention
dedupulicate requested test runs
replace ParseFromLine with CargoParser
formatting - remove trailing space
formatting for rustfmt CI
|
|
|
|
internal: set up Zig on CI and start using it in rust-analyzer
|
|
Allow rust-project.json to specify sysroot workspace
|
|
|
|
- Remove the `Option` from the result type, as `None` is never returned.
- Document the difference from the `BindingMode` in `PatKind::Binding`.
|
|
r=spastorino
Make `AssocOp` more like `ExprKind`
This is step 1 of [MCP 831](https://github.com/rust-lang/compiler-team/issues/831).
r? ``@estebank``
|
|
[`compiletest`-related cleanups 4/7] Make the distinction between root build directory vs test suite specific build directory in compiletest less confusing
Reference for overall changes: https://github.com/rust-lang/rust/pull/136437
Part **4** of **7** of the *`compiletest`-related cleanups* PR series.
### Summary
- Remove `--build-base` compiletest flag, and introduce `--build-{root,test-suite-root}` flags instead. `--build-base` previously actually is test suite specific build directory, not the root `build/` directory.
- Feed the root build directory directly from bootstrap to compiletest via `--build-root` instead of doing multiple layers of parent unwrapping[^parent] based on the test suite specific build directory.
- Remove a redundant `to_path_buf()`.
[^parent]: Please do not unwrap the parents.
r? bootstrap
|
|
|
|
To match `ExprKind::Cast`, and because a semantic name makes more sense
here than a syntactic name.
|
|
It makes `AssocOp` more similar to `ExprKind` and makes things a little
simpler. And the semantic names make more sense here than the syntactic
names.
|
|
It mirrors `ExprKind::Binary`, and contains a `BinOpKind`. This makes
`AssocOp` more like `ExprKind`. Note that the variants removed from
`AssocOp` are all named differently to `BinOpToken`, e.g. `Multiply`
instead of `Mul`, so that's an inconsistency removed.
The commit adds `precedence` and `fixity` methods to `BinOpKind`, and
calls them from the corresponding methods in `AssocOp`. This avoids the
need to create an `AssocOp` from a `BinOpKind` in a bunch of places, and
`AssocOp::from_ast_binop` is removed.
`AssocOp::to_ast_binop` is also no longer needed.
Overall things are shorter and nicer.
|
|
`AssocOp::AssignOp` contains a `BinOpToken`. `ExprKind::AssignOp`
contains a `BinOpKind`. Given that `AssocOp` is basically a cut-down
version of `ExprKind`, it makes sense to make `AssocOp` more like
`ExprKind`. Especially given that `AssocOp` and `BinOpKind` use semantic
operation names (e.g. `Mul`, `Div`), but `BinOpToken` uses syntactic
names (e.g. `Star`, `Slash`).
This results in more concise code, and removes the need for various
conversions. (Note that the removed functions `hirbinop2assignop` and
`astbinop2assignop` are semantically identical, because `hir::BinOp` is
just a synonum for `ast::BinOp`!)
The only downside to this is that it allows the possibility of some
nonsensical combinations, such as `AssocOp::AssignOp(BinOpKind::Lt)`.
But `ExprKind::AssignOp` already has that problem. The problem can be
fixed for both types in the future with some effort, by introducing an
`AssignOpKind` type.
|
|
|
|
|
|
raw-dylib is a link kind that allows rustc to link against a library
without having any library files present.
This currently only exists on Windows. rustc will take all the symbols
from raw-dylib link blocks and put them in an import library, where they
can then be resolved by the linker.
While import libraries don't exist on ELF, it would still be convenient
to have this same functionality. Not having the libraries present at
build-time can be convenient for several reasons, especially
cross-compilation. With raw-dylib, code linking against a library can be
cross-compiled without needing to have these libraries available on the
build machine. If the libc crate makes use of this, it would allow
cross-compilation without having any libc available on the build
machine. This is not yet possible with this implementation, at least
against libc's like glibc that use symbol versioning.
The raw-dylib kind could be extended with support for symbol versioning
in the future.
This implementation is very experimental and I have not tested it very
well. I have tested it for a toy example and the lz4-sys crate, where it
was able to successfully link a binary despite not having a
corresponding library at build-time.
|
|
|
|
doc: remove nit from setup.md
|
|
|
|
internal: Migrate some low-hanging `remove_*` assists to `SyntaxEditor`
|
|
|
|
Resolve more FIXMEs
|
|
Allow "package/feature" format feature flag
|
|
|
|
|
|
|
|
|
|
Miri subtree update
r? `@ghost`
try-job: x86_64-gnu-aux
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
