| Age | Commit message (Collapse) | Author | Lines |
|---|
|
r=onur-ozkan
add clarity for custom path installation
install.sysconfdir is another value, in addition to install.prefix, that could be set for custom path installation.
|
|
ismailarilik:handle-potential-query-instability-lint-for-librustdoc, r=notriddle
Handle `librustdoc` cases of `rustc::potential_query_instability` lint
This PR removes `#![allow(rustc::potential_query_instability)]` line from [`src/librustdoc/lib.rs`](https://github.com/rust-lang/rust/blob/master/src/librustdoc/lib.rs#L23) and converts `FxHash{Map,Set}` types into `FxIndex{Map,Set}` to suppress lint errors.
A somewhat tracking issue: https://github.com/rust-lang/rust/issues/84447
r? `@compiler-errors`
|
|
install.sysconfdir is another value, in addition to install.prefix,
that could be set for custom path installation.
Signed-off-by: Naveen R. Iyer <iyernaveenr@gmail.com>
|
|
Rollup of 5 pull requests
Successful merges:
- #129392 (Do not consider match/let/ref of place that evaluates to `!` to diverge, disallow coercions from them too)
- #131279 (update "build/host" symlink comment)
- #131312 (On function and method calls in patterns, link to the book)
- #131315 (bootstrap: add `std_features` config)
- #131316 (Fix typo in primitive_docs.rs)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Fix typo in primitive_docs.rs
typo introduced in #129559
|
|
r=onur-ozkan
bootstrap: add `std_features` config
Adding support for a std-features config under the rust section in config.toml during bootstrap. This allows rustc devs to build with specific feature flags for local development.
|
|
On function and method calls in patterns, link to the book
```
error: expected a pattern, found an expression
--> f889.rs:3:13
|
3 | let (x, y.drop()) = (1, 2);
| ^^^^^^^^ not a pattern
|
= note: arbitrary expressions are not allowed in patterns: <https://doc.rust-lang.org/book/ch18-00-patterns.html>
error[E0532]: expected a pattern, found a function call
--> f889.rs:2:13
|
2 | let (x, drop(y)) = (1, 2);
| ^^^^ not a tuple struct or tuple variant
|
= note: function calls are not allowed in patterns: <https://doc.rust-lang.org/book/ch18-00-patterns.html>
```
Fix #97200.
|
|
update "build/host" symlink comment
It's needed and can't be removed, so make it clear where it's needed.
|
|
compiler-errors:raw-ref-op-doesnt-diverge-but-more, r=lcnr
Do not consider match/let/ref of place that evaluates to `!` to diverge, disallow coercions from them too
Fixes #117288.
This PR implements a heuristic which disables two things that are currently being performed on the HIR when we have **expressions that involve place-like expressions that point to `!`**. Specifically, it will (in certain cases explained below):
### (1.) Disable the `NeverToAny` coercion we implicitly insert for `!`.
Which fixes this inadvertent, sneaky unsoundness:
```
unsafe {
let x: *const ! = &0 as *const u8 as *const !;
let _: () = *x;
}
```
which is UB because currently rust emits an *implicit* NeverToAny coercion even though we really shouldn't be, since there's no read of the value pointed by `x`.
### (2.) Disable the logic which considers expression which evaluate to `!` to diverge, which affects the type returned by the containing block.
Which fixes this unsoundness:
```
fn make_up_a_value<T>() -> T {
unsafe {
let x: *const ! = &0 as *const u8 as *const !;
let _ = *x;
}
}
```
We disable these two operations **if** the expression is a place-like expression (locals, statics, field projections, index operations, and deref operations), and if the parent expression is either:
(1.) the LHS of an assignment
(2.) AddrOf
(3.) A match or let **unless** all of the *patterns consitute a read*, which is explained below:
And finally, a pattern currently is considered to constitute a read **unless** it is a wildcard, or an OR pattern. An OR pattern is considered to constitute a read if all of its subpatterns constitute a read, to remain as conservative as possible in cases like `_ | subpat` or `subpat | _`.
All other patterns are considered currently to constitute a read. Specifically, because `NeverToAny` is a coercion performed on a *value* and not a *place*, `Struct { .. }` on a `!` type must be a coercion currently, and we currently rely on this behavior to allow us to perform coercions like `let _: i32 = x;` where `x: !`.
This is already considered UB by [miri](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=daf3a2246433fe43fdc07d1389c276c9), but also means it does not affect the preexisting UB in this case:
```
let Struct { .. } = *never_ptr;
```
Even though it's likely up for debate since we're not actually reading any data out of the struct, it almost certainly causes inference changes which I do *NOT* want to fix in this PR.
|
|
bootstrap: Consolidate editor setup into ./x setup editor & add support for vim, emacs & helix
Add support for automatically setting up the recommended
LSP config for Vim (coc-nvim), Emacs (eglot) and Helix.
Additionally, refactor setup.rs to make it easier to add support
for more editors in the future.
As suggested,
r? `@jieyouxu`
|
|
|
|
Update `compiler-builtins` to 0.1.133
This includes [1], which should help resolve an infinite recusion issue on WASM and SPARC (possibly other platforms). See [2] and [3] for further details.
[1]: https://github.com/rust-lang/compiler-builtins/pull/708
[2]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/sparc-unknown-none-elf.20regresssion.20between.20compiler-built.2E.2E.2E
[3]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/.5Bwasm32.5D.20Infinite.20recursion.20.60compiler-builtins.60.20.60__multi3.60
|
|
|
|
bootstrap: add std_features to config.example
fix: use BTreeSet for std-features; add unit tests
* fix formatting of string in front of std_features
* rename `std_features` to `std-features` in config.toml
fix: remove space before std-features in config.toml
fix: remove explicit .into_iter conversion
bootstrap: add details for rust.std-features in config.example.toml
Co-authored-by: Onur Özkan <onurozkan.dev@outlook.com>
fix: remove `Option<T>` from `rust_std_features`
fix: move default rust_std_features to config
fix: make std_features CI rustc incompatible
|
|
Add a Lint for Pointer to Integer Transmutes in Consts
Fixes #87525
This PR adds a MirLint for pointer to integer transmutes in const functions and associated consts. The implementation closely follows this comment: https://github.com/rust-lang/rust/pull/85769#issuecomment-880969112. More details about the implementation can be found in the comments.
Note: This could break some sound code as mentioned by RalfJung in https://github.com/rust-lang/rust/pull/85769#issuecomment-886491680:
> ... technically const-code could transmute/cast an int to a ptr and then transmute it back and that would be correct -- so the lint will deny some sound code. Does not seem terribly likely though.
References:
1. https://doc.rust-lang.org/std/mem/fn.transmute.html
2. https://doc.rust-lang.org/reference/items/associated-items.html#associated-constants
|
|
This includes [1], which should help resolve an infinite recusion issue
on WASM and SPARC (possibly other platforms). See [2] and [3] for
further details.
[1]: https://github.com/rust-lang/compiler-builtins/pull/708
[2]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/sparc-unknown-none-elf.20regresssion.20between.20compiler-built.2E.2E.2E
[3]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/.5Bwasm32.5D.20Infinite.20recursion.20.60compiler-builtins.60.20.60__multi3.60
|
|
```
error: expected a pattern, found an expression
--> f889.rs:3:13
|
3 | let (x, y.drop()) = (1, 2); //~ ERROR
| ^^^^^^^^ not a pattern
|
= note: arbitrary expressions are not allowed in patterns: <https://doc.rust-lang.org/book/ch18-00-patterns.html>
error[E0532]: expected a pattern, found a function call
--> f889.rs:2:13
|
2 | let (x, drop(y)) = (1, 2); //~ ERROR
| ^^^^ not a tuple struct or tuple variant
|
= note: function calls are not allowed in patterns: <https://doc.rust-lang.org/book/ch18-00-patterns.html>
```
Fix #97200.
|
|
|
|
|
|
Update to LLVM 19.1.1
No known issues are fixed this time.
r? `@rust-lang/wg-llvm`
|
|
check_expr_has_type_or_error
|
|
|
|
|
|
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Rollup of 5 pull requests
Successful merges:
- #130555 ( Initial support for riscv32{e|em|emc}_unknown_none_elf)
- #131280 (Handle `rustc_interface` cases of `rustc::potential_query_instability` lint)
- #131281 (make Cell unstably const)
- #131285 (clarify semantics of ConstantIndex MIR projection)
- #131299 (fix typo in 'lang item with track_caller' message)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
fix typo in 'lang item with track_caller' message
Revival of https://github.com/rust-lang/rust/pull/124912
|
|
clarify semantics of ConstantIndex MIR projection
This documents what Miri does:
https://github.com/rust-lang/rust/blob/c4ce8c114b06840c3521a189ee44958b713fb33a/compiler/rustc_const_eval/src/interpret/projection.rs#L272-L275
I am not sure what exactly the purpose of this `min_length` field is, TBH... but this seems like the most obvious meaning it could have?
|
|
make Cell unstably const
Now that we can do interior mutability in `const`, most of the Cell API can be `const fn`. :) The main exception is `set`, because it drops the old value. So from const context one has to use `replace`, which delegates the responsibility for dropping to the caller.
Tracking issue: https://github.com/rust-lang/rust/issues/131283
`as_array_of_cells` is itself still unstable to I added the const-ness to the feature gate for that function and not to `const_cell`, Cc #88248.
r? libs-api
|
|
ismailarilik:handle-potential-query-instability-lint-for-rustc-interface, r=cjgillot
Handle `rustc_interface` cases of `rustc::potential_query_instability` lint
This PR removes `#![allow(rustc::potential_query_instability)]` occurrences from [`compiler/rustc_interface/`](https://github.com/rust-lang/rust/blob/master/compiler/rustc_interface/) <s>and converts `FxHash{Map,Set}` types into `FxIndex{Map,Set}` to suppress lint errors</s> (was not necessary for this PR).
A somewhat tracking issue: https://github.com/rust-lang/rust/issues/84447
r? `@compiler-errors`
|
|
Initial support for riscv32{e|em|emc}_unknown_none_elf
We have a research prototype of an RV32EMC target and have been successfully running the e, em, emc programs on it. I'm hoping upstreaming this configuration would make the target maintenance slightly easier.
Configuration is based on the respective {i, im, imc} variants. As defined in RISC-V Unprivileged Spec. 20191213, the only change in RVE wrt. RVI is to reduce the number of integer registers to 16 (x0-x15), which also implies
- 2 callee saved registers instead of 12
- 32-bit / 4-byte stack alignment instead of 128 bits / 16 bytes
My initial presumption is that this will not impact how the target is defined for the compiler but only becomes relevant at the runtime level. I am willing to investigate, though.
EDIT: LLVM is now told about the presumed 32-bit stack alignment.
`@Disasm` `@romancardenas`
|
|
Update compiler-builtins to 0.1.132
This commit updates compiler-builtins from 0.1.130 to 0.1.132.
PRs in the delta:
- rust-lang/compiler-builtins#698
- rust-lang/compiler-builtins#699
- rust-lang/compiler-builtins#701
- rust-lang/compiler-builtins#704
- rust-lang/compiler-builtins#627
- rust-lang/compiler-builtins#706
|
|
|
|
Do not copy libstd dynamic library to sysroot
Since https://github.com/rust-lang/rust/pull/122362, rustc links statically to libstd.[so|dll]. Which means that the libstd.[so|dll] file no longer has to be in the rustc sysroot. However, we are currently still shipping this file, in every new release of Rust, for no reason, it's just wasted bytes.
This PR removes the dynamic library file from the built sysroot.
However, it is not yet performed on Windows, because stage0 incremental tests start failing there (see description of the issue [here](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Failing.20incr.20tests.20on.20Windows.20when.20std.2Edll.20is.20missing/near/474507064)).
This is an extended version of https://github.com/rust-lang/rust/pull/128986.
CC `@Zoxc`
|
|
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- #130428 (Stabilize `const_slice_split_at_mut` and `const_slice_first_last_chunk`)
- #131094 (std: replace `LazyBox` with `OnceBox`)
- #131256 (move f16/f128 const fn under f16/f128 feature gate)
- #131278 (remove outdated contribution direction)
- #131286 (Miri subtree update)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Miri subtree update
r? `@ghost`
|
|
remove outdated contribution direction
|
|
move f16/f128 const fn under f16/f128 feature gate
The `*_const` features were added to work around https://github.com/rust-lang/rust/issues/129656, which should not be needed any more.
|
|
std: replace `LazyBox` with `OnceBox`
This PR replaces the `LazyBox` wrapper used to allocate the pthread primitives with `OnceBox`, which has a more familiar API mirroring that of `OnceLock`. This cleans up the code in preparation for larger changes like #128184 (from which this PR was split) and allows some neat optimizations, like avoid an acquire-load of the allocation pointer in `Mutex::unlock`, where the initialization of the allocation must have already been observed.
Additionally, I've gotten rid of the TEEOS `Condvar` code, it's just a duplicate of the pthread one anyway and I didn't want to repeat myself.
|
|
r=RalfJung
Stabilize `const_slice_split_at_mut` and `const_slice_first_last_chunk`
Stabilizes #101804 and the remainder of #111774.
FCP proposed in the tracking issue.
Requires #130403 (or it would need a rustc_allow_const_fn_unstable for it)
Stabilized const API:
```rust
// slice
impl [T] {
pub const fn split_at_mut(&mut self, mid: usize) -> (&mut [T], &mut [T]);
pub const fn split_at_mut_unchecked(&mut self, mid: usize) -> (&mut [T], &mut [T]);
pub const fn split_at_mut_checked(&mut self, mid: usize) -> Option<(&mut [T], &mut [T])>;
pub const fn first_chunk_mut<const N: usize>(&mut self) -> Option<&mut [T; N]>;
pub const fn last_chunk_mut<const N: usize>(&mut self) -> Option<&mut [T; N]>;
pub const fn split_first_chunk_mut<const N: usize>(&mut self) -> Option<(&mut [T; N], &mut [T])>;
pub const fn split_last_chunk_mut<const N: usize>(&mut self) -> Option<(&mut [T; N], &mut [T])>;
}
```
Closes #101804
Closes #111774
cc `@RalfJung`
|
|
|
|
Prefer refutable slice patterns over len check + index op
Just something I noticed while reviewing other PRs
We do it for shim arguments almost everywhere, but when the size is not statically known, we didn't use the helpers as they rely on array ops. But we can avoid a len check followed by several index ops by just using a refutable slice pattern with `let else`.
The pattern is so common, it seems almost worth a dedicated macro
|
|
|
|
|
|
|
|
Add rv32e-targets to 'stage0 missing targets'. This prevents the error
"no such target exists in the target list".
|
|
|
|
|
