profile
viewpoint

Aaron1011/actix 0

Actor framework for Rust

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

Aaron1011/ammonia 0

An HTML sanitizer

Aaron1011/amy 0

Rust wrapper around epoll and kqueue

Aaron1011/android-sdk-installer 0

Linux utility which aims to automatically install and configures Android SDK, Eclipse ADT Plugin, adds hardware support for devices and enables full MTP support.

Aaron1011/AnimatedPing 0

Animated ping

pull request commentrust-lang/rust

[perf] Skip attempting to run coerce_unsized on an inference variable

It looks like this resulted in clean/baseline-incremental improvements across several different benchmarks, in the range of 1-1.7%.

I have absolutely no idea what's going on with syn-opt.

Aaron1011

comment created time in 6 hours

pull request commentrust-lang/rust

Re-land "add IntoFuture trait and support for await"

I think https://github.com/rust-lang/rust/pull/69218 should help improve performance here - this PR appears to introduce many additional predicates during typeck, which end up getting stalled for several select iterations.

tmandry

comment created time in 8 hours

pull request commentrust-lang/rust

[perf] Skip attempting to run coerce_unsized on an inference variable

Can I get a perf run?

Aaron1011

comment created time in 13 hours

PR opened rust-lang/rust

[perf] Skip attempting to run coerce_unsized on an inference variable

See the included comment for a detailed explanation of why this is sound.

+30 -0

0 comment

1 changed file

pr created time in 13 hours

create barnchAaron1011/rust

branch : perf/skip-coerce-var

created branch time in 13 hours

pull request commentrust-lang/rust

[perf] Skip iterating over impls that could not possibly apply

I'm closing this, as I was unable to make any meaningful improvement locally.

Aaron1011

comment created time in 17 hours

PR closed rust-lang/rust

[perf] Skip iterating over impls that could not possibly apply S-waiting-on-review

Currently, tcx.for_each_relevant_impl invokes the provided callback with every non-blanket impl that has the right 'structure', based on fast_reject::simplify_type. However, this will still consider impls from crates that could not possibly define an impl for self_ty, based on the orphan rule.

For example, imagine we have the following crates and code:

Crate A: trait MyTrait {}

Crate B:

struct CrateBStruct;
impl MyTrait for CrateBStruct

Crate C:

struct CrateCStruct;
impl MyTrait for CrateCStruct

if we call tcx.for_each_relevant_impl with MyTrait and CrateBStruct, we will end up passing impl MyTrait for CrateCStruct to the provided callback. However, crate C does not define MyTrait, nor are any types from crate C used the self type CrateBStruct. This makes it impossible for any impl from crate C to apply (crate C cannot provide a blanket impl, and any non-blanket impls will not apply due to the fact that we don't mention any types for crate C).

This results in unecessary work being performed in the caller of for_each_relevant_impl. For example, trait selection will enter an infcx.probe environment that is guarnateed to fail, resulting in a pointless snapshot and restore.

This PR creates a new version of tcx.for_each_relevant_impl called tcx.for_each_relevant_impl_trait_ref, which takes into account the orphan rule when deciding which impls to pass to the callback. A TraitRef is needed rather than a plain Ty because we allow code like this:

struct MyStruct;
impl PartialEq<MyStruct> for str { ... }

which requires us to consider both type parameters for the trait, as well as the self type.

This implementation uses a conservative overapproximation of the orphan rule. Invoking the callback for every single impl in existence would be perfectly valid (though incredibly inefficient), so it's fine if we have false positives.

Specifically, we check if every type mentioned in the TraitRef (not considering nested types) has a clear 'defining crate'. If so, we require that all impls come from the same crate as one of the types in the TraitRef. If we could not determine a 'defining crate' for any type, we just pass all impls to the callback to be safe.

For now, we treat &_, &mut _, and #[fundamental] types as having no 'defining crate', and revert to the old behavior as described above. This is for both simplicitly and performance - to properly determine the 'defining crate', it would be necessary to recursively 'peel away' such types until we hit a non-fundamental/non-reference type. Otherwise, we will fail to locate impl like:

struct MyStruct<T>(T);
impl<T> ForeignTrait for Box<MyStruct<T>> {}

When trying to find an impl for <Box<MyStruct<_>> as ForeignTrait>, failing to consider #[fundamental] types would cause us to only check for impls in the defining crate of Box (liballoc) and the defining crate of ForeignTrait, meaning that we would incorrectly ignore impls in the crate where MyStruct is defined.

+197 -25

23 comments

5 changed files

Aaron1011

pr closed time in 17 hours

delete branch Aaron1011/actix-web

delete branch : fix/new-remove-pin-unsafe

delete time in 3 days

pull request commentrust-lang/rust

[perf] Skip iterating over impls that could not possibly apply

The initial version gave a small improvement - however, I'm not sure if it's large enough to justify the increased complexity.

I have a few other improvements that I'm trying out locally - I'll push them to this branch, and see if they help.

Aaron1011

comment created time in 3 days

pull request commentrust-lang/rust

[perf] Skip iterating over impls that could not possibly apply

@eddyb: It looks like I skimmed over the fast_reject too quickly, and didn't see that it included the DefId :smile:. This explains why the results were less dramatic than I was expecting.

Aaron1011

comment created time in 4 days

pull request commentrust-lang/rust

Implement unused crate lint for 2018 edition

Even if cargo passes all the dependencies correctly, it would still make sense to configure this lint separately for cases like playground, which adds 100 or so most popular crates to the command line regardless of whether they are used or not.

Could the playground disable this via -A unused_extern_options?

Aaron1011

comment created time in 4 days

pull request commentrust-lang/rust

Properly handle Spans that reference imported SourceFiles

@petrochenkov: Did you have additional concerns beyond #69432?

Aaron1011

comment created time in 4 days

pull request commentrust-lang/rust

Add new `rustc_panic_abort_runtime` attribute for `libpanic_abort`

@RalfJung: This PR addresses a different issue - the metadata that we write out for libpanic_unwind depends on the right flag being magically passed in from bootstrap. This not affected by whether or not we run codegen.

Aaron1011

comment created time in 4 days

pull request commentrust-lang/rust

[perf] Skip iterating over impls that could not possibly apply

@Mark-Simulacrum: From looking at https://perf.rust-lang.org/status.html, it doesn't look like the perf build was actually queued (unless I'm misinterpreting something).

Aaron1011

comment created time in 4 days

pull request commentrust-lang/rust

[perf] Skip iterating over impls that could not possibly apply

Those results are a little underwhelming.

@Mark-Simulacrum Can I get another perf run for the latest commit? Switching over to building a FxHashMap<CrateNum, _> gave me some additional improvement locally.

Aaron1011

comment created time in 5 days

push eventAaron1011/rust

Aaron Hill

commit sha b00c53b2f03d7fa27d5e3fe7d1d440222e3aee5e

Store trait impls in a FxHashMap keyed by CrateNum

view details

push time in 5 days

pull request commentactix/actix-web

Remove uses of Pin::new_unchecked in h1 Dispatcher

The test failures seem unrelated.

Aaron1011

comment created time in 5 days

PR opened actix/actix-web

Remove uses of Pin::new_unchecked in h1 Dispatcher

This removes the last uses of unsafe Pin functions in actix-web.

This PR adds a Pin<Box<_>> wrapper to DispatcherState::Upgrade, State::ExpectCall, and State::ServiceCall.

The previous uses of the futures State::ExpectCall and State::ServiceCall were Undefined Behavior - a future was obtained from self.expect.call or self.service.call, pinned on the stack, and then immediately returned from handle_request. The only alternative to using Box::pin would be to refactor handle_request to write the futures directly into their final location, or avoid polling them before they are returned.

The previous use of DispatcherState::Upgrade doesn't seem to be unsound. However, having data pinned inside an enum that we std::mem::replace would require some careful unsafe code to ensure that we never call std::mem::replace when the active variant contains pinned data. By using Box::pin, we any possibility of future refactoring accidentally introducing undefined behavior.

+13 -27

0 comment

1 changed file

pr created time in 5 days

create barnchAaron1011/actix-web

branch : fix/new-remove-pin-unsafe

created branch time in 5 days

pull request commentrust-lang/rust

[perf] Skip iterating over impls that could not possible apply

If this works out well, then an additional change to consider making trait_impls_of group impls by defining crate, or make a trait_impls_from_crate query that only considers a single crate. This could speed up filtering of impls in for_each_relevant_impl, but could also make it less efficient to traverse all impls of a particular trait.

Aaron1011

comment created time in 5 days

pull request commentrust-lang/rust

[perf] Skip iterating over impls that could not possible apply

I've gotten some favorable-looking results locally, but I'd like to get a perf run to make sure that this change even makes sense to consider. If the perf run looks good, I'll probably want to do some additional refactoring to reduce duplication with the existing orphan_check method.

Aaron1011

comment created time in 5 days

PR opened rust-lang/rust

[perf] Skip iterating over impls that could not possible apply

Currently, tcx.for_each_relevant_impl invokes the provided callback with every non-blanket impl that has the right 'structure', based on fast_reject::simplify_type. However, this will still consider impls from crates that could not possibly define an impl for self_ty, based on the orphan rule.

For example, imagine we have the following crates and code:

Crate A: trait MyTrait {}

Crate B: ```rust struct CrateBStruct; impl MyTrait for CrateBStruct


Crate C: ```rust
struct CrateCStruct;
impl MyTrait for CrateCStruct

if we call tcx.for_each_relevant_impl with MyTrait and CrateBStruct, we will end up passing impl MyTrait for CrateCStruct to the provided callback. However, crate C does not define MyTrait, nor are any types from crate C used the self type CrateBStruct. This makes it impossible for any impl from crate C to apply (crate C cannot provide a blanket impl, and any non-blanket impls will not apply due to the fact that we don't mention any types for crate C).

This results in unecessary work being performed in the caller of for_each_relevant_impl. For example, trait selection will enter an infcx.probe environment that is guarnateed to fail, resulting in a pointless snapshot and restore.

This PR creates a new version of tcx.for_each_relevant_impl called tcx.for_each_relevant_impl_trait_ref, which takes into account the orphan rule when deciding which impls to pass to the callback. A TraitRef is needed rather than a plain Ty because we allow code like this:

struct MyStruct;
impl PartialEq<MyStruct> for str { ... }

which requires us to consider both type parameters for the trait, as well as the self type.

This implementation uses a conservative overapproximation of the orphan rule. Invoking the callback for every single impl in existence would be perfectly valid (though incredibly inefficient), so it's fine if we have false positives.

Specifically, we check if every type mentioned in the TraitRef (not considering nested types) has a clear 'defining crate'. If so, we require that all impls come from the same crate as one of the types in the TraitRef. If we could not determine a 'defining crate' for any type, we just pass all impls to the callback to be safe.

For now, we treat &_, &mut _, and #[fundamental] types as having no 'defining crate', and revert to the old behavior as described above. This is for both simplicitly and performance - to properly determine the 'defining crate', it would be necessary to recursively 'peel away' such types until we hit a non-fundamental/non-reference type. Otherwise, we will fail to locate impl like:

struct MyStruct<T>(T);
impl<T> ForeignTrait for Box<MyStruct<T>> {}

When trying to find an impl for <Box<MyStruct<_>> as ForeignTrait>, failing to consider #[fundamental] types would cause us to only check for impls in the defining crate of Box (liballoc) and the defining crate of ForeignTrait, meaning that we would incorrectly ignore impls in the crate where MyStruct is defined.

+94 -8

0 comment

2 changed files

pr created time in 5 days

create barnchAaron1011/rust

branch : perf/orphan-impl-list

created branch time in 5 days

issue closedactix/actix

Audit remaining uses of unsafe `Pin` functions

PR https://github.com/actix/actix/pull/335 replaces several calls to unsafe Pin functions with the safe pin_project. However, there are still several remaining uses of Pin::get_unchecked_mut. Ideally, all of these calls should be replaced with uses of #[pin_project]. If this is not possible, comments should be added to explain why each call is safe (e.g. how we ensure that that the mutable reference is never moved out of).

closed time in 6 days

Aaron1011

issue commentactix/actix

Audit remaining uses of unsafe `Pin` functions

As of https://github.com/actix/actix/pull/348, all unsafe code in actix is unrelated to pinning.

Aaron1011

comment created time in 6 days

pull request commentactix/actix

Only implement `ActorFuture` for Box where `ActorFuture` is `Unpin`

@Jonathas-Conceicao: I've changed Box::pin to Box::new as you requested.

Aaron1011

comment created time in 6 days

push eventAaron1011/actix

Aaron Hill

commit sha f93713a4ec52dd702d234fb4d55a9ae1907c464c

Only implement `ActorFuture` for Box where `ActorFuture` is `Unpin` This is a breaking change. The previous impl was unsound: it allowed going from a `Pin<&mut Box<F>>` to a `Pin<&mut F>`. However, the fact that `Box<T>` is `Unpin` for all `T` means that it's possible to go from a `Pin<&mut Box<F>>` to a `&mut Box<F>`. This allows a user to construct a `Pin<&mut F>`, and them move the underlying `F` by obtaining a `&mut Box<F>` and calling `mem::swap`. The new impl adds an `Unpin` bound to `F`, bringing it in line with the standard library's impl of `Future` for `Box<F>`.4 We can make `Box<F> where F: ActorFuture` easier to work with by 'porting' a `Future`-related impl from the standard library. By making `Pin<Box<F>>` implement `ActorFuture` (e.g. you can call `poll` on a `Pin<&mut Pin<Box<F>>>`), it's possible to avoid introducing extra `Box`s in many cases. If you have ownership of a `Box<F>`, you can use `Box::pin` to get a `Pin<Box<F>>`, which implements `ActorFuture` *regardless of whether or not `F` is `Unpin`. In a few cases, it was necessary to introduce an extra `Box`. The alternatives would be to add an `Unpin` bound to a public type (e.g. `ResponseActFuture`, or change the signature of a function to take a `Pin<&mut Self>`). Adding a `Box` seemed like the simplest change - the relevant code was already using a `Box`, so this didn't introduce heap allocations into code that previously required no allocations.

view details

push time in 6 days

push eventAaron1011/actix

Aaron Hill

commit sha f2a71b65dc5058ceba33482afcbe3900abb8aefd

Only implement `ActorFuture` for Box where `ActorFuture` is `Unpin` This is a breaking change. The previous impl was unsound: it allowed going from a `Pin<&mut Box<F>>` to a `Pin<&mut F>`. However, the fact that `Box<T>` is `Unpin` for all `T` means that it's possible to go from a `Pin<&mut Box<F>>` to a `&mut Box<F>`. This allows a user to construct a `Pin<&mut F>`, and them move the underlying `F` by obtaining a `&mut Box<F>` and calling `mem::swap`. The new impl adds an `Unpin` bound to `F`, bringing it in line with the standard library's impl of `Future` for `Box<F>`.4 We can make `Box<F> where F: ActorFuture` easier to work with by 'porting' a `Future`-related impl from the standard library. By making `Pin<Box<F>>` implement `ActorFuture` (e.g. you can call `poll` on a `Pin<&mut Pin<Box<F>>>`), it's possible to avoid introducing extra `Box`s in many cases. If you have ownership of a `Box<F>`, you can use `Box::pin` to get a `Pin<Box<F>>`, which implements `ActorFuture` *regardless of whether or not `F` is `Unpin`. In a few cases, it was necessary to introduce an extra `Box`. The alternatives would be to add an `Unpin` bound to a public type (e.g. `ResponseActFuture`, or change the signature of a function to take a `Pin<&mut Self>`). Adding a `Box` seemed like the simplest change - the relevant code was already using a `Box`, so this didn't introduce heap allocations into code that previously required no allocations.

view details

push time in 7 days

PR opened actix/actix

Only implement `ActorFuture` for Box where `ActorFuture` is `Unpin`

This is a breaking change.

The previous impl was unsound: it allowed going from a Pin<&mut Box<F>> to a Pin<&mut F>. However, the fact that Box<T> is Unpin for all T means that it's possible to go from a Pin<&mut Box<F>> to a &mut Box<F>. This allows a user to construct a Pin<&mut F>, and them move the underlying F by obtaining a &mut Box<F> and calling mem::swap.

The new impl adds an Unpin bound to F, bringing it in line with the standard library's impl of Future for Box<F>.4

We can make Box<F> where F: ActorFuture easier to work with by 'porting' a Future-related impl from the standard library. By making Pin<Box<F>> implement ActorFuture (e.g. you can call poll on a Pin<&mut Pin<Box<F>>>), it's possible to avoid introducing extra Boxs in many cases. If you have ownership of a Box<F>, you can use Box::pin to get a Pin<Box<F>>, which implements ActorFuture *regardless of whether or not F is Unpin.

In a few cases, it was necessary to introduce an extra Box. The alternatives would be to add an Unpin bound to a public type (e.g. ResponseActFuture, or change the signature of a function to take a Pin<&mut Self>). Adding a Box seemed like the simplest change - the relevant code was already using a Box, so this didn't introduce heap allocations into code that previously required no allocations.

+26 -10

0 comment

4 changed files

pr created time in 7 days

push eventAaron1011/actix

Aaron Hill

commit sha ff5fdb843a83d8e3da23953ca57366aa842ac30c

Only implement `ActorFuture` for Box where `ActorFuture` is `Unpin` This is a breaking change. The previous impl was unsound: it allowed going from a `Pin<&mut Box<F>>` to a `Pin<&mut F>`. However, the fact that `Box<T>` is `Unpin` for all `T` means that it's possible to go from a `Pin<&mut Box<F>>` to a `&mut Box<F>`. This allows a user to construct a `Pin<&mut F>`, and them move the underlying `F` by obtaining a `&mut Box<F>` and calling `mem::swap`. The new impl adds an `Unpin` bound to `F`, bringing it in line with the standard library's impl of `Future` for `Box<F>`.4 We can make `Box<F> where F: ActorFuture` easier to work with by 'porting' a `Future`-related impl from the standard library. By making `Pin<Box<F>>` implement `ActorFuture` (e.g. you can call `poll` on a `Pin<&mut Pin<Box<F>>>`), it's possible to avoid introducing extra `Box`s in many cases. If you have ownership of a `Box<F>`, you can use `Box::pin` to get a `Pin<Box<F>>`, which implements `ActorFuture` *regardless of whether or not `F` is `Unpin`. In a few cases, it was necessary to introduce an extra `Box`. The alternatives would be to add an `Unpin` bound to a public type (e.g. `ResponseActFuture`, or change the signature of a function to take a `Pin<&mut Self>`). Adding a `Box` seemed like the simplest change - the relevant code was already using a `Box`, so this didn't introduce heap allocations into code that previously required no allocations.

view details

push time in 7 days

create barnchAaron1011/actix

branch : feature/poll-box-actorfuture

created branch time in 7 days

issue commentrust-lang/rust

Occasional non-reproducibility when building rustc

I don't think this should be tagged I-ICE if there's no crash happening.

jgalenson

comment created time in 7 days

PR opened actix/actix

Make more uses of Pin safe

After this PR, the only remaining use of unsafe with Pin comes from impl ActorFuture for Box.

+25 -19

0 comment

3 changed files

pr created time in 7 days

create barnchAaron1011/actix

branch : fix/more-pin-safety

created branch time in 7 days

Pull request review commentrust-lang/rust

mir-interpret: add methods to read/write wide strings

 impl<'mir, 'tcx, M: Machine<'mir, 'tcx>> InterpCx<'mir, 'tcx, M> {         Ok(str)     } +    // Turn the wide MPlace into a OsString (must already be dereferenced!)+    #[cfg(target_os = "windows")]

While this is probably only useful on Windows, I don't think it should be cfg-gated. Having these functions be compiled unconditionally will make it easier for people building on other platfirms to notice if they end up breaking those functions through other changes.

JOE1994

comment created time in 8 days

push eventAaron1011/rust

Mark Rousskov

commit sha 3b92689f3d0c3b90fa01d9873cdf01543d51c000

Relax bounds on HashMap to match hashbrown No functional changes are made, and all APIs are moved to strictly less restrictive bounds. These APIs changed from the old bound listed to no trait bounds: K: Hash + Eq * new * with_capacity K: Eq + Hash, S: BuildHasher * with_hasher * with_capacity_and_hasher * hasher K: Eq + Hash + Debug -> K: Debug S: BuildHasher -> S <HashMap as Debug> K: Eq + Hash -> K S: BuildHasher + Default -> S: Default <HashMap as Default>

view details

Mark Rousskov

commit sha 48859db151b839518bdd9d44a2387c0f6b65d141

Relax bounds on HashSet to match hashbrown No functional changes are made, and all APIs are moved to strictly less restrictive bounds. These APIs changed from the old bound listed to the new bound: T: Hash + Eq -> T * new * with_capacity T: Eq + Hash, S: BuildHasher -> T * with_hasher * with_capacity_and_hasher * hasher T: Eq + Hash + Debug -> T: Debug S: BuildHasher -> S <HashSet as Debug> T: Eq + Hash -> T S: BuildHasher + Default -> S: Default <HashSet as Default>

view details

Tobias Thiel

commit sha 51021b1d421a7d055ff44f9b6afe11377b825c5c

rustc_session: allow overriding lint level of individual lints from a group

view details

Tobias Thiel

commit sha 34417792deed6f0e570e9c7b01a24f1d05b70519

tools/compiletest: fix argument ordering for allowing unused in ui & compile-fail tests

view details

Tobias Thiel

commit sha 21edd2ae2cc4c06d8ea98051c47d24dc3c4e2238

convert match statement to if let

view details

Tobias Thiel

commit sha 3fc9253a5a27771c72429a738d5379c34e1cd924

rustc: add lint level cli ordering into the documentation

view details

Aaron Hill

commit sha 90afc0765e5e536af6307b63e1655a38df06e235

Use a `ParamEnvAnd<Predicate>` for caching in `ObligationForest` Previously, we used a plain `Predicate` to cache results (e.g. successes and failures) in ObligationForest. However, fulfillment depends on the precise `ParamEnv` used, so this is unsound in general. This commit changes the impl of `ForestObligation` for `PendingPredicateObligation` to use `ParamEnvAnd<Predicate>` instead of `Predicate` for the associated type. The associated type and method are renamed from 'predicate' to 'cache_key' to reflect the fact that type is no longer just a predicate.

view details

Steven Degutis

commit sha ac19dffd1eaea34c3861324c2588f9cb1f1489f5

Updating str.chars docs to mention crates.io. This might spare someone else a little time searching the stdlib for unicode/grapheme support.

view details

Oliver Middleton

commit sha 84f3356e0dffc36f57d9be7902822db5d362e24f

Simplify `Skip::nth` and `Skip::last` implementations The main improvement is to make `last` no longer recursive.

view details

Tom Jakubowski

commit sha b60f08bd6d3fbe784eb47a57e0c41954454af3dd

rustdoc: NodeId is now DefId

view details

Tom Jakubowski

commit sha 05c6f329e785c9b53a50217de0f21df906ae7ba0

rustdoc: emit JS paths for struct-like variants On the backend, rustdoc now emits `paths` entries to a crate's search index for struct-like enum variants, and index items of type structfield which belong to such variants point to their variant parents in the `paths` table, rather than their enum grandparents. The path entry for a variant is the fully qualified module path plus the enum name. On the frontend, the search code recognizes structfields belonging to structlike variants in the `paths` table and re-constructs the URL to the field's anchor on the enum documentation page. closes #16017

view details

Guillaume Gomez

commit sha 8ee30dbc1b07ad7fc842ceee6d6729a1377f7a36

Add tests for struct variant field in search

view details

Matthew Jasper

commit sha 91cf0e741186a9fa3bf31b07a65dc89324c10296

Don't requery the param_env of a union Union fields have the ParamEnv of the union.

view details

Matthew Jasper

commit sha 570c1613c1225d5777af5603dcf526da9cf57e19

Remove unnecessary features in rustc_ty

view details

Matthew Jasper

commit sha 39733223fc817efba52a4204dd697192bf5da185

Add IS_MANUALLY_DROP to AdtFlags

view details

Matthew Jasper

commit sha d1965216a34dc2831cf44d2e15ad9d78403d10cc

Improve needs_drop query * Handle cycles in `needs_drop` correctly * Normalize types when computing `needs_drop` * Move queries from rustc to rustc_ty

view details

Matthew Jasper

commit sha d20646b2d8033f31423b5bda3e56776df115e144

Address review comments * Handle arrays with const-generic lengths * Use closure for repeated code.

view details

Matthew Jasper

commit sha 465b86253ce828e215d564fde53adf8742f0e3f6

Use correct `ParamEnv` in `Instance::resolve`

view details

Daniel Henry-Mantilla

commit sha 60274a95fef57a18113f7c48be68be31ece860eb

Added From<Vec<NonZeroU8>> for CString Updated tracking issue number Added safeguards for transmute_vec potentially being factored out elsewhere Clarified comment about avoiding mem::forget Removed unneeded unstable guard Added back a stability annotation for CI Minor documentation improvements Thanks to @Centril's code review Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com> Improved layout checks, type annotations and removed unaccurate comment Removed unnecessary check on array layout Adapt the stability annotation to the new 1.41 milestone Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com> Simplify the implementation. Use `Vec::into_raw_parts` instead of a manual implementation of `Vec::transmute`. If `Vec::into_raw_parts` uses `NonNull` instead, then the code here will need to be adjusted to take it into account (issue #65816) Reduce the whitespace of safety comments

view details

Mazdak Farrokhzad

commit sha 6509db844315882db7ec0b624ca1e7b04d72568d

or_patterns: harden bindings test

view details

push time in 8 days

push eventAaron1011/actix-web

Aaron Hill

commit sha e6811e8818b015c31f88d22bd037d3377deac1c3

Use #[pin_project] with `ConnectorPoolSupport` This removes a use of `Pin::get_unchecked_mut`

view details

push time in 8 days

PR opened actix/actix-web

Use #[pin_project] with `ConnectorPoolSupport`

This removes a use of Pin::get_unchecked_mut

+3 -1

0 comment

1 changed file

pr created time in 8 days

create barnchAaron1011/actix-web

branch : fix/connector-pool-support

created branch time in 8 days

PR opened actix/actix

Remove uses of `Pin::new_unchecked` in `WriterFut`

The struct WriterFut is private, and is only ever constructed when T: Unpin is known to hold. This lets us add a T: Unpin bound to the definition of WriterFut, and use Pin::new instead of Pin::new_unchecked.

+3 -3

0 comment

1 changed file

pr created time in 8 days

push eventAaron1011/actix

Aaron Hill

commit sha da19f87353f0d72bb2a74753e343f7a0ffdd7fe1

Remove uses of `Pin::new_unchecked` in `WriterFut` The struct `WriterFut` is private, and is only ever constructed when `T: Unpin` is known to hold. This lets us add a `T: Unpin` bound to the definition of `WriterFut`, and use `Pin::new` instead of `Pin::new_unchecked`.

view details

push time in 8 days

create barnchAaron1011/actix

branch : fix/add-unpin

created branch time in 8 days

pull request commentrust-lang/rust

Implement unused crate lint for 2018 edition

This is blocked on reaching some kind of decision about how to enable this (on-by-default, off-by-default, or some hybrid).

Aaron1011

comment created time in 9 days

push eventAaron1011/rust

Aaron Hill

commit sha 5e55f55244ec034bdc497821db4067c27a15cf81

Fix tabs

view details

push time in 9 days

pull request commentrust-lang/rust

Permit attributes on 'if' expressions

@Centril: I've added the additional tests you requested, and removed the parser recovery test.

@joshtriplett: I've added the test you suggested.

Aaron1011

comment created time in 9 days

push eventAaron1011/rust

Aaron Hill

commit sha 377ae21a520c92ceb004e1e2bba6984ef5957f37

Extent pretty-print test

view details

push time in 9 days

pull request commentrust-lang-nursery/libbacktrace

Update to latest upstream master

@alexcrichton: Should I make a pull request merging upstream into rust-snapshot-2018-05-22, or should someone make a newer rust-snapshot branches with the fixes from rust-snapshot-2018-05-22 applied?

Aaron1011

comment created time in 9 days

push eventAaron1011/rust

Aaron Hill

commit sha ade82f9477d3ae440d00676d1df91d4832ba09b8

Test that stmt_expr_attrs properly gates if-attrs

view details

Aaron Hill

commit sha 52d6f5724a14678232cf4a93e38bf62cfb6573e7

Test trying to cfg-remove an `if` expression

view details

Aaron Hill

commit sha 57b056025971c4db44e4f2bc7eec10b3c2ec5a4e

Remove recovery test

view details

Aaron Hill

commit sha 34bf444a187fc5f1e6118e04f34562e34aa0991d

Add run-pass test suggested by @joshtriplett

view details

Aaron Hill

commit sha c843f9729cbb13c39f655e7b7ff61ec6d4b43a44

Move if-attr tests to their own directory

view details

Aaron Hill

commit sha 1f67aaff35ee82cfcf28c8c5e2e0ca128bd5044e

Test that cfg-gated if-exprs are not type-checked

view details

push time in 9 days

issue commentrust-lang/rust

Tracking issue for RFC 2091: Implicit caller location

I have some code locally which serializes hygiene information, but it's currently blocked on https://github.com/rust-lang/rust/pull/68941

aturon

comment created time in 10 days

issue commentrust-lang/rust

Rustdoc cannot infer type when using type_alias_impl_trait, while rustc works

@jonhoo: I haven't done any work on this issue as of yet.

bjorn3

comment created time in 11 days

startedellbrid/krabs

started time in 11 days

push eventAaron1011/rust

Aaron Hill

commit sha 7a4f921c6fc26eba9b2324e679c0b028b9ea3925

Run fmt

view details

push time in 11 days

Pull request review commentrust-lang/rfcs

RFC: Eager Macro Expansion

+- Feature Name: `eager_macro_expansion`+- Start Date: 2018-01-26+- RFC PR: (leave this empty)+- Rust Issue: (leave this empty)++# Summary++Expose an API for procedural macros to opt in to eager expansion. This will:+* Allow procedural and declarative macros to handle unexpanded macro calls that+  are passed as inputs,+* Allow macros to access the results of macro calls that they construct+  themselves,+* Enable macros to be used where the grammar currently forbids it.++# Motivation++## Expanding macros in input ++There are a few places where proc macros may encounter unexpanded macros in+their input:++* In declarative macros:+    ```rust+    env!(concat!("PA", "TH"));+    //   ^^^^^^^^^^^^^^^^^^^+    // Currently, `std::env!` is a compiler-builtin macro because it often+    // needs to expand input like this, and 'normal' macros aren't able+    // to do so.+    ```++* In procedural macros:+    ```rust+    my_proc_macro!(concat!("hello", "world"));+    //             ^^^^^^^^^^^^^^^^^^^^^^^^^+    // This call isn't expanded before being passed to `my_proc_macro`, and+    // can't be since proc macros are passed opaque token streams by design.+    ```++* In attribute macros:+    ```rust+    #[my_attr_macro(x = a_macro_call!(...))]+    //                  ^^^^^^^^^^^^^^^^^^+    // This call isn't expanded before being passed to `my_attr_macro`, and+    // can't be since attr macros are passed opaque token streams by design.+    struct X {+        my_field_definition_macro!(...)+    //  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Same with this one.+    }+    ```++In these situations, macros need to either re-emit the input macro invocation+as part of their token output, or simply reject the input. If the proc macro+needs to inspect the result of the macro call (for instance, to check or edit+it, or to re-export a hygienic symbol defined in it), the author is currently+unable to do so.++Giving proc macro authors the ability to handle these situations will allow+proc macros to 'just work' in more contexts, and without surprising users who+expect macro calls to interact well with more parts of the language.++As a side note, allowing macro calls in built-in attributes would solve a few+outstanding issues (see+[rust-lang/rust#18849](https://github.com/rust-lang/rust/issues/18849) for an+example).++An older motivation to allow macro calls in attributes was to get+`#[doc(include_str!("path/to/doc.txt"))]` working, in order to provide an+ergonomic way to keep documentation outside of Rust source files. This was+eventually emulated by the accepted [RFC+1990](https://github.com/rust-lang/rfcs/pull/1990), indicating that macros in+attributes could be used to solve problems at least important enough to go+through the RFC process.++## Interpolating macros in output++Macros are currently not allowed in certain syntactic positions. Famously, they+aren't allowed in identifier position, which makes `concat_idents!` [almost+useless](https://github.com/rust-lang/rust/issues/29599). If macro authors have+access to eager expansion, they could eagerly expand `concat_idents!` and+interpolate the resulting token into their output.++# Guide-level explanation++We expose the following API in the `proc_macro` crate, to allow proc macro+authors to iteratively expand all macros within a token stream:++```rust+use proc_macro::{LexError, Diagnostic, TokenStream};++pub struct ExpansionBuilder { /* No public fields. */ }+pub enum ExpansionError {+    LexError(LexError),+    ParseError(Diagnostic),+    MissingDefinition(Diagnostic),+    /* What other errors do we want to report?+       What failures can the user reasonably handle? */+}++impl ExpansionBuilder {+    /// Creates a new macro expansion request to iteratively expand all macro+    /// invocations that occur in `tokens`.+    ///+    /// Expansion results will be interpolated within the input stream before+    /// being returned.+    ///+    /// `tokens` should parse as valid Rust -- for instance, as an item or+    /// expression.+    pub fn from_tokens(tokens: TokenStream) -> Self;++    /// Sends the expansion request to the compiler, then awaits the results of+    /// expansion.+    ///+    /// The main causes for an expansion not completing right away are:+    /// - Procedural macros performing IO or complex analysis.

My main concern is over the language "Procedural macros performing IO or complex analysis" - this sounds like expanding a proc macro that does not "perform or complex analysis" could cause Poll::Ready to be returned immediately. That is, the implementation of expand might wait for some short period of time to see if the invoked proc-macro will compete "quickly enough".

pierzchalski

comment created time in 11 days

push eventAaron1011/rust

Tobias Thiel

commit sha 51021b1d421a7d055ff44f9b6afe11377b825c5c

rustc_session: allow overriding lint level of individual lints from a group

view details

Tobias Thiel

commit sha 34417792deed6f0e570e9c7b01a24f1d05b70519

tools/compiletest: fix argument ordering for allowing unused in ui & compile-fail tests

view details

Tobias Thiel

commit sha 21edd2ae2cc4c06d8ea98051c47d24dc3c4e2238

convert match statement to if let

view details

Tobias Thiel

commit sha 3fc9253a5a27771c72429a738d5379c34e1cd924

rustc: add lint level cli ordering into the documentation

view details

Steven Degutis

commit sha ac19dffd1eaea34c3861324c2588f9cb1f1489f5

Updating str.chars docs to mention crates.io. This might spare someone else a little time searching the stdlib for unicode/grapheme support.

view details

Tom Jakubowski

commit sha b60f08bd6d3fbe784eb47a57e0c41954454af3dd

rustdoc: NodeId is now DefId

view details

Tom Jakubowski

commit sha 05c6f329e785c9b53a50217de0f21df906ae7ba0

rustdoc: emit JS paths for struct-like variants On the backend, rustdoc now emits `paths` entries to a crate's search index for struct-like enum variants, and index items of type structfield which belong to such variants point to their variant parents in the `paths` table, rather than their enum grandparents. The path entry for a variant is the fully qualified module path plus the enum name. On the frontend, the search code recognizes structfields belonging to structlike variants in the `paths` table and re-constructs the URL to the field's anchor on the enum documentation page. closes #16017

view details

Guillaume Gomez

commit sha 8ee30dbc1b07ad7fc842ceee6d6729a1377f7a36

Add tests for struct variant field in search

view details

Dylan MacKenzie

commit sha 95186201724a087bacafc74317722314f203cfdc

Use `ResultsCursor` for `elaborate_drops` The old code hard-coded the transfer function for the initialized places analyses.

view details

Dylan MacKenzie

commit sha f0260ae196b62f27c64738d52519efb424724915

Use `seek_before` instead of `seek_after`

view details

Dylan MacKenzie

commit sha 2aa39350d3dde13f5e82f24d42a51cbfe92f723e

Use more descriptive name to get `InitializationData` state

view details

Dylan MacKenzie

commit sha 26451d007e7482f0c4cdae152a972f4e7c8bf970

Print flow state in debug messages for `find_dead_unwinds`

view details

Dylan MacKenzie

commit sha 5c473a059e26614b65414cfb8cf75c283cda5a87

Don't print block exit state if unchanged

view details

Vadim Petrochenkov

commit sha dcad07af8aa831344fd3be353c71379854637c21

parser: `macro_rules` is a weak keyword

view details

Amos Onn

commit sha 302b9e4b540cc352e75d3de6f803a99147107a50

Improve #Safety in various methods in core::ptr s/for reads and writes/for both ...

view details

Amos Onn

commit sha 351782d30aaa6e15204e17ecdd51ac1e712685cf

Improve #Safety of core::ptr::replace Added missing condition: `dst` must be readable

view details

Amos Onn

commit sha 40ca16794456e9b1520bba6d887a176395f127f0

Improve #Safety in various methods in core::ptr For all methods which read a value of type T, `read`, `read_unaligned`, `read_volatile` and `replace`, added missing constraint: The value they point to must be properly initialized

view details

Guillaume Gomez

commit sha cadf9efad123a62472cad45f22569747cc599256

Clean up E0309 explanation

view details

John Kåre Alsaker

commit sha a7db5051d14994474c641328333884aeba70ca25

Treat NodeIs as pure values for incremental compilation

view details

John Kåre Alsaker

commit sha 8a37811e2c3b89beb135cf96dcb5d887a6262751

Panic when hashing node IDs

view details

push time in 11 days

push eventAaron1011/rust

Tobias Thiel

commit sha 51021b1d421a7d055ff44f9b6afe11377b825c5c

rustc_session: allow overriding lint level of individual lints from a group

view details

Tobias Thiel

commit sha 34417792deed6f0e570e9c7b01a24f1d05b70519

tools/compiletest: fix argument ordering for allowing unused in ui & compile-fail tests

view details

Tobias Thiel

commit sha 21edd2ae2cc4c06d8ea98051c47d24dc3c4e2238

convert match statement to if let

view details

Tobias Thiel

commit sha 3fc9253a5a27771c72429a738d5379c34e1cd924

rustc: add lint level cli ordering into the documentation

view details

Steven Degutis

commit sha ac19dffd1eaea34c3861324c2588f9cb1f1489f5

Updating str.chars docs to mention crates.io. This might spare someone else a little time searching the stdlib for unicode/grapheme support.

view details

Tom Jakubowski

commit sha b60f08bd6d3fbe784eb47a57e0c41954454af3dd

rustdoc: NodeId is now DefId

view details

Tom Jakubowski

commit sha 05c6f329e785c9b53a50217de0f21df906ae7ba0

rustdoc: emit JS paths for struct-like variants On the backend, rustdoc now emits `paths` entries to a crate's search index for struct-like enum variants, and index items of type structfield which belong to such variants point to their variant parents in the `paths` table, rather than their enum grandparents. The path entry for a variant is the fully qualified module path plus the enum name. On the frontend, the search code recognizes structfields belonging to structlike variants in the `paths` table and re-constructs the URL to the field's anchor on the enum documentation page. closes #16017

view details

Guillaume Gomez

commit sha 8ee30dbc1b07ad7fc842ceee6d6729a1377f7a36

Add tests for struct variant field in search

view details

Dylan MacKenzie

commit sha 95186201724a087bacafc74317722314f203cfdc

Use `ResultsCursor` for `elaborate_drops` The old code hard-coded the transfer function for the initialized places analyses.

view details

Dylan MacKenzie

commit sha f0260ae196b62f27c64738d52519efb424724915

Use `seek_before` instead of `seek_after`

view details

Dylan MacKenzie

commit sha 2aa39350d3dde13f5e82f24d42a51cbfe92f723e

Use more descriptive name to get `InitializationData` state

view details

Dylan MacKenzie

commit sha 26451d007e7482f0c4cdae152a972f4e7c8bf970

Print flow state in debug messages for `find_dead_unwinds`

view details

Dylan MacKenzie

commit sha 5c473a059e26614b65414cfb8cf75c283cda5a87

Don't print block exit state if unchanged

view details

Vadim Petrochenkov

commit sha dcad07af8aa831344fd3be353c71379854637c21

parser: `macro_rules` is a weak keyword

view details

Amos Onn

commit sha 302b9e4b540cc352e75d3de6f803a99147107a50

Improve #Safety in various methods in core::ptr s/for reads and writes/for both ...

view details

Amos Onn

commit sha 351782d30aaa6e15204e17ecdd51ac1e712685cf

Improve #Safety of core::ptr::replace Added missing condition: `dst` must be readable

view details

Amos Onn

commit sha 40ca16794456e9b1520bba6d887a176395f127f0

Improve #Safety in various methods in core::ptr For all methods which read a value of type T, `read`, `read_unaligned`, `read_volatile` and `replace`, added missing constraint: The value they point to must be properly initialized

view details

Guillaume Gomez

commit sha cadf9efad123a62472cad45f22569747cc599256

Clean up E0309 explanation

view details

John Kåre Alsaker

commit sha a7db5051d14994474c641328333884aeba70ca25

Treat NodeIs as pure values for incremental compilation

view details

John Kåre Alsaker

commit sha 8a37811e2c3b89beb135cf96dcb5d887a6262751

Panic when hashing node IDs

view details

push time in 11 days

pull request commentrust-lang/rust

Implement unused crate lint for 2018 edition

An alternative would be to add the ability to tell rust to ignore crates for the purposes of this lint. This could be applied to panic runtime crates, as well as dev-dependencies.

Aaron1011

comment created time in 12 days

pull request commentrust-lang/rust

Implement unused crate lint for 2018 edition

We could potentially have Cargo disable the lint (split the new part into a lint called unused_extern_prelude and pass -A unused_extern_prelude) if you're building a multi-target crate. Once Cargo gains better support for per-target dependencies, we could remove it.

Aaron1011

comment created time in 12 days

push eventAaron1011/rust

Aaron Hill

commit sha e940496ffb1afd5c8c9e34dd4b1edd5df02c80da

Apply wording change suggested by @matthewjasper

view details

push time in 12 days

pull request commentrust-lang/rust

Propagate lifetime resolution errors into tcx.type_of

@matthewjasper: You're right - there are still issues with lifetimes in nested opaque types (see https://github.com/rust-lang/rust/issues/69137). This PR doesn't fix those errors - it just ensures that we properly bail out when errors do occur, since opaque type inference may implicitly assume that the opaque type has sane generics.

Aaron1011

comment created time in 12 days

Pull request review commentrust-lang/rfcs

RFC: Eager Macro Expansion

+- Feature Name: `eager_macro_expansion`+- Start Date: 2018-01-26+- RFC PR: (leave this empty)+- Rust Issue: (leave this empty)++# Summary++Expose an API for procedural macros to opt in to eager expansion. This will:+* Allow procedural and declarative macros to handle unexpanded macro calls that+  are passed as inputs,+* Allow macros to access the results of macro calls that they construct+  themselves,+* Enable macros to be used where the grammar currently forbids it.++# Motivation++## Expanding macros in input ++There are a few places where proc macros may encounter unexpanded macros in+their input:++* In declarative macros:+    ```rust+    env!(concat!("PA", "TH"));+    //   ^^^^^^^^^^^^^^^^^^^+    // Currently, `std::env!` is a compiler-builtin macro because it often+    // needs to expand input like this, and 'normal' macros aren't able+    // to do so.+    ```++* In procedural macros:+    ```rust+    my_proc_macro!(concat!("hello", "world"));+    //             ^^^^^^^^^^^^^^^^^^^^^^^^^+    // This call isn't expanded before being passed to `my_proc_macro`, and+    // can't be since proc macros are passed opaque token streams by design.+    ```++* In attribute macros:+    ```rust+    #[my_attr_macro(x = a_macro_call!(...))]+    //                  ^^^^^^^^^^^^^^^^^^+    // This call isn't expanded before being passed to `my_attr_macro`, and+    // can't be since attr macros are passed opaque token streams by design.+    struct X {+        my_field_definition_macro!(...)+    //  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Same with this one.+    }+    ```++In these situations, macros need to either re-emit the input macro invocation+as part of their token output, or simply reject the input. If the proc macro+needs to inspect the result of the macro call (for instance, to check or edit+it, or to re-export a hygienic symbol defined in it), the author is currently+unable to do so.++Giving proc macro authors the ability to handle these situations will allow+proc macros to 'just work' in more contexts, and without surprising users who+expect macro calls to interact well with more parts of the language.++As a side note, allowing macro calls in built-in attributes would solve a few+outstanding issues (see+[rust-lang/rust#18849](https://github.com/rust-lang/rust/issues/18849) for an+example).++An older motivation to allow macro calls in attributes was to get+`#[doc(include_str!("path/to/doc.txt"))]` working, in order to provide an+ergonomic way to keep documentation outside of Rust source files. This was+eventually emulated by the accepted [RFC+1990](https://github.com/rust-lang/rfcs/pull/1990), indicating that macros in+attributes could be used to solve problems at least important enough to go+through the RFC process.++## Interpolating macros in output++Macros are currently not allowed in certain syntactic positions. Famously, they+aren't allowed in identifier position, which makes `concat_idents!` [almost+useless](https://github.com/rust-lang/rust/issues/29599). If macro authors have+access to eager expansion, they could eagerly expand `concat_idents!` and+interpolate the resulting token into their output.++# Guide-level explanation++We expose the following API in the `proc_macro` crate, to allow proc macro+authors to iteratively expand all macros within a token stream:++```rust+use proc_macro::{LexError, Diagnostic, TokenStream};++pub struct ExpansionBuilder { /* No public fields. */ }+pub enum ExpansionError {+    LexError(LexError),+    ParseError(Diagnostic),+    MissingDefinition(Diagnostic),+    /* What other errors do we want to report?+       What failures can the user reasonably handle? */+}++impl ExpansionBuilder {+    /// Creates a new macro expansion request to iteratively expand all macro+    /// invocations that occur in `tokens`.+    ///+    /// Expansion results will be interpolated within the input stream before+    /// being returned.+    ///+    /// `tokens` should parse as valid Rust -- for instance, as an item or+    /// expression.+    pub fn from_tokens(tokens: TokenStream) -> Self;++    /// Sends the expansion request to the compiler, then awaits the results of+    /// expansion.+    ///+    /// The main causes for an expansion not completing right away are:+    /// - Procedural macros performing IO or complex analysis.

By 'not completing right away', do you mean 'returing Poll::Pending'?

The best practice for an implementation of Future::poll is to return quickly. This suggests that the Future returned by expand should deterministically:

  1. Return Poll::Ready if no macros needed to be expanded. We could possibly expand macro_rules! macros, since they don't require running arbitrary user code.
  2. Return Poll::Pending if we needed to start the expansion of any proc macros. When all of the invoked proc macros complete, Waker::wake will (somehow) be called, at which point the future will return Poll::Ready
pierzchalski

comment created time in 12 days

Pull request review commentrust-lang/rfcs

RFC: Eager Macro Expansion

+- Feature Name: `eager_macro_expansion`+- Start Date: 2018-01-26+- RFC PR: (leave this empty)+- Rust Issue: (leave this empty)++# Summary++Expose an API for procedural macros to opt in to eager expansion. This will:+* Allow procedural and declarative macros to handle unexpanded macro calls that+  are passed as inputs,+* Allow macros to access the results of macro calls that they construct+  themselves,+* Enable macros to be used where the grammar currently forbids it.++# Motivation++## Expanding macros in input ++There are a few places where proc macros may encounter unexpanded macros in+their input:++* In declarative macros:+    ```rust+    env!(concat!("PA", "TH"));+    //   ^^^^^^^^^^^^^^^^^^^+    // Currently, `std::env!` is a compiler-builtin macro because it often+    // needs to expand input like this, and 'normal' macros aren't able+    // to do so.+    ```++* In procedural macros:+    ```rust+    my_proc_macro!(concat!("hello", "world"));+    //             ^^^^^^^^^^^^^^^^^^^^^^^^^+    // This call isn't expanded before being passed to `my_proc_macro`, and+    // can't be since proc macros are passed opaque token streams by design.+    ```++* In attribute macros:+    ```rust+    #[my_attr_macro(x = a_macro_call!(...))]+    //                  ^^^^^^^^^^^^^^^^^^+    // This call isn't expanded before being passed to `my_attr_macro`, and+    // can't be since attr macros are passed opaque token streams by design.+    struct X {+        my_field_definition_macro!(...)+    //  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Same with this one.+    }+    ```++In these situations, macros need to either re-emit the input macro invocation+as part of their token output, or simply reject the input. If the proc macro+needs to inspect the result of the macro call (for instance, to check or edit+it, or to re-export a hygienic symbol defined in it), the author is currently+unable to do so.++Giving proc macro authors the ability to handle these situations will allow+proc macros to 'just work' in more contexts, and without surprising users who+expect macro calls to interact well with more parts of the language.++As a side note, allowing macro calls in built-in attributes would solve a few+outstanding issues (see+[rust-lang/rust#18849](https://github.com/rust-lang/rust/issues/18849) for an+example).++An older motivation to allow macro calls in attributes was to get+`#[doc(include_str!("path/to/doc.txt"))]` working, in order to provide an+ergonomic way to keep documentation outside of Rust source files. This was+eventually emulated by the accepted [RFC+1990](https://github.com/rust-lang/rfcs/pull/1990), indicating that macros in+attributes could be used to solve problems at least important enough to go+through the RFC process.++## Interpolating macros in output++Macros are currently not allowed in certain syntactic positions. Famously, they+aren't allowed in identifier position, which makes `concat_idents!` [almost+useless](https://github.com/rust-lang/rust/issues/29599). If macro authors have+access to eager expansion, they could eagerly expand `concat_idents!` and+interpolate the resulting token into their output.++# Guide-level explanation++We expose the following API in the `proc_macro` crate, to allow proc macro+authors to iteratively expand all macros within a token stream:++```rust+use proc_macro::{LexError, Diagnostic, TokenStream};++pub struct ExpansionBuilder { /* No public fields. */ }+pub enum ExpansionError {+    LexError(LexError),+    ParseError(Diagnostic),+    MissingDefinition(Diagnostic),+    /* What other errors do we want to report?+       What failures can the user reasonably handle? */+}++impl ExpansionBuilder {+    /// Creates a new macro expansion request to iteratively expand all macro+    /// invocations that occur in `tokens`.+    ///+    /// Expansion results will be interpolated within the input stream before+    /// being returned.+    ///+    /// `tokens` should parse as valid Rust -- for instance, as an item or+    /// expression.+    pub fn from_tokens(tokens: TokenStream) -> Self;++    /// Sends the expansion request to the compiler, then awaits the results of+    /// expansion.+    ///+    /// The main causes for an expansion not completing right away are:+    /// - Procedural macros performing IO or complex analysis.+    /// - The input token stream referring to a macro that hasn't been defined+    ///   yet.+    pub async fn expand(self) -> Result<TokenStream, ExpansionError>;+}+```++## Simple examples++Here is an example showing how a proc macro can find out what the result of+`concat!("hello ", "world!")` is. We assume we have access to a function+`await_future<T>(impl Future<T>) -> T` which polls a future to completion and

How would this work in practice? Can this be any function (e.g. tokio::Runtime::block_on), or is this a compiler builtin?

Since proc-macros are currently run in a different process, there needs to be some way of ensuring that Waker::wake can actually get called on the Waker that (implicitly) get passed to Expand

pierzchalski

comment created time in 12 days

Pull request review commentrust-lang/rfcs

RFC: Eager Macro Expansion

+- Feature Name: `eager_macro_expansion`+- Start Date: 2018-01-26+- RFC PR: (leave this empty)+- Rust Issue: (leave this empty)++# Summary++Expose an API for procedural macros to opt in to eager expansion. This will:+* Allow procedural and declarative macros to handle unexpanded macro calls that+  are passed as inputs,+* Allow macros to access the results of macro calls that they construct+  themselves,+* Enable macros to be used where the grammar currently forbids it.++# Motivation++## Expanding macros in input ++There are a few places where proc macros may encounter unexpanded macros in+their input:++* In declarative macros:+    ```rust+    env!(concat!("PA", "TH"));+    //   ^^^^^^^^^^^^^^^^^^^+    // Currently, `std::env!` is a compiler-builtin macro because it often+    // needs to expand input like this, and 'normal' macros aren't able+    // to do so.+    ```++* In procedural macros:+    ```rust+    my_proc_macro!(concat!("hello", "world"));+    //             ^^^^^^^^^^^^^^^^^^^^^^^^^+    // This call isn't expanded before being passed to `my_proc_macro`, and+    // can't be since proc macros are passed opaque token streams by design.+    ```++* In attribute macros:+    ```rust+    #[my_attr_macro(x = a_macro_call!(...))]+    //                  ^^^^^^^^^^^^^^^^^^+    // This call isn't expanded before being passed to `my_attr_macro`, and+    // can't be since attr macros are passed opaque token streams by design.+    struct X {+        my_field_definition_macro!(...)+    //  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Same with this one.+    }+    ```++In these situations, macros need to either re-emit the input macro invocation+as part of their token output, or simply reject the input. If the proc macro+needs to inspect the result of the macro call (for instance, to check or edit+it, or to re-export a hygienic symbol defined in it), the author is currently+unable to do so.++Giving proc macro authors the ability to handle these situations will allow+proc macros to 'just work' in more contexts, and without surprising users who+expect macro calls to interact well with more parts of the language.++As a side note, allowing macro calls in built-in attributes would solve a few+outstanding issues (see+[rust-lang/rust#18849](https://github.com/rust-lang/rust/issues/18849) for an+example).++An older motivation to allow macro calls in attributes was to get+`#[doc(include_str!("path/to/doc.txt"))]` working, in order to provide an+ergonomic way to keep documentation outside of Rust source files. This was+eventually emulated by the accepted [RFC+1990](https://github.com/rust-lang/rfcs/pull/1990), indicating that macros in+attributes could be used to solve problems at least important enough to go+through the RFC process.++## Interpolating macros in output++Macros are currently not allowed in certain syntactic positions. Famously, they+aren't allowed in identifier position, which makes `concat_idents!` [almost+useless](https://github.com/rust-lang/rust/issues/29599). If macro authors have+access to eager expansion, they could eagerly expand `concat_idents!` and+interpolate the resulting token into their output.++# Guide-level explanation++We expose the following API in the `proc_macro` crate, to allow proc macro+authors to iteratively expand all macros within a token stream:++```rust+use proc_macro::{LexError, Diagnostic, TokenStream};++pub struct ExpansionBuilder { /* No public fields. */ }+pub enum ExpansionError {+    LexError(LexError),+    ParseError(Diagnostic),+    MissingDefinition(Diagnostic),+    /* What other errors do we want to report?+       What failures can the user reasonably handle? */+}++impl ExpansionBuilder {+    /// Creates a new macro expansion request to iteratively expand all macro

I think it would be more useful to be able to expand invocations one 'layer' at a time (e.g. expand all invocations in the TokenStream, but don't recursively expand any new invocations that appear). This would allow proc macros to avoid unnecessary work when they only care about the result of a particular expansion.

For example, a macro might want to evaluate something like quote! { some_macro!($user_input) } purely for its side effects (if some_macro! might emit an error), and not actually care about expanding any other macros that occur in the output of some_macro!.

An 'iterative expansion' method could be built on top of this, possibly as a helper method that avoids repeatedly .awaiting the result.

pierzchalski

comment created time in 12 days

pull request commentrust-lang/rust

Implement unused crate lint for 2018 edition

For example, if you have multiple bin targets, and only one of them uses a dependency, you have to squelch it in all the other targets (lib, other bins, examples, integration tests, benchmarks). Same with dev-dependencies, where it is only used in one example or test, then all other targets will get warnings. For larger projects, this could be very frustrating.

I see - that's quite unfortunate.

Perhaps this could be "allow" by default and make it opt-in?

I'm definitely biased, but I think this lint loses a lot of value if it's opt-it. Removing unused dependencies improves build times for both your own crates as well as downstream crates - it would be really nice if we could warn about this by default.

Maybe when Cargo has per-target controls, it will be easier to silence the warnings and it could be switched to "warn" by default?

Is there a tracking issue or RFC for that kind of per-target control?

Aaron1011

comment created time in 12 days

Pull request review commentrust-lang/rust

Implement unused crate lint for 2018 edition

 extern crate libc; #[macro_use] extern crate cfg_if; +// Suppress unused crate lints:+// when #[cfg(parallel_compiler)], there will be no uses+// of these crates+use rayon as _;+use crossbeam_utils as _;+use rayon_core as _;

AFAIK, Cargo features are the only way to conditionally enable dependencies.

Aaron1011

comment created time in 12 days

push eventAaron1011/rust

Aaron Hill

commit sha fa7b3fad763086ae3900e5f09e6af383b1214763

Don't require DefId to exist in pretty printing I have no idea how this was never hit before...

view details

Aaron Hill

commit sha 6537794523b354e9e36e533443ad84c2527b3b71

Fix tests

view details

push time in 12 days

push eventAaron1011/rust

Aaron Hill

commit sha 0b364527501cc96054b1968956b6b5b5aeea880d

Run ./x.py fmt

view details

push time in 12 days

pull request commentrust-lang/rust

Implement unused crate lint for 2018 edition

This ended up catching several unused crates within the compiler itself, which I fixed. Several crates needed suppressions due to rustc-specific quirks (forcing things to end up in the sysroot, or #[cfg(parallel_compiler)]-related dependencies that are unused with a non-parallel build).

Aaron1011

comment created time in 12 days

PR opened rust-lang/rust

Implement unused crate lint for 2018 edition

Fixes #57274

This PR fixes the unused_extern_crate lint to work with the 2018 edition. We now separately track whether or not crates in the extern prelude ended up getting used, and lint those that do not.

Notes:

  • This lint ignores crates that have an extern crate statement. That is, exern crate mycrate as renamed will not trigger a lint for mycrate (but the existing extern crate-based lints will still run). This avoids false-positives when #[macro_use] is involved, and allows this lint to be suppressed using either use mycrate as _ or extern mycrate.
  • I added in a hack which ignores crates named panic_abort and panic_unwind, to avoid lints in libstd. Ideally, we could just do use panic_abort as _ and use panic_unwind as _ - however, this currently triggers an error due to two different panic runtimes being linked in.
  • The extern crate-based lint performs several checks on the metadata of unused crates (e.g. is_compiler_builtins) to see if it should skip linting an otherwise unused crate. Unfortuantely, the nature of the extern prelude means that if a crate ends up unused, we will never have loaded the metadata for it. Unless we want to deliberately load unused crates during a lint (which seems like a horrible hack), we can only use command line flags to determine if we should skip linting a crate. This prevents us from detecting panic_abort and panic_unwind via crate metadata instead of crate names.
+152 -45

0 comment

20 changed files

pr created time in 12 days

create barnchAaron1011/rust

branch : feature/final-lint-unused-crate

created branch time in 12 days

issue openedrust-lang/rust-clippy

New lint: using `#[macro_use]` instead of a `use` statement

In the Rust 2018 edition, you can directly import exported macros via a normal use statement, instead of using the blanket #[macro_use] attr. This makes it clear exactly which items you are importing, and avoids the need to use extern crate.

As far as I know, there are no cases where #[macro_use] works but use some_crate::some_macro doesn't.

created time in 12 days

PR opened rust-lang-nursery/libbacktrace

Update to latest upstream master

This pulls in a fix for https://github.com/ianlancetaylor/libbacktrace/issues/32

+19455 -5178

0 comment

64 changed files

pr created time in 12 days

create barnchAaron1011/libbacktrace

branch : update-master

created branch time in 12 days

fork Aaron1011/libbacktrace

A C library that may be linked into a C/C++ program to produce symbolic backtraces

fork in 12 days

push eventAaron1011/rust

Aaron Hill

commit sha d9c12d1c00958bc3b1daf52a37afa7ed6a6a0952

Test #[allow(unused)] on `if` expression

view details

push time in 13 days

push eventAaron1011/rust

Aaron Hill

commit sha 78df914695e553b000b7ea5ea9c0cf17299cc36b

Test #[allow(unused)] on `if` expression

view details

push time in 13 days

pull request commentrust-lang/rust

Permit attributes on 'if' expressions

r? @Centril

Aaron1011

comment created time in 13 days

PR closed rust-lang/rust

Syntactically permit attributes on 'if' expressions S-waiting-on-author T-lang needs-fcp relnotes

Fixes #68618

Previously, attributes on 'if' expressions (e.g. #[attr] if true {}) were disallowed during parsing. This made it impossible for macros to perform any custom handling of such attributes (e.g. stripping them away), since a compilation error would be emitted before they ever had a chance to run.

This PR permits attributes on 'if' expressions ('if-attrs' from here on) syntactically, i.e. during parsing. We instead deny if-attrs during AST validation, which occurs after all macro expansions have run.

This is a conservative change which allows more code to be processed by macros. It does not commit us to semantically accepting if-attrs. For example, the following code is not allowed even with this PR:

fn builtin_attr() {
    #[allow(warnings)] if true {}
}

fn custom_attr() {
    #[my_proc_macro_attr] if true {}
}

However, the following code is accepted

#[cfg(FALSE)]
fn foo() {
    #[allow(warnings)] if true {}
    #[my_custom_attr] if true {}
}

#[my_custom_attr]
fn use_within_body() {
    #[allow(warnings)] if true {}
    #[my_custom_attr] if true {}
}
+289 -78

20 comments

15 changed files

Aaron1011

pr closed time in 13 days

pull request commentrust-lang/rust

Syntactically permit attributes on 'if' expressions

Closing in favor of https://github.com/rust-lang/rust/pull/69201, which allows if-attrs both syntactically and semantically.

Aaron1011

comment created time in 13 days

PR opened rust-lang/rust

Permit attributes on 'if' expressions

Previously, attributes on 'if' expressions (e.g. #[attr] if true {}) were disallowed during parsing. This made it impossible for macros to perform any custom handling of such attributes (e.g. stripping them away), since a compilation error would be emitted before they ever had a chance to run.

This PR permits attributes on 'if' expressions ('if-attrs' from here on). Both built-in attributes (e.g. #[allow], #[cfg]) are supported.

We still do not accept attributes on 'other parts' of an if-else chain. That is, the following code snippet still fails to parse:

if true {} #[attr] else if false {} else #[attr] if false {} #[attr]
else {}
+172 -93

0 comment

11 changed files

pr created time in 13 days

create barnchAaron1011/rust

branch : feature/permit-if-attr

created branch time in 13 days

create barnchAaron1011/rust

branch : feature/new-syntactic-if-attr

created branch time in 13 days

pull request commentrust-lang/rust

Syntactically permit attributes on 'if' expressions

@Centril: I'm going to open a new PR, since almost all of this discussion in this PR doesn't apply once we allow if-attrs semantically.

Aaron1011

comment created time in 13 days

pull request commentrust-lang/rust

Stabilize `Span::mixed_site`

If returning let (); from the macro would not be a parse error, then statement.

This might have weird interactions with let-chains, specifically PR https://github.com/rust-lang/rust/pull/68577

petrochenkov

comment created time in 13 days

issue commentrust-lang/rust

The "type_alias_impl_trait" feature has problems handling lifetime parameters.

When I wrote https://github.com/rust-lang/rust/pull/69008, I assumed that the three types of generic substs (types, lifetimes, and consts) were all handled in the same way for opaque types. However, this is not the case: the handling of lifetimes is significantly more complicated than that of types or consts.

I still think that using the 'parent' opaque type as the 'parent' generics is the best approach. However, it's going to require several changes to how we process lifetimes. In particular, we'll need to ensure that simply using a lifetime (e.g. impl FnOnce(B) -> C + 'a) does not create a corresponding generic parameter when we're outside of a return-position-impl-trait context.

steffahn

comment created time in 13 days

pull request commentrust-lang/rust

Record proc macro harness order for use during metadata deserialization

@petrochenkov: I've added an additional comment.

Aaron1011

comment created time in 13 days

push eventAaron1011/rust

Mark Rousskov

commit sha 3b92689f3d0c3b90fa01d9873cdf01543d51c000

Relax bounds on HashMap to match hashbrown No functional changes are made, and all APIs are moved to strictly less restrictive bounds. These APIs changed from the old bound listed to no trait bounds: K: Hash + Eq * new * with_capacity K: Eq + Hash, S: BuildHasher * with_hasher * with_capacity_and_hasher * hasher K: Eq + Hash + Debug -> K: Debug S: BuildHasher -> S <HashMap as Debug> K: Eq + Hash -> K S: BuildHasher + Default -> S: Default <HashMap as Default>

view details

Mark Rousskov

commit sha 48859db151b839518bdd9d44a2387c0f6b65d141

Relax bounds on HashSet to match hashbrown No functional changes are made, and all APIs are moved to strictly less restrictive bounds. These APIs changed from the old bound listed to the new bound: T: Hash + Eq -> T * new * with_capacity T: Eq + Hash, S: BuildHasher -> T * with_hasher * with_capacity_and_hasher * hasher T: Eq + Hash + Debug -> T: Debug S: BuildHasher -> S <HashSet as Debug> T: Eq + Hash -> T S: BuildHasher + Default -> S: Default <HashSet as Default>

view details

Erin Power

commit sha 49d78fcd901700c5a14e19a6679db1646b5ca901

Add GitHub issue templates

view details

Aaron Hill

commit sha 90afc0765e5e536af6307b63e1655a38df06e235

Use a `ParamEnvAnd<Predicate>` for caching in `ObligationForest` Previously, we used a plain `Predicate` to cache results (e.g. successes and failures) in ObligationForest. However, fulfillment depends on the precise `ParamEnv` used, so this is unsound in general. This commit changes the impl of `ForestObligation` for `PendingPredicateObligation` to use `ParamEnvAnd<Predicate>` instead of `Predicate` for the associated type. The associated type and method are renamed from 'predicate' to 'cache_key' to reflect the fact that type is no longer just a predicate.

view details

Tomasz Miąsko

commit sha 7e3c51d085d9eaa2204cc18763bc7d98b66435fd

Instrument C / C++ in MemorySanitizer example Modify the example to instrument C / C++ in addition to Rust, since it will be generally required (e.g., when using libbacktrace for symbolication). Additionally use rustc specific flag to track the origins of unitialized memory rather than LLVM one.

view details

Andreas Molzer

commit sha 47ae565ed4f1b2a7cc754d4cf0af520b5e6841b9

Add a method to query the capacity of a BufWriter

view details

Andreas Molzer

commit sha aebd0d733940d62566c66a923c7b9f7078209e98

Add capacity to BufReader with same unstable gate

view details

John Kåre Alsaker

commit sha bfba6ef328bbba327cae8918e795c11b89217672

Add an option to use LLD to link the compiler on Windows platforms

view details

John Kåre Alsaker

commit sha 95318f8d859dc55cc5e06722c96f6e492529d6ca

Link a linking issue

view details

John Kåre Alsaker

commit sha 2124a85260fdf0851bb4de369d311bcfc05b205f

Don't use a whitelist for use_lld

view details

Trevor Spiteri

commit sha aa046da61f8722dfe46204cb303dbc9d2b4cb32e

rustdoc: attempt full build for compile_fail test Some code fails when doing a full build but does not fail when only emitting metadata. This commit makes sure compile_fail tests for such code behave as expected, that is, the test succeeds because the compilation fails.

view details

Trevor Spiteri

commit sha 6d768ddecc13c4acf45730952c0af401a990383a

error code examples: replace some ignore with compile_fail

view details

Mark Rousskov

commit sha b613b0cb3641a7a5be74471e8e5963e52adf30ea

Correctly reinstall rustfmt on channel change

view details

Mark Rousskov

commit sha ff95473b5e8fe4a25f59778e6a071abc026e6447

Bump rustfmt and stage0

view details

Mark Rousskov

commit sha 31dcdc9e13c324d33a18db3aed7f4b3208ff3744

Drop cfg(bootstrap) code

view details

Matthew Jasper

commit sha a81c59f9b84b6519785a4e0ae9234107d149f454

Remove some unsound specializations

view details

kennytm

commit sha 847d5b4d1387a30f1798a5c3c59c3e0c31e00319

Derive Clone + PartialEq + Eq for std::string::FromUtf8Error

view details

Trevor Spiteri

commit sha fd2282388140ea0f370ee25c82f00be81c2f822c

implement AsMut<str> for String

view details

Matthew Jasper

commit sha 425e494fceb2f88bec344ef07d0f2db4c74dd2d1

Remove or_patterns from INCOMPLETE_FEATURES

view details

Matthew Jasper

commit sha eecee76652dafe25f2cd6453f33bf4c298e84463

Generate prebinding blocks lazily

view details

push time in 13 days

issue openedactix/actix

Audit remaining uses of unsafe `Pin` functions

PR https://github.com/actix/actix/pull/335 replaces several calls to unsafe Pin functions with the safe pin_project. However, there are still several remaining uses of Pin::get_unchecked_mut. Ideally, all of these calls should be replaced with uses of #[pin_project]. If this is not possible, comments should be added to explain why each call is safe (e.g. how we ensure that that the mutable reference is never moved out of).

created time in 13 days

push eventAaron1011/rust

Aaron Hill

commit sha bdb07940b56d7275743b9f707bf61bdf8d27cee4

Propagate lifetime resolution errors into tcx.type_of Fixes #69136 Previously, lifetime resolution errors would cause an error to be emitted, but would not mark the parent type as 'tainted' in any way. We usually abort compilation before this becomes an issue - however, opaque types can cause us to type-check function bodies before such an abort occurs. Ths can result in trying to instantiate opaque types that have invalid computed generics. Currently, this only causes issues for nested opaque types, but there's no reason to expect the computed generics to be sane when we had unresolved lifetimes (which can result in extra lifetime parameters getting added to the generics). This commit tracks 'unresolved lifetime' errors that occur during lifetime resolution. When we type-check an item, we bail out and return `tcx.types.err` if a lifetime error was reported for that type. This causes us to skip type-checking of types affected by the lifetime error, while still checking unrelated types. Additionally, we now check for errors in 'parent' opaque types (if such a 'parent' exists) when collecting constraints for opaque types. This reflects the fact that opaque types inherit generics from 'parent' opaque types - if an error ocurred while type-checking the parent, we don't attempt to type-check the child.

view details

push time in 13 days

push eventAaron1011/rust

Aaron Hill

commit sha 90afc0765e5e536af6307b63e1655a38df06e235

Use a `ParamEnvAnd<Predicate>` for caching in `ObligationForest` Previously, we used a plain `Predicate` to cache results (e.g. successes and failures) in ObligationForest. However, fulfillment depends on the precise `ParamEnv` used, so this is unsound in general. This commit changes the impl of `ForestObligation` for `PendingPredicateObligation` to use `ParamEnvAnd<Predicate>` instead of `Predicate` for the associated type. The associated type and method are renamed from 'predicate' to 'cache_key' to reflect the fact that type is no longer just a predicate.

view details

Daniel Henry-Mantilla

commit sha 60274a95fef57a18113f7c48be68be31ece860eb

Added From<Vec<NonZeroU8>> for CString Updated tracking issue number Added safeguards for transmute_vec potentially being factored out elsewhere Clarified comment about avoiding mem::forget Removed unneeded unstable guard Added back a stability annotation for CI Minor documentation improvements Thanks to @Centril's code review Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com> Improved layout checks, type annotations and removed unaccurate comment Removed unnecessary check on array layout Adapt the stability annotation to the new 1.41 milestone Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com> Simplify the implementation. Use `Vec::into_raw_parts` instead of a manual implementation of `Vec::transmute`. If `Vec::into_raw_parts` uses `NonNull` instead, then the code here will need to be adjusted to take it into account (issue #65816) Reduce the whitespace of safety comments

view details

Mazdak Farrokhzad

commit sha 6509db844315882db7ec0b624ca1e7b04d72568d

or_patterns: harden bindings test

view details

Mazdak Farrokhzad

commit sha 29437e55a56c1c1251ae5f7276f3e95dac4b609a

or_patterns: rename previous test

view details

Mazdak Farrokhzad

commit sha 17e632d382dfae46e9dfa684db9bddec3e8951a7

or_patterns: test default binding modes

view details

Mazdak Farrokhzad

commit sha b5aca3128d5c0ee2441ec9ca9a9c3ae4f391ef16

typeck: refactor default binding mode logic & improve docs

view details

varkor

commit sha 38060567e89bb142e8a060d91bf53f7e82eaaae6

Correct inference of primitive operand type behind binary operation

view details

varkor

commit sha 0276d7a32e1c83abc3106f7b36b711faf1f74dff

Add more tests

view details

Mazdak Farrokhzad

commit sha ebbaf4611a9605412d2aa31c8ebaf0745557fff0

simplify_try: address some of eddyb's comments

view details

Ingvar Stepanyan

commit sha 8fb8bb4b3ff25570a7a9b105c1a569bb2307f25f

Fix std::fs::copy on WASI target Previously `std::fs::copy` on wasm32-wasi would reuse code from the `sys_common` module and would successfully copy contents of the file just to fail right before closing it. This was happening because `sys_common::copy` tries to copy permissions of the file, but permissions are not a thing in WASI (at least yet) and `set_permissions` is implemented as an unconditional runtime error. This change instead adds a custom working implementation of `std::fs::copy` (like Rust already has on some other targets) that doesn't try to call `set_permissions` and is essentially a thin wrapper around `std::io::copy`. Fixes #68560.

view details

Mazdak Farrokhzad

commit sha f5bd9646be31d865a083193c21c7448d546ce07c

fix extra subslice lowering

view details

Nicholas Nethercote

commit sha dbd8220891d229f9092e623b8a1dcadbddeb12fc

Avoid `base_parser`, it's not needed.

view details

Nicholas Nethercote

commit sha 88b0912d27afa0fa2f9593c3c7545207127ff91c

Fix a typo in a variable name.

view details

Yuki Okushi

commit sha be92200af7ac732063500a96890ed0354dcc490b

Check `has_typeck_tables` before calling `typeck_tables_of`

view details

Alberto Piai

commit sha ea2ffda44e0c38854dbe63c786a194dd35559545

add regression test for issue #68794 This is a minimal regression test for the issue #68794: "TEXTREL in i686", which was fixed with e86019c4a0968a1e393cdd0731649168624a88b8. The test links a minimal rust static library into a shared library, and checks that the linker didn't have to add the TEXTREL flag.

view details

Matthew Jasper

commit sha 033bd8c7af79d362b4e861543b63991e7300948f

Explain a test

view details

Matthew Jasper

commit sha 7f41cf4cef551d887de539842d11945b6bfaa8b6

Check associated opaque types don't use unconstrained lifetimes

view details

Matthew Jasper

commit sha 4af0952961520d44088107d000b78eb3a698edba

Call `is_freeze` less in unsafety-checking This is to avoid cycles when calling `is_freeze` on an opaque type.

view details

Matthew Jasper

commit sha 60970be1fd67b19cfcdbbc53f5e87ebcbf0b61bf

Distinguish RPIT from other impl trait

view details

Matthew Jasper

commit sha 43dae91821afd70eeea46bfe0a793321b7e77526

Give some more queries descriptions

view details

push time in 13 days

issue commentrust-lang/rust

Bad quality code for `Clone` on enum types

I wonder if it would be worthwhile to try to detect and optimize this case. If a type 'could have been' Copy (it and all of its transitive fields are either #[derive(Copy)] or #[derive(Clone)] with no user-provided Clone impls), then the Clone implementation should be able to be the same as a Copy implementation.

For maximum effectiveness, this would probably have to be done during codegen, which would be quite hacky. However, it might result in some easy performance wins (less work for LLVM to do, and more efficient code generation).

reinerp

comment created time in 13 days

create barnchAaron1011/rust

branch : feature/comma-struct-init

created branch time in 13 days

PR opened rust-lang/rust

Suggest a comma if a struct initializer field fails to parse

Currently, we emit a "try adding a comma" suggestion if a comma is missing in a struct definition. However, we emit no such suggestion if a comma is missing in a struct initializer.

This commit adds a "try adding a comma" suggestion when we don't find a comma during the parsing of a struct initializer field.

The change to src/test/ui/parser/removed-syntax-with-1.stderr isn't great, but I don't see a good way of avoiding it.

+46 -3

0 comment

4 changed files

pr created time in 13 days

issue openedrust-lang/backtrace-rs

Provide a non-empty error callback to `libbacktrace`

Currently, the error callback function passed to libbacktrace does nothing:

https://github.com/rust-lang/backtrace-rs/blob/190b2f9bb1df384be686eadd1d14cb95de0d87d4/src/symbolize/libbacktrace.rs#L156-L158

Doing something here (printing an error, or just setting a flag that makes backtrace-rs calls fail) will make it much easier to debug issues like https://github.com/rust-lang/rust/issues/69151 - it took me quite a while to realize that the memory corruption I was seeing was the result of libbacktrace intentionally freeing memory.

created time in 13 days

issue openedrust-lang/backtrace-rs

Compile libbacktrace with mmapio.c instead of read.c

Currently, backtrace-sys hardcoded the compilation of src/libbacktrace/read.c: https://github.com/rust-lang/backtrace-rs/blob/190b2f9bb1df384be686eadd1d14cb95de0d87d4/crates/backtrace-sys/build.rs#L33

However, libbacktrace provides a more efficient version of read.c (which is used internally to read in chunks of memory) called mmapio.c.

backtrace-rs should either provide a feature which compiles libbacktrace with mmapio.c, or attempt to detect whether or not the mmap system call is available. Alternatively, the configure script for libbacktrace could be used instead of hard-coding paths, since [it already detects if mmap is available[(https://github.com/ianlancetaylor/libbacktrace/blob/559ab7cab4a6002124863d493bd09a376a690e76/configure.ac#L285-L303). I'm not sure if there are any issues preventing this script from being used.

This will also fix https://github.com/rust-lang/rust/issues/69151, since we will no longe be hitting the bug in read.c

created time in 13 days

PR opened rust-lang/rust

Propagate lifetime resolution errors into tcx.type_of

Fixes #69136

Previously, lifetime resolution errors would cause an error to be emitted, but would not mark the parent type as 'tainted' in any way. We usually abort compilation before this becomes an issue - however, opaque types can cause us to type-check function bodies before such an abort occurs. Ths can result in trying to instantiate opaque types that have invalid computed generics. Currently, this only causes issues for nested opaque types, but there's no reason to expect the computed generics to be sane when we had unresolved lifetimes (which can result in extra lifetime parameters getting added to the generics).

This commit tracks 'unresolved lifetime' errors that occur during lifetime resolution. When we type-check an item, we bail out and return tcx.types.err if a lifetime error was reported for that type. This causes us to skip type-checking of types affected by the lifetime error, while still checking unrelated types.

Additionally, we now check for errors in 'parent' opaque types (if such a 'parent' exists) when collecting constraints for opaque types. This reflects the fact that opaque types inherit generics from 'parent' opaque types - if an error ocurred while type-checking the parent, we don't attempt to type-check the child.

+122 -126

0 comment

9 changed files

pr created time in 13 days

create barnchAaron1011/rust

branch : feature/lifetime-error-tracking

created branch time in 13 days

startedpemistahl/grex

started time in 14 days

issue commentianlancetaylor/libbacktrace

read.c fails to handle views of more than 2,147,479,552 bytes

@ianlancetaylor: Yes - I stepped through with gdb, and verified that read.c was being used.

It looks like read.c is being explicitly selected by backtrace-rs, which is used by the Rust compiler.

Is read.rs unsupported on GNU/linux systems, or is it just that mmapio.c is more efficient?

Aaron1011

comment created time in 14 days

issue commentianlancetaylor/libbacktrace

read.c fails to handle views of more than 2,147,479,552 bytes

@ianlancetaylor: This actually occured - see https://github.com/rust-lang/rust/issues/69151.

Aaron1011

comment created time in 14 days

issue openedrust-lang/rust

rustc segfaults when printing a backtrace for ICEs when debug=true is set

When debug=true is set in config.toml, my machine generates a librustc_driver.so with a size of 2.2 GB, of which 2.1 GB is debuginfo. This ends up triggering https://github.com/ianlancetaylor/libbacktrace/issues/32. Since backtrace-rs ignores errors from libbacktrace, we continue trying to print the backtrace, which leads to a segfaut since the strtab has been freed due to the libbacktrace error.

There are a couple of ways that we can address this:

  1. Fix the libbacktrace bug - I think this should be fairly straightforward, but I haven't attempted it yet.
  2. Switch over to using backtrace-rs's gimli backend - however, I don't think it's feature-complete atm.

It would probably also be a good idea to investigate why 2.1 GB of debuginfo is getting generated - this seems really excessive.

created time in 14 days

more