profile
viewpoint

Aaron1011/acme-redirect 1

Tiny http daemon that answers acme challenges and redirects everything else to https

Aaron1011/actix 1

Actor framework for Rust

Aaron1011/actix-net 0

framework for composable networking services

Aaron1011/actix-web 0

Actix web is a small, pragmatic, and extremely fast rust web framework.

Aaron1011/ActuallyAdditions 0

A Minecraft Mod about lots of useful gadgets and things!

Aaron1011/afl.rs 0

🐇 Fuzzing Rust code with american-fuzzy-lop

Aaron1011/alacritty 0

A cross-platform, GPU-accelerated terminal emulator

Pull request review commentrust-lang/rust

Use try_normalize_erasing_regions in needs_drop

 impl<'tcx> ty::TyS<'tcx> {                     [component_ty] => component_ty,                     _ => self,                 };+                 // This doesn't depend on regions, so try to minimize distinct                 // query keys used.-                let erased = tcx.normalize_erasing_regions(param_env, query_ty);-                tcx.needs_drop_raw(param_env.and(erased))+                // If normalization fails, we just use `query_ty`.+                let query_ty = match tcx.try_normalize_erasing_regions(param_env, query_ty) {

You could use .unwrap_or(query_ty) here

b-naber

comment created time in 2 hours

PullRequestReviewEvent

pull request commentrust-lang/rust

Don't suggest types whose inner type is erroneous

Could you add the code from the issue as a test case?

hkmatsumoto

comment created time in 4 hours

pull request commentrust-lang/rust

expand: Turn `ast::Crate` into a first class expansion target

@bors r+

petrochenkov

comment created time in a day

pull request commentrust-lang/rust

Avoid uneccessary clone of Annotatable

@bors r+

eggyal

comment created time in 2 days

pull request commentrust-lang/rust

Avoid uneccessary clone of Annotatable

@bors retry

eggyal

comment created time in 2 days

Pull request review commentrust-lang/rust

expand: Turn `ast::Crate` into a first class expansion target

 macro_rules! assign_id { }  impl<'a, 'b> MutVisitor for InvocationCollector<'a, 'b> {+    fn visit_crate(&mut self, krate: &mut ast::Crate) {+        let span = krate.span;+        let empty_crate =+            || ast::Crate { attrs: Vec::new(), items: Vec::new(), span, is_placeholder: None };+        let mut fold_crate = |krate: ast::Crate| {+            let mut krate = match self.configure(krate) {+                Some(krate) => krate,+                None => return empty_crate(),

Can the entire crate really be removed with something like #![cfg(FALSE)]? Is there a test case for this?

petrochenkov

comment created time in 2 days

PullRequestReviewEvent

pull request commentrust-lang/rust

Avoid uneccessary clone of Annotatable

@bors try

eggyal

comment created time in 2 days

pull request commentrust-lang/rust

Avoid uneccessary clone of Annotatable

@bors retry

eggyal

comment created time in 2 days

startedjayphelps/git-blame-someone-else

started time in 3 days

pull request commentrust-lang/rust

Remove eval_always for lib_features.

@bors r+

cjgillot

comment created time in 3 days

pull request commentrust-lang/rust

Avoid uneccessary clone of Annotatable

@bors r+

eggyal

comment created time in 3 days

pull request commentrust-lang/rust

Avoid uneccessary clone of Annotatable

Very clever!

@bors try @rust-timer queue

eggyal

comment created time in 4 days

Pull request review commentrust-lang/rust

Add test for evaluate_obligation: Ok(EvaluatedToOkModuloRegions) ICE

+// compile-flags: --edition=2021++#![feature(rustc_attrs)]++use core::any::Any;+use core::marker::PhantomData;++fn main() {+    test::<MaskedStorage<GenericComp<Pos>>>(make());+    //~^ ERROR evaluate(Binder(TraitPredicate(<MaskedStorage<GenericComp<Pos>> as std::marker::Sized>, polarity:Positive), [])) = Ok(EvaluatedToOk)+    //~| ERROR evaluate(Binder(TraitPredicate(<MaskedStorage<GenericComp<Pos>> as std::marker::Sized>, polarity:Positive), [])) = Ok(EvaluatedToOk)+}++#[rustc_evaluate_where_clauses]+fn test<T: Sized>(_: T) {}++fn make<T>() -> T {+    todo!()+}++struct DerefWrap<T>(T);++impl<T> core::ops::Deref for DerefWrap<T> {+    type Target = T;+    fn deref(&self) -> &Self::Target {+        &self.0+    }+}++struct Storage<T, D> {+    phantom: PhantomData<(T, D)>,+}++type ReadStorage<T> = Storage<T, DerefWrap<MaskedStorage<T>>>;++pub trait Component {+    type Storage;+}++struct VecStorage;++struct Pos;++impl Component for Pos {+    type Storage = VecStorage;+}++struct GenericComp<T> {+    _t: T,+}++impl<T: 'static> Component for GenericComp<T> {

You can make the top-level evaluation produce EvaluatedToOkModuloRegions by adding where for<'a> &'a bool: 'a to this impl. However, this will not work until https://github.com/rust-lang/rust/pull/91329 is merged

wesleywiser

comment created time in 4 days

PullRequestReviewEvent

PR opened rust-lang/rust

Fix incorrect usage of `EvaluatedToOk` when evaluating `TypeOutlives`

A global predicate is not guarnatenteed to outlive all regions. If the predicate involves late-bound regions, then it may fail to outlive other regions (e.g. for<'b> &'b bool: 'static does not hold)

We now only produce EvaluatedToOk when a global predicate has no late-bound regions - in that case, the ony region that can be present in the type is 'static

+82 -1

0 comment

4 changed files

pr created time in 4 days

create barnchAaron1011/rust

branch : modulo-regions-test

created branch time in 4 days

pull request commentrust-lang/rust

Use a fresh `InferCtxt` when we 'speculatively' evaluate predicates

After some further thought, I think this strategy is insufficient to complete fix the issue. We could still end up hitting a spurious ``ProjectionCacheEntry::InProgress, causing us to cache an evaluation error in the *global*tcx.evaluation_cache`.

I think we need to avoid speculative evaluation entirely. PR https://github.com/rust-lang/rust/pull/89831 remove speculative evaluation (among other things), but it causes a significant performance hit. Since this bug is currently preventing code from compiling, we might want to accept the performance hit for the time being.

Aaron1011

comment created time in 4 days

pull request commentrust-lang/rust

Use a fresh `InferCtxt` when we 'speculatively' evaluate predicates

@bors try

Aaron1011

comment created time in 4 days

pull request commentrust-lang/rust

Use a fresh `InferCtxt` when we 'speculatively' evaluate predicates

@bors try @rust-timer queue

Aaron1011

comment created time in 5 days

push eventAaron1011/rust

Aaron Hill

commit sha 931a3a631e80348068f49ce16fc73a7d54e020a3

Re-use the fresh InferCtxt

view details

push time in 5 days

issue commentrust-lang/rust

A `Pin` unsoundness involving an `impl DerefMut for Pin<&dyn LocalTrait>`

@y86-dev Thanks for the excellent write-up!

I believe that #[fundamental] only comes into play when writing a local impl for Pin<SomeType>. In my understanding, CoerceUnsized does not interact with #[fundamental] at all (except maybe if you were writing a CoerceUnsized impl for a foreign type, but the example doesn't include any new CoerceUnsized impls).

@steffahn: If I understand correctly, this issue is only possible because of the blanket impl<P, U> CoerceUnsized<Pin<U>> for Pin<P> where P: CoerceUnsized<U> {}. Without that impl, you could still write a DerefMut impl for Pin<&LocalType>, allowing you to obtain a Pin<&mut LocalType. However, you can only (safely) obtain a Pin<Pin<&LocalType>> if LocalType: Unpin, so you could already use the safe constructor Pin::new(&mut LocalType).

If LocalType: !Unpin, then you cannot create a Pin<Pin<&LocalType>> in safe code:

use std::marker::PhantomPinned;
use std::pin::Pin;

fn main() {
    let val: Pin<Pin<&PhantomPinned>> = Pin::new(Pin::new(&PhantomPinned));
}

produces:

error[E0277]: `PhantomPinned` cannot be unpinned
   --> src/main.rs:5:59
    |
5   |     let val: Pin<Pin<&PhantomPinned>> = Pin::new(Pin::new(&PhantomPinned));
    |                                                           ^^^^^^^^^^^^^^ the trait `Unpin` is not implemented for `PhantomPinned`
    |
    = note: consider using `Box::pin`
note: required by `Pin::<P>::new`

error[E0277]: `PhantomPinned` cannot be unpinned
   --> src/main.rs:5:50
    |
5   |     let val: Pin<Pin<&PhantomPinned>> = Pin::new(Pin::new(&PhantomPinned));
    |                                                  ^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Unpin` is not implemented for `PhantomPinned`
    |
    = note: consider using `Box::pin`
note: required by `Pin::<P>::new`

To obtain a Pin<Pin<&LocalType>> with LocalType: !Unpin, you would either need to use the CoerceUnsized impl with dyn Trait, or use Pin::new_unchecked. Since LocalType is (by definition) local, you are arguably violating the unsafe contract being using Pin::new_unchecked in this way - if you later move LocalType, you are moving a type that you promised not to move.

With that in mind, I think we can eliminate the problem by replacing the blanket CoerceUnsized impl by several concrete impls. The blanket impl<P, U> CoerceUnsized<Pin<U>> for Pin<P> where P: CoerceUnsized<U> {} applies recursively to Pin<Pin<T>>, allowing us to coerce Pin<Pin<&T>> to Pin<Pin<&dyn Trait>>. However, I think this impl is essentially useless in practice. Not only is a Pin<Pin<&T>> a pretty useless type, but it can be manually constructed by unwrapping the the Pins, coercing &T to &dyn T, and then wrapping the &dyn T in two layers of Pin.

Since CoerceUnsized is an unstable trait, stable code can only be relying on the impls provided by the standard library for certain pointer types (Box, Cell, Pin, etc). We could replace the blanket impl<P, U> CoerceUnsized<Pin<U>> for Pin<P> where P: CoerceUnsized<U> {} with an impl for each standard library 'pointer' type, excluding Pin:

impl<P, U> CoerceUnsized<Pin<Box<U>>> for Pin<Box<P>> where P: CoerceUnsized<U> {}
impl<P, U> CoerceUnsized<Pin<Box<U>>> for Pin<Box<P>> where P: CoerceUnsized<U> {}
impl<P, U> CoerceUnsized<Pin<Cell<U>>> for Pin<Cell<P>> where P: CoerceUnsized<U> {}
...

This would allow users to continue relying on 'useful' coercions (e.g. Pin<&MyFuture> to Pin<&dyn Future>), while banning coercions involving Pin<Pin<&T>>. Even though users will still be able to write DerefMut impls for Pin<&LocalType>, the lack of the necessary CoerceUnsized impl with prevent this DerefMut impl from being exploited in safe code.

steffahn

comment created time in 5 days

pull request commentrust-lang/rust

Only check for errors in predicate when skipping impl assembly

@bors r=lcnr

Aaron1011

comment created time in 5 days

push eventAaron1011/rust

Josh Stone

commit sha 5ff6ac4287e191ee684f1de1af642e7b656947b6

Refactor weak symbols in std::sys::unix This makes a few changes to the weak symbol macros in `sys::unix`: - `dlsym!` is added to keep the functionality for runtime `dlsym` lookups, like for `__pthread_get_minstack@GLIBC_PRIVATE` that we don't want to show up in ELF symbol tables. - `weak!` now uses `#[linkage = "extern_weak"]` symbols, so its runtime behavior is just a simple null check. This is also used by `syscall!`. - On non-ELF targets (macos/ios) where that linkage is not known to behave, `weak!` is just an alias to `dlsym!` for the old behavior. - `raw_syscall!` is added to always call `libc::syscall` on linux and android, for cases like `clone3` that have no known libc wrapper. The new `weak!` linkage does mean that you'll get versioned symbols if you build with a newer glibc, like `WEAK DEFAULT UND statx@GLIBC_2.28`. This might seem problematic, but old non-weak symbols can tie the build to new versions too, like `dlsym@GLIBC_2.34` from their recent library unification. If you build with an old glibc like `dist-x86_64-linux` does, you'll still get unversioned `WEAK DEFAULT UND statx`, which may be resolved based on the runtime glibc. I also found a few functions that don't need to be weak anymore: - Android can directly use `ftruncate64`, `pread64`, and `pwrite64`, as these were added in API 12, and our baseline is API 14. - Linux can directly use `splice`, added way back in glibc 2.5 and similarly old musl. Android only added it in API 21 though.

view details

The8472

commit sha 3f9b26dc64a2068d30027fd29ffbbfe07663419f

Fix Iterator::advance_by contract inconsistency The `advance_by(n)` docs state that in the error case `Err(k)` that k is always less than n. It also states that `advance_by(0)` may return `Err(0)` to indicate an exhausted iterator. These statements are inconsistent. Since only one implementation (Skip) actually made use of that I changed it to return Ok(()) in that case too. While adding some tests I also found a bug in `Take::advance_back_by`.

view details

Badel2

commit sha 6955afe8fd16d51b2c617d69f89a9eac5b7fd150

Fix stack overflow in `usefulness.rs`

view details

rdambrosio

commit sha 870b8311c17fb51139d5cc95fc592bcea85ee6ac

Feat: make cg_ssa get_param borrow the builder mutable

view details

Stefan Lankes

commit sha 644b445428845a4e662c15059193dfa492bc0c44

If the thread does not get the lock in the short term, yield the CPU Reduces the amount of wasted processor cycles

view details

Stefan Lankes

commit sha 6911af9d06ef4f92659326ce426c6aefc7b47282

Improving the readability Co-authored-by: kennytm <kennytm@gmail.com>

view details

Guillaume Gomez

commit sha c981d40d43c76267e7b4002e381851f0e92875bf

Fix invalid scrollbar display on source code page

view details

Michael Goulet

commit sha 718a3b1f2d59943c90cd02b9d0b90b315e003ec0

Fix issue 91206

view details

Michael Goulet

commit sha 69d1917672d302e2da14ad6673e6a0478c62d1ad

Add test demonstrating no more ICE

view details

Noah Lev

commit sha 8adb0b6d6c264facc6e213ad06a25194e7591682

Clean up `clean` re-exports This will allow re-exporting only certain enum variants.

view details

Noah Lev

commit sha d81deb33fa8e9f03006b637fd0c035dc7acc5343

Stop re-exporting `Type::ResolvedPath` I would like to rename it to `Type::Path`, but then it can't be re-exported since the name would conflict with the `Path` struct. Usually enum variants are referred to using their qualified names in Rust (and parts of rustdoc already do that with `clean::Type`), so this is also more consistent with the language.

view details

David Tolnay

commit sha 553a84c445b39c439318f463d6a6f86fc391ed7b

Saner formatting for UTF8_CHAR_WIDTH table

view details

Nicholas Nethercote

commit sha 026edbb4ef85ef3d38876548a771b7c72c87803f

Use unchecked construction in `Layout::pad_to_align`. Other, similar methods for `Layout` do likewise, and there's already an `unwrap()` around the result demonstrating the safety.

view details

Nicholas Nethercote

commit sha f3bda74d363a060ade5e5caeb654ba59bfed51a4

Optimize `Layout::array`. The current implementation is much more conservative than it needs to be, because it's dealing with the size and alignment of a given `T`, which are more restricted than an arbitrary `Layout`. For example, imagine a struct with a `u32` and a `u4`. You can safely create a `Layout { size_: 5, align_: 4 }` by hand, but `Layout::new::<T>` will give `Layout { size_: 8, align_: 4}`, where the size already has padding that accounts for the alignment. (And the existing `debug_assert_eq!` in `Layout::array` already demonstrates that no additional padding is required.)

view details

Nicholas Nethercote

commit sha dbfb91385f7e4c27a6a48ecc3f683e3295af8b49

Add a unit test for zero-sized types in `RawVec`. Because there's some subtle behaviour specific to zero-sized types and it's currently not well tested.

view details

Alessandro Decina

commit sha 1cf37189bc15d0bd4ac25281366d320e4a522b11

Bump compiler-builtins to 0.1.53 Fixes a LLVM crash with the bpf targets

view details

bors

commit sha 454cc5fb86be180b3ec1138b6f2b480fbf3f1388

Auto merge of #91164 - Badel2:usefulness-stack-overflow, r=davidtwco Fix stack overflow in `usefulness.rs` Fix #88747 Applied the suggestion from `@nbdd0121,` not sure if this has any drawbacks. The first call to `ensure_sufficient_stack` is not needed to fix the test case, but I added it to be safe.

view details

Joshua Nelson

commit sha 6e0e22080424e7d8a4b4638bf4fb41e691efb26b

Fix bug where submodules wouldn't be updated when running x.py from a subdirectory Previously, it would concatenate the relative path to the current subdirectory, which looked at the wrong folder. I tested this by checking out `1.56.1`, changing the current directory to `src/`, and running `../x.py build`.

view details

Matthias Krüger

commit sha 324b4bcb3caaaa70476d65c86e8d399f09145bab

Rollup merge of #91169 - RDambrosio016:master, r=bjorn3 Change cg_ssa's get_param to borrow the builder mutably This is a small change to make `get_param` more flexible for codegens that may need to modify things when retrieving function parameters. This will currently only be used by [rustc_codegen_nvvm](https://github.com/Rust-GPU/Rust-CUDA) (my own project), but may be useful to more codegens in the future. This is needed because cg_nvvm needs to remap certain types to libnvvm-friendly types, such as `i128` -> `<2 x i64>`. Because cg_ssa does not give mutable access to the builder, i resorted to using a mutex: ```rs fn get_param(&self, index: usize) -> Self::Value { let val = llvm::get_param(self.llfn(), index as c_uint); trace!("Get param `{:?}`", val); unsafe { let llfnty = LLVMRustGetFunctionType(self.llfn()); let map = self.remapped_integer_args.borrow(); if let Some((_, key)) = map.get(llfnty) { if let Some((_, new_ty)) = key.iter().find(|t| t.0 == index) { trace!("Casting irregular param {:?} to {:?}", val, new_ty); return transmute_llval( *self.llbuilder.lock().unwrap(), &self.cx, val, *new_ty, ); } } val } } ``` However, i predict this is pretty bad for performance, considering how much builders are called during codegen, so i would greatly appreciate having a more flexible API for this.

view details

Matthias Krüger

commit sha fdc305d58d7cf93703a47118538f04b2b53c2873

Rollup merge of #91176 - hermitcore:spin, r=kennytm If the thread does not get the lock in the short term, yield the CPU Reduces on [RustyHermit](https://github.com/hermitcore/rusty-hermit) the amount of wasted processor cycles

view details

push time in 5 days

PullRequestReviewEvent

Pull request review commentrust-lang/rust

Include `lld` in `rust-dev` package

 impl Step for RustDev {             "llvm-bcanalyzer",             "llvm-cov",             "llvm-dwp",+            "lld",

I'm not very familiar with this code - I think it would be better to add in ensure calls in a separate PR.

Aaron1011

comment created time in 5 days

pull request commentrust-lang/rust

Visit `param_env` field in Obligation's `TypeFoldable` impl

The perf regression is really unfortunate - I had hoped that https://github.com/rust-lang/rust/pull/91254 would allow us to recover some of the loss, but it appears to have no impact.

I'll see if there are any call sites that don't actually care about the ParamEnv, and could be adjusted to just visit the predicate. However, this is a correctness fix, do I'm not sure how much can be done to improve the performance.

Aaron1011

comment created time in 6 days

issue openedrust-lang/rustc-perf

Display number of invalidations per query

Slowdowns in incremental benchmarks can often be due to increased query invalidation (adding extra query dependency edges, or making a stable hash dependent on more inputs). It would be useful to display a count/percentage of query invalidations on a per-queery basis, as well as a diff between the old and new runs.

created time in 6 days

pull request commentrust-lang/rust

Visit `param_env` field in Obligation's `TypeFoldable` impl

@estebank I've opened https://github.com/rust-lang/rust/pull/91254 to fix this

Aaron1011

comment created time in 6 days

more