| Age | Commit message (Collapse) | Author | Lines |
|---|
|
remove attribute ids from hir stats (they're simply not needed)
Turns out these are simply not needed. Yay!
r? `@nnethercote`
|
|
Reduce dependence on the target name
The target name can be anything with custom target specs. Matching on fields inside the target spec is much more robust than matching on the target name.
Also remove the unused is_builtin target spec field.
|
|
remove const-support for align_offset and is_aligned
As part of the recent discussion to stabilize `ptr.is_null()` in const context, the general vibe was that it's okay for a const function to panic when the same operation would work at runtime (that's just a case of "dynamically detecting that something is not supported as a const operation"), but it is *not* okay for a const function to just return a different result.
Following that, `is_aligned` and `is_aligned_to` have their const status revoked in this PR, since they do return actively wrong results at const time. In the future we can consider having a new intrinsic or so that can check whether a pointer is "guaranteed to be aligned", but the current implementation based on `align_offset` does not have the behavior we want.
In fact `align_offset` itself behaves quite strangely in const, and that support needs a bunch of special hacks. That doesn't seem worth it. Instead, the users that can fall back to a different implementation should just use const_eval_select directly, and everything else should not be made const-callable. So this PR does exactly that, and entirely removes const support for align_offset.
Closes some tracking issues by removing the associated features:
Closes https://github.com/rust-lang/rust/issues/90962
Closes https://github.com/rust-lang/rust/issues/104203
Cc `@rust-lang/wg-const-eval` `@rust-lang/libs-api`
|
|
Generate correct symbols.o for sparc-unknown-none-elf
This fixes #130172 by selecting the correct ELF Machine type for sparc-unknown-none-elf (which has a baseline of SPARC V7).
|
|
Rollup of 6 pull requests
Successful merges:
- #126136 (Call the target libdir target libdir)
- #132516 (Add bad-reg inline assembly ui test for RISC-V and s390x)
- #132521 (replace manual time convertions with std ones, comptime time format parsing)
- #132560 (Remove outdated tidy license fixmes)
- #132563 (Modify `NonZero` documentation to reference the underlying integer type)
- #132574 (compiler: Directly use rustc_abi almost everywhere)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
compiler: Directly use rustc_abi almost everywhere
Use rustc_abi instead of rustc_target where applicable. This is mostly described by the following substitutions:
```rust
match path_substring {
rustc_target::spec::abi::Abi => rustc_abi::ExternAbi,
rustc_target::abi::call => rustc_target::callconv,
rustc_target::abi => rustc_abi,
}
```
A number of spot-fixes make that not quite the whole story.
The main exception is in 33edc68 where I get a lot more persnickety about how things are imported, especially in `rustc_middle::ty::layout`, not just from where. This includes putting an end to a reexport of `rustc_middle::ty::ReprOptions`, for the same reason that the rest of this change is happening: reexports mostly confound things.
This notably omits rustc_passes and the ast crates, as I'm still examining a question I have about how they do stability checking of `extern "Abi"` strings and if I can simplify their logic. The rustc_abi and rustc_target crates also go untouched because they will be entangled in that cleanup.
r? compiler-errors
|
|
Modify `NonZero` documentation to reference the underlying integer type
This change updates the documentation for `NonZero` integer types to explicitly reference the underlying integer type each `NonZero` variant wraps, instead of using a general "integer" term.
**Before**
**After**
|
|
Remove outdated tidy license fixmes
~~This PR re-enables license dependency checking for:~~
- ~~the `backtrace` submodule~~
- ~~and the `portable-simd` subtree~~
~~The `stdarch` submodule doesn't have a `Cargo.lock` yet so we can't re-enable it.~~
This PR removes outdated tidy license fixmes, https://github.com/rust-lang/rust/pull/132560#issuecomment-2453525276.
r? bootstrap
|
|
replace manual time convertions with std ones, comptime time format parsing
First commit replaces few manual time conversions with std ones, second makes parsing of time format at compiletime.
|
|
Add bad-reg inline assembly ui test for RISC-V and s390x
https://github.com/rust-lang/rust/pull/131341#discussion_r1826555431
> Btw, such unsupported registers are present in most architectures, but only aarch64/arm64ec, x86_64, and not yet merged [sparc/sparc64](https://github.com/rust-lang/rust/pull/132472/files#diff-02aebda3376c2b020265137f9ce2c387669ca5cfecd7d60494275c2387db5114) (and powerpc/powerpc64 by this PR) currently have ui tests for them. I plan to add tests for other arches later.
Starting with RISC-V and s390x, which I'm familiar with and relatively easy to check for correctness.
(Relevant rustc code are supported_types/def_regs/overlapping_regs in [compiler/rustc_target/src/asm/riscv.rs](https://github.com/rust-lang/rust/blob/588a4203508ed7c76750c96b482641261630ed36/compiler/rustc_target/src/asm/riscv.rs) and [compiler/rustc_target/src/asm/s390x.rs](https://github.com/rust-lang/rust/blob/588a4203508ed7c76750c96b482641261630ed36/compiler/rustc_target/src/asm/s390x.rs).)
r? workingjubilee
`@rustbot` label +A-inline-assembly
|
|
Call the target libdir target libdir
Because it's the target libdir.
`--print` uses the same terminology, and it's a simple way to make it obviously different from `$sysroot/lib`.
|
|
Make `std::os::darwin` public
I'm not sure of the reasoning behind them not being public before, but I think they should be, just like `std::os::ios` and `std::os::macos` are public.
Additionally, I've merged their source code, as it was otherwise just a bunch of unnecessary duplication.
Ultimately, I've done this PR to fix `./x build library --target=aarch64-apple-tvos,aarch64-apple-watchos,aarch64-apple-visionos`, as that currently fails because of dead code warnings.
Since you reviewed https://github.com/rust-lang/rust/pull/121419
r? davidtwco
Fixes https://github.com/rust-lang/rust/issues/121640.
`@rustbot` label O-tvos O-watchos O-visionos
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Stop reexporting ReprOptions from middle::ty
|
|
|
|
|
|
|
|
It is unused.
|
|
|
|
Yeet the `effects` feature, move it onto `const_trait_impl`
This PR merges the `effects` feature into the `const_trait_impl` feature. There's really no need to have two feature gates for one feature.
After this PR, if `const_trait_impl` **is** enabled:
* Users can use and define const traits
* `HostEffect` const conditions will be enforced on the HIR
* We re-check the predicates in MIR just to make sure that we don't "leak" anything during MIR lowering
And if `const_trait_impl` **is not** enabled:
* Users cannot use nor define const traits
* `HostEffect` const conditions are not enforced on the HIR
* We will raise a const validation error if we call a function that has any const conditions (i.e. const traits and functions with any `~const` in their where clasues)
This should be the last step for us to be able to enable const traits in the standard library. We still need to re-constify `Drop` and `Destruct` and stuff for const traits to be particularly *useful* for some cases, but this is a good step :D
r? fee1-dead
cc `@rust-lang/project-const-traits`
|
|
|
|
|
|
|
|
|
|
The target name can be anything with custom target specs. Matching on
fields inside the target spec is much more robust than matching on the
target name.
|
|
add const_panic macro to make it easier to fall back to non-formatting panic in const
Suggested by `@tgross35`
r? `@tgross35`
|
|
Operations like is_aligned would return actively wrong results at compile-time,
i.e. calling it on the same pointer at compiletime and runtime could yield
different results. That's no good.
Instead of having hacks to make align_offset kind-of work in const-eval, just
use const_eval_select in the few places where it makes sense, which also ensures
those places are all aware they need to make sure the fallback behavior is
consistent.
|
|
This change updates the documentation for `NonZero` integer types to
explicitly reference the underlying integer type each `NonZero` variant
wraps, instead of using a general "integer" term.
|
|
Rollup of 15 pull requests
Successful merges:
- #129329 (Implement `From<&mut {slice}>` for `Box/Rc/Arc<{slice}>`)
- #131377 (Add LowerExp and UpperExp implementations to NonZero)
- #132393 (Docs: added brief colon explanation)
- #132437 (coverage: Regression test for inlining into an uninstrumented crate)
- #132499 (unicode_data.rs: show command for generating file)
- #132503 (better test for const HashMap; remove const_hash leftovers)
- #132511 (stabilize const_arguments_as_str)
- #132520 (NFC add known bug nr to test)
- #132522 (make codegen help output more consistent)
- #132523 (Added regression test for generics index out of bounds)
- #132528 (Use `*_opt` typeck results fns to not ICE in fallback suggestion)
- #132537 (PassWrapper: adapt for llvm/llvm-project@5445edb5d)
- #132540 (Do not format generic consts)
- #132543 (add and update some crashtests)
- #132550 (compiler: Continue introducing rustc_abi to the compiler)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
Port most of `--print=target-cpus` to Rust
The logic and formatting needed by `--print=target-cpus` has historically been carried out in C++ code. Originally it used `printf` to write directly to the console, but later it switched over to writing to a `std::ostringstream` and then passing its buffer to a callback function pointer.
This PR replaces that C++ code with a very simple function that writes a list of CPU names to a `&RustString`, with the rest of the logic and formatting being handled by ordinary safe Rust code.
|
|
workingjubilee:rustc-abi-selects-borrowck-for-mono-sans, r=compiler-errors
compiler: Continue introducing rustc_abi to the compiler
Some crates have not heard of rustc_abi before, so arrange introductions.
Encourage some crates to go further and leave rustc_target behind: it was no good for them.
|
|
add and update some crashtests
Adds tests for #126268 and #132126, updates it for #131050.
|
|
Do not format generic consts
We introduced **nightly support** for generic const items in #113522, but formatting of consts was not modified. Making them format *correctly* is hard, so let's just bail formatting them so we don't accidentally strip their generics and where clauses. This is essentially no-op formatting for generic const items.
r? `````@calebcartwright````` or `````@ytmimi`````
|
|
PassWrapper: adapt for llvm/llvm-project@5445edb5d
As with ab5583ed1e75869b765a90386dac9119992f8ed7, we had been explicitly passing defaults whose type have changed. Rather than do an ifdef, we simply rely on the defaults.
````@rustbot```` label: +llvm-main
|
|
Use `*_opt` typeck results fns to not ICE in fallback suggestion
Self-explanatory. Fixes #132517.
|
|
Added regression test for generics index out of bounds
Added a regression test for #117446
This ICE was fixed in Rust 1.75 but a regression test was never added.
This PR adds a UI test with a reduced version of the original bug report that does not rely on external crates.
|
|
make codegen help output more consistent
The output of `rustc -C help` generally has one option per line. There was one exception because of a (presumably) forgotten line continuation escape.
|
|
NFC add known bug nr to test
r? ```````@jieyouxu```````
|
|
stabilize const_arguments_as_str
FCP passed in the [tracking issue](https://github.com/rust-lang/rust/issues/103900#issuecomment-2397096659).
|
|
better test for const HashMap; remove const_hash leftovers
The existing `const_with_hasher` test is kind of silly since the HashMap it constructs can never contain any elements. So this adjusts the test to construct a usable HashMap, which is a bit non-trivial since the default hash builder cannot be built in `const`. `BuildHasherDefault::new()` helps but is unstable (https://github.com/rust-lang/rust/issues/123197), so we also have a test that does not involve that type.
The second commit removes the last remnants of https://github.com/rust-lang/rust/issues/104061, since they aren't actually useful -- without const traits, you can't do any hashing in `const`.
Cc ``@rust-lang/libs-api`` ``@rust-lang/wg-const-eval``
Closes #104061
Related to https://github.com/rust-lang/rust/issues/102575
|
|
unicode_data.rs: show command for generating file
https://github.com/rust-lang/rust/pull/131647 made this an easily runnable tool, now we just have to mention that in the comment. :)
Fixes https://github.com/rust-lang/rust/issues/131640.
|
|
coverage: Regression test for inlining into an uninstrumented crate
Regression test for #132395, after I was able to figure out a simple way to reproduce it. See also #132436.
In addition to confirming that there is no ICE, this test also demonstrates that the affected code is undercounted, because executing the inlined copy doesn't increment coverage counters.
|
