| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Rollup of 5 pull requests
Successful merges:
- #127879 (Document futility of printing temporary pointers)
- #130325 (Use -0.0 in `intrinsics::simd::reduce_add_unordered`)
- #130336 (simplify `Build::update_existing_submodule`)
- #130398 (Add system libs for LLVM when cross compiling for Windows)
- #130420 (Register tool docs for `src/tools/build_helper`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Register tool docs for `src/tools/build_helper`
Fixes #130355.
|
|
Add system libs for LLVM when cross compiling for Windows
Windows uses "import libraries" to link to system libraries. These are a kind of static lib that are distributed with the Windows SDK and therefore they don't rely on the host. All that matters is you have the right SDK installed for the target.
|
|
simplify `Build::update_existing_submodule`
`Build::update_existing_submodule` is already doing the same thing..
|
|
r=RalfJung,jieyouxu
Use -0.0 in `intrinsics::simd::reduce_add_unordered`
-0.0 is the actual neutral additive float, not +0.0, and this matters to codegen.
try-job: aarch64-gnu
|
|
Document futility of printing temporary pointers
In the user forum I've seen a few people trying to understand how borrowing and moves are implemented by peppering their code with printing of `{:p}` of references to variables and expressions. This is a bad idea. It gives misleading and confusing results, because of autoderef magic, printing pointers of temporaries on the stack, and/or causes LLVM to optimize code differently when values had their address exposed.
|
|
simplify float::classify logic
I played around with the float-classify test in the hope of triggering x87 bugs by strategically adding `black_box`, and still the exact expression `@beetrees` suggested [here](https://github.com/rust-lang/rust/pull/129835#issuecomment-2325661597) remains the only case I found where we get the wrong result on x87. Curiously, this bug only occurs when MIR optimizations are enabled -- probably the extra inlining that does is required for LLVM to hit the right "bad" case in the backend. But even for that case, it makes no difference whether `classify` is implemented in the simple bit-pattern-based version or the more complicated version we had before.
Without even a single testcase that can distinguish our `classify` from the naive version, I suggest we switch to the naive version.
|
|
Update cargo
25 commits in c1fa840a85eca53818895901a53fae34247448b2..a9a418d1a22f29e7dfd034e3b93f15657e608a29
2024-08-29 21:03:53 +0000 to 2024-09-15 19:13:12 +0000
- chore: revert change to Cargo.lock in f25806c (rust-lang/cargo#14547)
- Disable the shell_completions tests (rust-lang/cargo#14546)
- fix(vendor): trust crate version only when coming from registries (rust-lang/cargo#14530)
- docs: Feature resolver version 2: clarify use of 'target' (rust-lang/cargo#14540)
- Update docs for how cargo is published (rust-lang/cargo#14539)
- feat: Add native comlpetion with CompleteEnv under the nightly (rust-lang/cargo#14493)
- fix(new): Add to workspace relative to manifest, not current-dir (rust-lang/cargo#14505)
- Fix parsing of comma separated values in --crate-type flag (rust-lang/cargo#14499)
- Include public/private dependency status in `cargo metadata` (rust-lang/cargo#14504)
- Remove unnecessary symbols (rust-lang/cargo#14519)
- docs: bin source can be `src/main.rs` and/or in `src/bin/` (rust-lang/cargo#14515)
- fix(toml): Don't require MSRV bump for pub/priv (rust-lang/cargo#14507)
- bail before packaging on same version (rust-lang/cargo#14448)
- Implement path-bases (RFC 3529) 2/n: `cargo [add|remove|update]` support (rust-lang/cargo#14427)
- Publish workspace (rust-lang/cargo#14433)
- Bump ci's version of cargo-semver-version (rust-lang/cargo#14503)
- Document -Zpackage-workspace (rust-lang/cargo#14496)
- uplift windows gnullvm import libraries (rust-lang/cargo#14451)
- Bump to 0.84.0; update changelog (rust-lang/cargo#14495)
- Fix cargo add behaving different when translating package name (rust-lang/cargo#13765)
- chore(deps): update rust crate core-foundation to 0.10.0 (rust-lang/cargo#14475)
- feat(resolve): Report MSRV compatible version instead of incomptible (rust-lang/cargo#14471)
- Don't automatically include the current crate when packaging (rust-lang/cargo#14488)
- Fix elided lifetime (rust-lang/cargo#14487)
- chore(deps): update rust crate pasetors to 0.7.0 (rust-lang/cargo#14478)
|
|
|
|
-0.0 is the actual neutral additive float, not +0.0, and this matters to codegen.
|
|
Rollup of 3 pull requests
Successful merges:
- #130151 (Use a small runner for msvc-ext2 job)
- #130394 (const: don't ICE when encountering a mutable ref to immutable memory)
- #130409 (tests: more ice tests)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
tests: more ice tests
r? `@jieyouxu`
|
|
const: don't ICE when encountering a mutable ref to immutable memory
Turns out that this can actually happen -- thanks to `@matthiaskrgr` for producing a testcase. :)
Fixes https://github.com/rust-lang/rust/issues/130392
|
|
Use a small runner for msvc-ext2 job
Hopefully this should eliminate the errors from this job. The only question is how long it takes.
try-job: x86_64-msvc-ext2
|
|
|
|
|
|
Rollup of 3 pull requests
Successful merges:
- #129897 (deprecate -Csoft-float because it is unsound (and not fixable))
- #130339 (Add `core::panic::abort_unwind`)
- #130384 (compiler: Document AbiAndPrefAlign)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
workingjubilee:document-what-abi-and-pref-align-is, r=compiler-errors
compiler: Document AbiAndPrefAlign
The mere existence of this struct is confusing, and the second field doubly so. It's easy to mistake the "preferred" alignment as semantically relevant somehow. Insofar as I am aware, it is not, and certainly not for Rust code.
|
|
Add `core::panic::abort_unwind`
`abort_unwind` is like `catch_unwind` except that it aborts the process if it unwinds, using the `#[rustc_nounwind]` mechanism also used by `extern "C" fn` to abort unwinding. The docs attempt to make it clear when to (rarely) and when not to (usually) use the function.
Although usage of the function is discouraged, having it available will help to normalize the experience when abort_unwind shims are hit, as opposed to the current ecosystem where there exist multiple common patterns for converting unwinding into a process abort.
For further information and justification, see the linked ACP.
- Tracking issue: https://github.com/rust-lang/rust/issues/130338
- ACP: https://github.com/rust-lang/libs-team/issues/441
|
|
deprecate -Csoft-float because it is unsound (and not fixable)
See https://github.com/rust-lang/rust/issues/129893 for details. The general sentiment there seems to be that this flag has no use and sound alternatives exist, so let's add this warning and see if anyone out there disagrees.
Also show a different warning on targets where it does nothing (as documented since https://github.com/rust-lang/rust/pull/36261): it seems to correspond to `-mfloat-abi` in GCC/clang, which is an ARM-specific option. To be really sure it does nothing, only forward the flag to LLVM for eabihf targets. This should not change behavior but makes me sleep better ;)
|
|
Co-authored-by: David Tolnay <dtolnay@gmail.com>
|
|
Rollup of 5 pull requests
Successful merges:
- #129439 (Implement feature `string_from_utf8_lossy_owned` for lossy conversion from `Vec<u8>` to `String` methods)
- #129828 (miri: treat non-memory local variables properly for data race detection)
- #130110 (make dist vendoring configurable)
- #130293 (Fix lint levels not getting overridden by attrs on `Stmt` nodes)
- #130342 (interpret, miri: fix dealing with overflow during slice indexing and allocation)
Failed merges:
- #130394 (const: don't ICE when encountering a mutable ref to immutable memory)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
interpret, miri: fix dealing with overflow during slice indexing and allocation
This is mostly to fix https://github.com/rust-lang/rust/issues/130284.
I then realized we're using somewhat sketchy arguments for a similar multiplication in `copy`/`copy_nonoverlapping`/`write_bytes`, so I made them all share the same function that checks exactly the right thing. (The intrinsics would previously fail on allocations larger than `1 << 47` bytes... which are theoretically possible maybe? Anyway it seems conceptually wrong to use any other bound than `isize::MAX` here.)
|
|
Fix lint levels not getting overridden by attrs on `Stmt` nodes
Fixes #130142. See comments on the issue for context.
r? `@cjgillot`
|
|
r=Kobzol,Mark-Simulacrum
make dist vendoring configurable
Adds a new option `dist.vendor` which allows people to decide whether to vendor dependencies for their custom distribution tarball builds. Note that our builds will not be affected, as the default for this option is the same as the previous vendoring condition from bootstrap.
|
|
miri: treat non-memory local variables properly for data race detection
Fixes https://github.com/rust-lang/miri/issues/3242
Miri has an optimization where some local variables are not represented in memory until something forces them to be stored in memory (most notably, creating a pointer/reference to the local will do that). However, for a subsystem triggering on memory accesses -- such as the data race detector -- this means that the memory access seems to happen only when the local is moved to memory, instead of at the time that it actually happens. This can lead to UB reports in programs that do not actually have UB.
This PR fixes that by adding machine hooks for reads and writes to such efficiently represented local variables. The data race system tracks those very similar to how it would track reads and writes to addressable memory, and when a local is moved to memory, the clocks get overwritten with the information stored for the local.
|
|
Implement feature `string_from_utf8_lossy_owned` for lossy conversion from `Vec<u8>` to `String` methods
Accepted ACP: https://github.com/rust-lang/libs-team/issues/116
Tracking issue: #129436
Implement feature for lossily converting from `Vec<u8>` to `String`
- Add `String::from_utf8_lossy_owned`
- Add `FromUtf8Error::into_utf8_lossy`
---
Related to #64727, but unsure whether to mark it "fixed" by this PR.
That issue partly asks for in-place replacement of the original allocation. We fulfill the other half of that request with these functions.
closes #64727
|
|
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- #129195 (Stabilize `&mut` (and `*mut`) as well as `&Cell` (and `*const Cell`) in const)
- #130118 (move Option::unwrap_unchecked into const_option feature gate)
- #130295 (Fix target-cpu fpu features on Armv8-R.)
- #130371 (Correctly account for niche-optimized tags in rustc_transmute)
- #130381 (library: Compute Rust exception class from its string repr)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
workingjubilee:sometimes-code-really-is-self-descriptive, r=Noratrieb
library: Compute Rust exception class from its string repr
Noticed this awkwardness while scanning through the code. I think we can do better than that.
|
|
Correctly account for niche-optimized tags in rustc_transmute
This is a bit hacky, but it fixes the ICE and makes it possible to run the safe transmute check on every `mem::transmute` check we instantiate. I want to write a lint that needs to do that, but this stands well on its own.
cc `@jswrenn` here's the fix I alluded to yesterday :)
Fixes #123693
|
|
Fix target-cpu fpu features on Armv8-R.
This is a follow-up to #123159, but applied to Armv8-R.
This required https://github.com/llvm/llvm-project/pull/88287 to work properly. Now that this change exists in rustc's llvm, we can fix Armv8-R's default fpu features. In Armv8-R's case, the default features from LLVM for floating-point are sufficient, because there is no integer-only variant of this architecture.
|
|
move Option::unwrap_unchecked into const_option feature gate
That's where `unwrap` and `expect` are so IMO it makes more sense to group them together.
Part of #91930, #67441
|
|
Stabilize `&mut` (and `*mut`) as well as `&Cell` (and `*const Cell`) in const
This stabilizes `const_mut_refs` and `const_refs_to_cell`. That allows a bunch of new things in const contexts:
- Mentioning `&mut` types
- Creating `&mut` and `*mut` values
- Creating `&T` and `*const T` values where `T` contains interior mutability
- Dereferencing `&mut` and `*mut` values (both for reads and writes)
The same rules as at runtime apply: mutating immutable data is UB. This includes mutation through pointers derived from shared references; the following is diagnosed with a hard error:
```rust
#[allow(invalid_reference_casting)]
const _: () = {
let mut val = 15;
let ptr = &val as *const i32 as *mut i32;
unsafe { *ptr = 16; }
};
```
The main limitation that is enforced is that the final value of a const (or non-`mut` static) may not contain `&mut` values nor interior mutable `&` values. This is necessary because the memory those references point to becomes *read-only* when the constant is done computing, so (interior) mutable references to such memory would be pretty dangerous. We take a multi-layered approach here to ensuring no mutable references escape the initializer expression:
- A static analysis rejects (interior) mutable references when the referee looks like it may outlive the current MIR body.
- To be extra sure, this static check is complemented by a "safety net" of dynamic checks. ("Dynamic" in the sense of "running during/after const-evaluation, e.g. at runtime of this code" -- in contrast to "static" which works entirely by looking at the MIR without evaluating it.)
- After the final value is computed, we do a type-driven traversal of the entire value, and if we find any `&mut` or interior-mutable `&` we error out.
- However, the type-driven traversal cannot traverse `union` or raw pointers, so there is a second dynamic check where if the final value of the const contains any pointer that was not derived from a shared reference, we complain. This is currently a future-compat lint, but will become an ICE in #128543. On the off-chance that it's actually possible to trigger this lint on stable, I'd prefer if we could make it an ICE before stabilizing const_mut_refs, but it's not a hard blocker. This part of the "safety net" is only active for mutable references since with shared references, it has false positives.
Altogether this should prevent people from leaking (interior) mutable references out of the const initializer.
While updating the tests I learned that surprisingly, this code gets rejected:
```rust
const _: Vec<i32> = {
let mut x = Vec::<i32>::new(); //~ ERROR destructor of `Vec<i32>` cannot be evaluated at compile-time
let r = &mut x;
let y = x;
y
};
```
The analysis that rejects destructors in `const` is very conservative when it sees an `&mut` being created to `x`, and then considers `x` to be always live. See [here](https://github.com/rust-lang/rust/issues/65394#issuecomment-541499219) for a longer explanation. `const_precise_live_drops` will solve this, so I consider this problem to be tracked by https://github.com/rust-lang/rust/issues/73255.
Cc `@rust-lang/wg-const-eval` `@rust-lang/lang`
Cc https://github.com/rust-lang/rust/issues/57349
Cc https://github.com/rust-lang/rust/issues/80384
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
interpret: get_ptr_alloc_mut: lookup allocation only once
I don't think this will make a big perf difference, but it makes this function symmetric with `get_ptr_alloc` -- and it's always nice to successfully solve a borrow checker puzzle like this. ;)
|
|
|
|
|
|
mutability check
|
|
|
|
|
|
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #130042 (properly handle EOF in BufReader::peek)
- #130061 (Add `NonNull` convenience methods to `Box` and `Vec`)
- #130202 (set `download-ci-llvm = true` by default on "library" and "tools" profiles)
- #130214 (MaybeUninit::zeroed: mention that padding is not zeroed)
- #130353 (Make some lint doctests compatible with `--stage=0`)
- #130370 (unstable-book: `trait_upcasting` example should not have `#![allow(incomplete_features)]`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
This is a follow-up to #123159, but applied to Armv8-R.
This required https://github.com/llvm/llvm-project/pull/88287 to work
properly. Now that this change exists in rustc's llvm, we can fix
Armv8-R's default fpu features. In Armv8-R's case, the default features
from LLVM for floating-point are sufficient, because there is no
integer-only variant of this architecture.
|
