| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
starting from the x86_64-unknown-linux-gnu specs, we add the lld linker
flavor and self-contained linker component
|
|
this ensures roundtripping of stable and unstable values:
- backwards-compatible values can be deserialized, as well as the new
unstable values
- unstable values are serialized.
|
|
|
|
Bump bootstrap compiler to just-released beta
https://forge.rust-lang.org/release/process.html#master-bootstrap-update-t-2-day-tuesday
|
|
Stabilize `atomic_from_ptr`
This stabilizes `atomic_from_ptr` and moves the const gate to `const_atomic_from_ptr`. Const stability is blocked on `const_mut_refs`.
Tracking issue: #108652
Newly stable API:
```rust
// core::atomic
impl AtomicBool { pub unsafe fn from_ptr<'a>(ptr: *mut bool) -> &'a AtomicBool; }
impl<T> AtomicPtr<T> { pub unsafe fn from_ptr<'a>(ptr: *mut *mut T) -> &'a AtomicPtr<T>; }
impl AtomicU8 { pub unsafe fn from_ptr<'a>(ptr: *mut u8) -> &'a AtomicU8; }
impl AtomicU16 { pub unsafe fn from_ptr<'a>(ptr: *mut u16) -> &'a AtomicU16; }
impl AtomicU32 { pub unsafe fn from_ptr<'a>(ptr: *mut u32) -> &'a AtomicU32; }
impl AtomicU64 { pub unsafe fn from_ptr<'a>(ptr: *mut u64) -> &'a AtomicU64; }
impl AtomicUsize { pub unsafe fn from_ptr<'a>(ptr: *mut usize) -> &'a AtomicUsize; }
impl AtomicI8 { pub unsafe fn from_ptr<'a>(ptr: *mut i8) -> &'a AtomicI8; }
impl AtomicI16 { pub unsafe fn from_ptr<'a>(ptr: *mut i16) -> &'a AtomicI16; }
impl AtomicI32 { pub unsafe fn from_ptr<'a>(ptr: *mut i32) -> &'a AtomicI32; }
impl AtomicI64 { pub unsafe fn from_ptr<'a>(ptr: *mut i64) -> &'a AtomicI64; }
impl AtomicIsize { pub unsafe fn from_ptr<'a>(ptr: *mut isize) -> &'a AtomicIsize; }
```
|
|
const-eval: make misalignment a hard error
It's been a future-incompat error (showing up in cargo's reports) since https://github.com/rust-lang/rust/pull/104616, Rust 1.68, released in March. That should be long enough.
The question for the lang team is simply -- should we move ahead with this, making const-eval alignment failures a hard error? (It turns out some of them accidentally already were hard errors since #104616. But not all so this is still a breaking change. Crater found no regression.)
|
|
Revert "Invoke `backtrace-rs` buildscript in `std` buildscript"
This reverts commit 93677276bc495e78f74536385a16201d465fd523 because it caused issues for projects building the standard library with non-cargo build systems.
See https://github.com/rust-lang/rust/pull/116318#issuecomment-1761977900
r? workingjubilee
|
|
|
|
* Remove duplicate alignment note that mentioned `AtomicBool` with other
types
* Update safety requirements about when non-atomic operations are
allowed
|
|
This reverts commit 93677276bc495e78f74536385a16201d465fd523
because it caused issues for projects building the standard
library with non-cargo build systems.
|
|
Detect ruby-style closure in parser
When parsing a closure without a body that is surrounded by a block, suggest moving the opening brace after the closure head.
Fix #116608.
|
|
DaniPopes:stabilize-const_maybe_uninit_assume_init_read, r=dtolnay
Stabilize `const_maybe_uninit_assume_init_read`
AFAICT the only reason this was not included in the `maybe_uninit_extra` stabilization was because `ptr::read` was unstable (https://github.com/rust-lang/rust/pull/92768#issuecomment-1011101383), which has since been stabilized in 1.71.
Needs a separate FCP from the [original `maybe_uninit_extra` one](https://github.com/rust-lang/rust/issues/63567#issuecomment-964428807).
Tracking issue: #63567
|
|
Fix exit status / wait status on non-Unix cfg(unix) platforms
Fixes #114593
Needs FCP due to behavioural changes (NB only on non-Unix `#[cfg(unix)]` platforms).
Also, I think this is likely to break in CI. I have not been yet able to compile the new bits of `process_unsupported.rs`, although I have compiled the new module. I'd like some help from people familiar with eg emscripten and fuchsia (which are going to be affected, I think).
|
|
Hide host effect params from docs
addresses (only on nightly, needs backport) https://github.com/rust-lang/rust/issues/116629
r? `@compiler-errors`
cc `@GuillaumeGomez` `@fee1-dead`
|
|
const trait things in libcore
|
|
On type error involving closure, avoid ICE
When we encounter a type error involving a closure, we try to typeck prior closure invocations to see if they influenced the current expected type. When trying to do so, ensure that the closure was defined in our current scope.
Fix #116658.
|
|
Improve check-cfg diagnostics
This PR tries to improve some of the diagnostics of check-cfg.
The main changes is the unexpected name or value being added to the main diagnostic:
```diff
- warning: unexpected `cfg` condition name
+ warning: unexpected `cfg` condition name: `widnows`
```
It also cherry-pick the better sensible logic for when we print the list of expected values when we have a matching value for a very similar name.
Address https://github.com/rust-lang/rust/pull/111072#discussion_r1356818100
r? `@petrochenkov`
|
|
Streamline `rustc_driver_impl` pretty-printing.
This PR simplifies a lot of unnecessary structure in
`rustc_driver_impl/src/pretty.rs`. It removes some traits and functions,
simplifies some structs, renames some things for increased consistency, and
eliminates some boilerplate code. Overall it cuts more than 150 lines of code.
r? `@compiler-errors`
|
|
Remove cgu_reuse_tracker from Session
This removes a bit of global mutable state.
It will now miss post-lto cgu reuse when ThinLTO determines that a cgu doesn't get changed, but there weren't any tests for this anyway and a test for it would be fragile to the exact implementation of ThinLTO in LLVM.
|
|
When we encounter a type error involving a closure, we try to typeck
prior closure invocations to see if they influenced the current expected
type. When trying to do so, ensure that the closure was defined in our
current scope.
Fix #116658.
|
|
When parsing a closure without a body that is surrounded by a block,
suggest moving the opening brace after the closure head.
Fix #116608.
|
|
exhaustiveness: Rework constructor splitting
`SplitWildcard` was pretty opaque. I replaced it with a more legible abstraction: `ConstructorSet` represents the set of constructors for patterns of a given type. This clarifies responsibilities: `ConstructorSet` handles one clear task, and diagnostic-related shenanigans can be done separately.
I'm quite excited, I had has this in mind for years but could never quite introduce it. This opens up possibilities, including type-specific optimisations (like using a `FxHashSet` to collect enum variants, which had been [hackily attempted some years ago](https://github.com/rust-lang/rust/pull/76918)), my one-pass rewrite (https://github.com/rust-lang/rust/pull/116042), and future librarification.
|
|
|
|
`NoAnn` and `IdentifiedAnnotation` impl both `pprust_ast::PpAnn` and
`pprust_hir::PpAnn`, which is a bit confusing, because the optional
`tcx` is only needed for the HIR cases. (Currently the `tcx` is
unnecessarily provided in the `expanded` AST cases.)
This commit splits each one into `Ast` and `Hir` versions, which makes
things clear about where the `tcx` is needed. The commit also renames
all the traits so they consistently end with `Ann`.
|
|
This avoids the need for a bespoke `tcx.analysis()` call.
|
|
Because they all end up within a `TyCtxt`.
|
|
`call_with_pp_support_ast` and `call_with_pp_support_hir` how each have
a single call site. This commit inlines and removes them, which also
removes the need for all the supporting traits: `Sess`,
`AstPrinterSupport`, and `HirPrinterSupport`. The `sess` member is also
removed from several structs.
|
|
The handling of the `PpMode` variants is currently spread across three
functions: `print_after_parsing`, `print_after_hir_lowering`, and
`print_with_analysis`. Each one handles some of the variants. This split
is primarily because `print_after_parsing` has slightly different
arguments to the other two.
This commit changes the structure. It merges the three functions into a
single `print` function, and encapsulates the different arguments in a
new enum `PrintExtra`.
Benefits:
- The code is a little shorter.
- All the `PpMode` variants are handled in a single `match`, with no
need for `unreachable!` arms.
- It enables the trait removal in the subsequent commit by reducing
the number of `call_with_pp_support_ast` call sites from two to one.
|
|
First, both `AstPrinterSupport` and `HirPrinterSupport` have a `sess`
method. This commit introduces a `Sess` trait and makes the support
traits be subtraits of `Sess`, to avoid some duplication.
Second, both support traits have a `pp_ann` method that isn't needed if
we enable `trait_upcasting`. This commit removes those methods.
(Both of these traits will be removed in a subsequent commit, as will
the `trait_upcasting` use.)
|
|
|
|
It's simpler to distinguish the two AST modes directly in `PpMode`.
|
|
`phase_3_run_analysis_passes` no longer exists, and AFAICT this code has
been refactored so much since this comment was written that it no longer
has any useful meaning.
|
|
The callback is trivial and no pp support is actually needed. This makes
the `HirTree` case more like the `AstTree` case above.
|
|
- Rename `pprust` as `pprust_ast`, to align with `pprust_hir`.
- Rename `PrinterSupport` as `AstPrinterSupport`, to align with
`HirPrinterSupport`.
|
|
Copy 1-element arrays as scalars, not vectors
For `[T; 1]` it's silly to copy as `<1 x T>` when we can just copy as `T`.
Inspired by https://github.com/rust-lang/rust/issues/101210#issuecomment-1732470941, which pointed out that `Option<[u8; 1]>` was codegenning worse than `Option<u8>`.
(I'm not sure *why* LLVM doesn't optimize out `<1 x u8>`, but might as well just not emit it in the first place in this codepath.)
---
I think I bit off too much in #116479; let me try just the scalar case first.
r? `@ghost`
|
|
|
|
|
|
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- #116593 (Add unstable book page for the no-jump-tables codegen option)
- #116625 (`rustc_hir_pretty` cleanups)
- #116642 (Handle several `#[diagnostic::on_unimplemented]` attributes correctly)
- #116654 (coverage: Clarify loop-edge detection and graph traversal)
- #116669 (Fix mips platform support entries.)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
|
|
|
|
Fix mips platform support entries.
The table entries for these MIPS entries were broken because they had the wrong number of columns (from #116503). Additionally, there was a conflict with #115238, which made the same change (but on different lines, so git didn't complain).
|
|
coverage: Clarify loop-edge detection and graph traversal
This is a collection of improvements to two semi-related pieces of code:
- The code in `counters` that detects which graph edges don't exit a loop, and would therefore be good candidates to have their coverage computed as an expression rather than having a physical counter.
- The code in `graph` that traverses the coverage BCB graph in a particular order, and tracks loops and loop edges along the way (which is relevant to the above).
I was originally only planning to make the `graph` changes, but there was going to be a lot of indentation churn in `counters` anyway, and once I started looking I noticed a lot of opportunities for simplification.
---
`@rustbot` label +A-code-coverage
|
|
r=compiler-errors
Handle several `#[diagnostic::on_unimplemented]` attributes correctly
This PR fixes an issues where rustc would ignore subsequent `#[diagnostic::on_unimplemented]` attributes. The [corresponding RFC](https://rust-lang.github.io/rfcs/3368-diagnostic-attribute-namespace.html) specifies that the first matching instance of each option is used. Invalid attributes are linted and otherwise ignored.
|
|
`rustc_hir_pretty` cleanups
Just some improvements I found while looking through this code.
r? ``@fee1-dead``
|
|
Add unstable book page for the no-jump-tables codegen option
See tracking issue: https://github.com/rust-lang/rust/issues/116592
|
