profile
viewpoint

ecstatic-morse/enum-utils 6

A set of useful proc macros for enums

ecstatic-morse/ksuid 5

A small utility for dealing with Segment.io KSUIDs

ecstatic-morse/atdf 1

A parser for AVR's system description files (.atdf).

ecstatic-morse/fixed-bitset 1

A bitset whose size is fixed at compile-time

ecstatic-morse/anglistic-sched 0

A scheduler for matching students to presentation time slots by preference

ecstatic-morse/blog.rust-lang.org 0

The Rust Programming Language Blog

ecstatic-morse/cargo 0

The Rust package manager

ecstatic-morse/competitive-coding-demo 0

An example of a solution to a coding problem

ecstatic-morse/compiler-team 0

A home for compiler team planning documents, meeting minutes, and other such things.

ecstatic-morse/const-eval 0

home for proposals in and around compile-time function evaluation

pull request commentrust-lang/rust

Stabilize const_type_id feature

I can't with any confidence say what implications this has. If anyone else has the relevant knowledge and tells me it's fine, I'm fine with it.

Ah, the "type of type" explanation makes sense to me intuitively. Consider me squarely in this camp as well :smile:.

In theory we could just make TypeId::of return an abstract pointer or some new other abstract value that can't be inspected at compile-time just like pointers.

I find this idea appealing, although I have no clue how to implement it myself. I agree that just forbidding it in transmute is not sufficient.

Thanks for making a "const safety" case, even if (I think) you're not quite sure where you come down on it. I also wasn't aware of the referential transparency concerns, although once again this doesn't obviously break something. Given that no one has expressed a real need for const_type_id (I think this PR is more a point of procedure), do we want to block this on having a better story around const safety and/or type-level compile-time referential transparency?

KodrAus

comment created time in 20 hours

pull request commentrust-lang/rust

Introduce `LocalDefId` to `HirId` lookup table

I wasn't sure how to proceed there; there was a follow-up PR, #65837, but it was closed due to inactivity.

Ugh, that's a bummer.

So @nikomatsakis (who reviewed #63849) and (@eddyb who authored #65837). AFAICT with my somewhat limited understanding of the current HirId situation, this PR basically does the same thing as #63849. It replaces the current DefId -> NodeId -> HirId lookup chain with a direct mapping from DefId -> HirId to try to limit the use of NodeIds late in the compilation pipeline. As @eddyb noted in https://github.com/rust-lang/rust/pull/63849#issuecomment-537016618, this is somewhat silly, since a HirId is just a LocalDefId combined with an ItemLocalId, so we should be able to map to a HirId by using a "default" ItemLocalId (hopefully I'm not misinterpreting that too badly). #63849 was closed with the idea that @ljedrz would pursue this idea instead with mentorship from @eddyb.

@eddyb opened #65837 to get this process started, but it was never seriously reviewed, so things have sort of stalled out. I guess I see two options:

  • Merge this PR, which contains a bit of cleanup along with the change from #63849, open an issue for removing the DefId -> HirId map entirely.
  • Ask @marmeladema to split out the "cleanup" parts, merge those, and then try to get #63849 going again, leaving the DefId -> NodeId -> HirId system in place.
marmeladema

comment created time in 20 hours

pull request commentrust-lang/rust

Stabilize const_type_id feature

@oli-obk, would you be willing to expand a bit on the concerns regarding referential transparency at compile-time? As I understand it, even if someone were to use type_id to emulate dynamic dispatch within e.g. an associated constant, X would still be referentially transparent if we consider T one of the "inputs" to <T as Const>::X. Perhaps my understanding of "referential transparency" is incomplete as it pertains to Rust, and I need to consider trait bounds (or the lack thereof)?

trait Const { const X: i32 }
impl<T> Const for T {
    const X: i32 = match TypeId::of::<T>() {
        // ...
    }
}

I am mildly concerned about 2, since stabilizing type_id might close off some of the potential design space around "unconst" operations for no real reason. Is it possible that we end up with a blacklist for the input/output type of transmute at compile-time (in this case one including TypeId)? OTOH, it seems to me mem::size_of::<T>() has basically the same set of issues here, since it's not deterministic between compiler versions either. Obviously it's much less likely to change than type_of though.

KodrAus

comment created time in 21 hours

issue commentrust-lang/rust

Tracking issue for RFC 2344, "Allow `loop` in constant evaluation"

Yep! As @oli-obk said, loops present no additional problems for dataflow-based const qualification, and I can't think of any other concerns that are unique to loops.

Centril

comment created time in a day

issue commentrust-lang/rust

Clarify stages of MIR pipeline

promoted_mir doesn't do promotion (I believe that happens in mir_validated?). It steals the promoted MIR and optimizes it.

ecstatic-morse

comment created time in 2 days

pull request commentrust-lang/rust

exhaustively check `ty::Kind` during structural match checking

@bors r=pnkfelix

lcnr

comment created time in 2 days

issue commentrust-lang/compiler-team

Make `CONTRIBUTING.md` into a series of tutorials

I checked with steveklabnik, who said that CONTRIBUTING.md is now under the purview of the compiler team since the docs team is no more.

cc @rust-lang/wg-rustc-dev-guide since this will involve adapting the relevant parts of the first chapter into the "tutorial" framework.

ecstatic-morse

comment created time in 2 days

issue openedrust-lang/compiler-team

Make `CONTRIBUTING.md` into a series of tutorials

TL;DR

Rewrite CONTRIBUTING.md to contain explicit instructions (as in a series of shell commands) for a variety of common tasks for new contributors. For example, "modifying the standard library documentation", "adding a function to the standard library", "modifying rustc itself", or "modifying a submodule". Move all information that is unlikely to be needed by newer contributors (e.g., "Creating a new subtree dependency", "updating submodules") to the dev-guide or the Forge.

Links and Details

The basic idea is to make the target audience of CONTRIBUTING.md exclusively newer contributors, while documenting the details in the dev-guide. The goal here is to avoid overwhelming new people by explaining, step-by-step, how to perform specific tasks without needing a detailed understanding of the build system or bootstrapping process.

Right now, Chapter 1 of the dev-guide contains pretty much everything you need to know, but goes into great detail in some sections, meaning that people have to read through a lot of text in order to figure out how to perform a small task. I suspect that people who, for example, simply want to edit and build the documentation for std locally will not make it through the whole thing. My hope is that by moving the step-by-step instructions out of an external document and into the main repo, we can lower the barrier to entry for new contributors.

Mentors or Reviewers

???

What is this issue?

This is a major change proposal, which means a proposal to make a notable change to the compiler -- one that either alters the architecture of some component, affects a lot of people, or makes a small but noticeable public change (e.g., adding a compiler flag). You can read more about the MCP process on https://forge.rust-lang.org/.

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

MCP Checklist

  • [x] MCP filed. Automatically, as a result of filing this issue:
    • The @rust-lang/wg-prioritization group will add this to the triage meeting agenda so folks see it.
    • A Zulip topic in the stream #t-compiler/major changes will be created for this issue.
  • [ ] MCP seconded. The MCP is "seconded" when a compiler team member or contributor issues the @rustbot second command. This should only be done by someone knowledgable with the area -- before seconding, it may be a good idea to cc other stakeholders as well and get their opinion.
  • [ ] Final comment period (FCP). Once the MCP is approved, the FCP begins and lasts for 10 days. This is a time for other members to review and raise concerns -- concerns that should block acceptance should be noted as comments on the thread, ideally with a link to Zulip for further discussion.
  • [ ] MCP Accepted. At the end of the FCP, a compiler team lead will review the comments and discussion and decide whether to accept the MCP.
    • At this point, the major-change-accepted label is added and the issue is closed. You can link to it for future reference.

A note on stability. If your change is proposing a new stable feature, such as a -C flag, then a full team checkoff will be required before the feature can be landed. Often it is better to start with an unstable flag, like a -Z flag, and then move to stabilize as a secondary step.

created time in 2 days

pull request commentrust-lang/rust

Don't emit structure padding members if no padding is required.

r? @eddyb

DiamondLovesYou

comment created time in 2 days

Pull request review commentrust-lang/rust

Don't emit structure padding members if no padding is required.

 pub enum FieldsShape {         // FIXME(eddyb) build a better abstraction for permutations, if possible.         // FIXME(camlorn) also consider small vector  optimization here.         memory_index: Vec<u32>,++        /// Map source order indices to memory indices which include+        /// required implicit padding, eg due to alignment.+        /// If None, then this is the identity.+        padded_indices: Option<Vec<u32>>,

In that case, r? @eddyb. I feel strongly that Option::None should not have special semantics, but I also don't own the code.

DiamondLovesYou

comment created time in 2 days

pull request commentrust-lang/rust

Introduce `LocalDefId` to `HirId` lookup table

@marmeladema This is basically just #63849 right? @ljedrz did we come to a conclusion about the approach in https://github.com/rust-lang/rust/pull/63849#issuecomment-537016618?

marmeladema

comment created time in 2 days

pull request commentrust-lang/rust

Introduce `LocalDefId` to `HirId` lookup table

BTW, you committed an .orig file by accident. I think you need to wait for the perf run to finish before pushing again though.

marmeladema

comment created time in 2 days

pull request commentrust-lang/rust

Don't emit structure padding members if no padding is required.

Sweet! This seems to be a small win across the board, and (very slightly) faster check builds indicate that rustc itself. I'm not concerned with the deep-vector-opt regression since that benchmark does basically no codegen, although if you have a theory as to why it regressed I'm happy to hear it.

DiamondLovesYou

comment created time in 2 days

pull request commentrust-lang/rust

Introduce `LocalDefId` to `HirId` lookup table

@bors try @rust-timer queue

marmeladema

comment created time in 2 days

pull request commentrust-lang/rust

Stabilize const_type_id feature

I was unlucky and hit this bug in my code when tried to create type map.

@Y0ba Would you mind briefly documenting your experience in the comments of #10389? I think that part of the lack of urgency on that issue is that there were no reports from users of it happening organically. Perhaps changing this would help spur action?

Also, I'm sorry I was curt with you above. I want to reiterate that I do think #10389 is a serious issue, and while I don't think that alone should preclude it from becoming const, I do understand your reticence around making type_id usable in more places.

KodrAus

comment created time in 2 days

pull request commentrust-lang/rust

Do not remove closures during `ReplaceBodyWithLoop` pass

For the record, there are some important refactor work going on right now like #72284 that might help fixing this.

Sweet. I'll wait for that to land.

marmeladema

comment created time in 3 days

pull request commentrust-lang/rust

Remove ReScope

@matthewjasper This PR led to substantial perf wins on check builds for real-world crates. Nice work!

matthewjasper

comment created time in 3 days

pull request commentrust-lang/rust

Stabilize const_type_id feature

I think "Good-faith" and "bad-faith" are also terms worth defining.

KodrAus

comment created time in 3 days

pull request commentrust-lang/rust

Stabilize const_type_id feature

https://github.com/rust-lang/rust/pull/72488#issuecomment-633289306 is meant specifically as a reply to @Y0ba.

The purpose of good-faith debate is ultimately to reach the best decision possible, not to just score points against your opponent, so to bring this back on track:

Does the fact that it is possible to intentionally create a type_id collision mean we can't make this intrinsic const fn given the relatively low probability of an accidental collision I stated above?

KodrAus

comment created time in 3 days

pull request commentrust-lang/rust

Stabilize const_type_id feature

Because there will be more ways to hit it.

This is far too conservative, IMO. It's important to me that const-eval is brought to parity with runtime evaluation when possible, and no fundamental reason has been proposed that would prevent this from being const. There may be a "const-safety" argument to be made here, but I think it's incorrect.

If you care about type_id collisions, you should bring attention to #10389, not try to stop constification withot good reason.

KodrAus

comment created time in 3 days

pull request commentrust-lang/rust

Stabilize const_type_id feature

So because I failed to specify that programs that intentionally cause a type_id hash collision fall outside of "the vast majority of programs", you conclude that " your reasoning based on probabilities is meaningless"?

Debates should be held in good-faith, especially between rust-lang contributors. I don't feel you were trying to actually resolve the issue at hand here.

KodrAus

comment created time in 3 days

pull request commentrust-lang/rust

Stabilize const_type_id feature

If you wish to be pedantic:

While I totally agree that the chance of a hash-collision is a serious problem, saying it's "really dangerous" is an overstatement for the vast majority of programs: The probability of a 64-bit hash collision in a program with 100,000 types is on the order of 1 in 10 billion.

What part of this do you disagree with?

KodrAus

comment created time in 3 days

pull request commentrust-lang/rust

Stabilize const_type_id feature

It''s possible to intentionally find type_id collisions. Why should that affect const-stabilization?

KodrAus

comment created time in 3 days

pull request commentrust-lang/rust

Do not remove closures during `ReplaceBodyWithLoop` pass

@marmeladema Do you mind if I take this over?

marmeladema

comment created time in 3 days

pull request commentrust-lang/rust

Stabilize const_type_id feature

In my opinion, the fact that type_id is poorly implemented doesn't have any bearing on whether or not it can be const. All code that uses Any is using type_id under the hood, so it's not "pretty useless". While I totally agree that the chance of a hash-collision is a serious problem, saying it's "really dangerous" is an overstatement: The probability of a 64-bit hash collision in a program with 100,000 types is on the order of 1 in 10 billion.

KodrAus

comment created time in 3 days

Pull request review commentrust-lang/rust

Don't emit structure padding members if no padding is required.

 pub enum FieldsShape {         // FIXME(eddyb) build a better abstraction for permutations, if possible.         // FIXME(camlorn) also consider small vector  optimization here.         memory_index: Vec<u32>,++        /// Map source order indices to memory indices which include+        /// required implicit padding, eg due to alignment.+        /// If None, then this is the identity.+        padded_indices: Option<Vec<u32>>,

We should encode this explicitly instead of giving context-specific semantics to Option::None. With a few helper methods, I think an enum like the following would benefit readability.

enum Permutation {
    Identity,
    Mapping(Vec<u32>),
}

We could also use this for memory_index above in a follow-up PR to resolve the FIXME and save a few heap allocations.

DiamondLovesYou

comment created time in 3 days

Pull request review commentrust-lang/rust

Don't emit structure padding members if no padding is required.

 fn uncached_llvm_type<'a, 'tcx>(     } } +/// Note: this must match the expected padding from LayoutCx::padded_indices. fn struct_llfields<'a, 'tcx>(     cx: &CodegenCx<'a, 'tcx>,     layout: TyAndLayout<'tcx>, ) -> (Vec<&'a Type>, bool) {     debug!("struct_llfields: {:#?}", layout);-    let field_count = layout.fields.count();+    let field_count = match layout.fields {+        FieldsShape::Arbitrary { padded_indices: None, ref offsets, .. } => offsets.len(),+        FieldsShape::Arbitrary { padded_indices: Some(ref indices), .. } => {+            indices.iter().cloned().max().unwrap_or_default() as usize+        }+        _ => bug!(),

While it's kind of obvious from the function name, can you add a descriptive message here?

DiamondLovesYou

comment created time in 3 days

issue openedrust-lang/rust

Clarify stages of MIR pipeline

The rustc_mir::transform module defines the pipeline of analysis passes and transformations that run on the MIR after is lowered but before it is passed to codegen. However, it's not always clear whether certain invariants apply to each stage of the pipeline. For example, some terminators (FalseEdges, DropAndReplace) are removed entirely at each stage of the pipeline and the Return terminator, which initially appears only once in the entire MIR body may appear multiple times after the generator transform.

Additionally, it can be hard to find the right place for new error-emitting passes like the lint in #72270 or #71824. Is there a point at which the MIR is no longer meant for analysis but only for codegen? Finally, the names of the mir_* queries have lost their meaning over time: mir_const can probably be removed entirely, and optimized_mir and promoted_mir should probably be renamed to mir_optimized and mir_promoted_fragments_optimized respectively.

created time in 4 days

issue commentrust-lang/rust

`asm!` error: invalid instruction mnemonic 'divq'

asm! uses Intel syntax, not AT&T. I believe you just need to lose the "q".

AaronKutch

comment created time in 4 days

push eventecstatic-morse/rust

Dylan MacKenzie

commit sha 9dadeb34dfd27a86051d8d7f4a5ffd4ee88d9775

Test `is_nan`

view details

push time in 4 days

push eventecstatic-morse/rust

Dylan MacKenzie

commit sha 8de4f0667b6be2a5cb52f3c73674ea5a957c0f44

Test `is_nan`

view details

push time in 4 days

pull request commentrust-lang/rust

Make `PolyTraitPredicate::self_ty` return `Binder<Ty>`

r? @nikomatsakis

ecstatic-morse

comment created time in 4 days

PR opened rust-lang/rust

Make `PolyTraitPredicate::self_ty` return `Binder<Ty>`

This came up during review of #71618. The current implementation is the same as a call to skip_binder but harder to audit. Make it preserve binding levels and add a call to skip_binder at all use sites so they can be audited as part of #72507.

+41 -24

0 comment

7 changed files

pr created time in 4 days

issue openedrust-lang/rust

Audit uses of `skip_binder` in diagnostics code

As discussed in #71618, skip_binder is called very often in diagnostics code. This is often incorrect for types with late-bound regions, e.g. function pointers. We should audit uses of skip_binder and replace them with no_bound_vars + early return or unwrap. If there are uses of skip_binder that are benign, for example debug printing or comparing with a known type, we should abstract this behind a function to minimize the number of calls to skip_binder that need to be checked.

created time in 4 days

create barnchecstatic-morse/rust

branch : poly-self-ty

created branch time in 4 days

push eventecstatic-morse/rust

Ralf Jung

commit sha 33541d5e55c3114e01e06b27715ae04372ce027f

clarify interaction of pin drop guarantee and panics

view details

Kevin Per

commit sha dfbc143e65dd4dc8499f7296ddc7889854a8cc7d

Adding if to prevent borrowing suggestion in structs #71136

view details

Kevin Per

commit sha bc29f1d062feeb68207c961d254652d6bff9fd9b

Adding new test #71136

view details

Kevin Per

commit sha d232be80f82b052fd023eb2f4904ccad0aa42d7a

Fix tidy checks

view details

bdbai

commit sha 5bfb7e7437dac924825be123f7c9645b4e4367e5

Add target thumbv7a-uwp-windows-msvc

view details

Jeremy Fitzhardinge

commit sha ff9646c0adc149dfff194665785f4daa3aa6d9c3

Stabilize process_set_argv0 feature for Unix This stabilizes process_set_argv0 targeting 1.45.0. It has been useful in practice and seems useful as-is. The equivalent feature could be implemented for Windows, but as far as I know nobody has. That can be done separately. Tracking issue: #66510

view details

Esteban Küber

commit sha a3f30bbc2d28572f9fa429cf3b31d7f95d3b0dda

Don't `type_of` on trait assoc ty without default Fix #72076.

view details

Gary Guo

commit sha a23dd0d1e6ddfe6624f1c59e9aefcb59e419610d

Replace fcntl-based file lock with flock WSL1 does not support `fcntl`-based lock and will always report success, therefore creating a race condition when multiple rustc processes are modifying shared data such as `search-index.js`. WSL1 does however support `flock`. `flock` is supported by all unix-like platforms. The only caveat is that Linux 2.6.11 or earlier does not support `flock` on NFS mounts, but as the minimum supported Linux version is 2.6.18, it is not an issue. Fixes #72157

view details

Tshepang Lekhonkhobe

commit sha b96a1a759528f3d43c54b4a18094ff6331d0d5fc

remove broken link

view details

David Cook

commit sha 0148a7f26ce636ac22ac7797dcd7d292c59e8576

InvalidUninitBytes: Track more info about access

view details

Nadrieril

commit sha e65d49d33860befebb3c5b2a13907983d57929a3

Fix incorrect ordering I introduced this mistake in 175976e2a2b03c3f347d4eff28661445c3c58372 and I can't quite remember what the reasoning was back then. I think I modeled it on `apply_constructor`, not realizing there was an important difference in the order in which fields were stored.

view details

Nadrieril

commit sha 4a1772ea92ce7949beade6c9d2f110e64de30aa0

Factor the code that generates TyErrs

view details

Nadrieril

commit sha a5294b6486ea4930e0d16518851dffa51917a8e5

We already handle arrays of unknown length correctly

view details

Nadrieril

commit sha 160eebec21387c13e4966f5744b998e75e647fb8

Only need TyErr for uninhabited types

view details

Nadrieril

commit sha 76dea86df44c172ba315f2938693f4ca1bd03b7c

Factor out a struct that holds subfields of a pattern

view details

Nadrieril

commit sha 3551f1a0f6301e315a8ee5ea39420fa6f26d0a90

Use Fields as output to specialize_one_pattern

view details

Nadrieril

commit sha c3d3727046a542e23cd105984c735a2ab5a4f610

Clarify specialize_one_pattern Using a more error-oriented approache to `Option`.

view details

Nadrieril

commit sha 70b3872a128b6e73b94345355008f56faa2bef74

Make all field-handling go through Fields

view details

Nadrieril

commit sha 59fa40a5a03e882427cb6bf527846c44afd80172

Filter out fields that should not be seen This was previously done by giving those fields the type tyerr. This was a hack.

view details

Nadrieril

commit sha 8f08b16c030d89049e0633ced8665c317db83f03

Small allocation improvement

view details

push time in 4 days

issue openedrust-lang/rust

Tracking issue for `#![feature(const_float_classify)]`

Tracking issue for the #![feature(const_float_classify)] feature gate, which makes the following methods on f32 and f64 const fn:

  • classify
  • is_nan
  • is_infinite
  • is_finite
  • is_normal
  • is_sign_positive
  • is_positive (deprecated)
  • is_sign_negative
  • is_negative (deprecated)

These require #![feature(const_float_bits_conv)].

created time in 4 days

pull request commentrust-lang/rust

Const floating point bitcasts

Would it make sense to also add abs_private and is_finite to the batch of functions that are being constified here?

Sure.

ecstatic-morse

comment created time in 4 days

pull request commentrust-lang/rust

Stabilize const_type_id feature

I don't see any hazards from this. The result of type_id is allowed to change across compiler versions, but I think that is acceptable for const fn.

cc @rust-lang/wg-const-eval

KodrAus

comment created time in 4 days

Pull request review commentrust-lang/rust

Stabilize const_type_id feature

-use std::any::TypeId;--struct A;--fn main() {-    const A_ID: TypeId = TypeId::of::<A>();-    //~^ ERROR `std::any::TypeId::of` is not yet stable as a const fn-}

Please make this "run-pass" and check that it works.

KodrAus

comment created time in 4 days

pull request commentrust-lang/rust

Intern predicates

The rollup containing this PR caused a large perf regression in trait solving. Was this expected?

lcnr

comment created time in 4 days

pull request commentrust-lang/rust

Rollup of 7 pull requests

This PR caused a rather large perf regression. Looking at the per-query results, the slowdown is in trait solving, so it is most likely #72055.

There's one other candidate PR, #71718, whose perf run is not yet complete, but it is unlikely to have caused the regression.

RalfJung

comment created time in 4 days

pull request commentrust-lang/rust

Preserve substitutions when making trait obligations for suggestions

@bors rollup

ecstatic-morse

comment created time in 4 days

pull request commentrust-lang/rust

Perform MIR NRVO even if types don't match

This has no effect. Perhaps we should just close this along with #72428?

ecstatic-morse

comment created time in 5 days

issue commentrust-lang/rust

ICE in _match.rs:1184:21 when building "gfx-backend-metal" on Nightly

cc @Nadrieril

kvark

comment created time in 5 days

pull request commentrust-lang/rust

Use `once_cell` crate instead of custom data structure

@bors r- @bors r=Mark-Simulacrum

ecstatic-morse

comment created time in 5 days

pull request commentrust-lang/rust

Check for live drops in constants after drop elaboration

MIR passes are currently divided into "post-borrowck cleanup" and "optimization passes". This runs immediately after "post-borrowck cleanup".

ecstatic-morse

comment created time in 5 days

pull request commentrust-lang/rust

Use `once_cell` crate instead of custom data structure

@bors r+

ecstatic-morse

comment created time in 5 days

push eventecstatic-morse/rust

Josh Stone

commit sha b0fb57bd8d18946787a79d1244154f2512dcf15b

impl From<Cow> for boxed slices and strings These forward `Borrowed`/`Owned` values to existing `Box::from` impls. - `From<Cow<'_, [T]>> for Box<[T]>` - `From<Cow<'_, str>> for Box<str>` - `From<Cow<'_, CStr>> for Box<CStr>` - `From<Cow<'_, OsStr>> for Box<OsStr>` - `From<Cow<'_, Path>> for Box<Path>`

view details

Josh Stone

commit sha 6d40751b37ef453bee5d8a9c47b00ef205d61738

impl From<Cow> for Rc and Arc These forward `Borrowed`/`Owned` values to existing `From` impls. impl<'a, B> From<Cow<'a, B>> for Rc<B> where B: ToOwned + ?Sized, Rc<B>: From<&'a B> + From<B::Owned>, impl<'a, B> From<Cow<'a, B>> for Arc<B> where B: ToOwned + ?Sized, Arc<B>: From<&'a B> + From<B::Owned>,

view details

Josh Stone

commit sha 23f71fe5b518c6136990f79733155b4fa1314d2b

Add tests from Cow

view details

Josh Stone

commit sha 22efd959109b9a231edbc81a8bc818eaa5763e78

Bless From<Cow> UI changes

view details

Ralf Jung

commit sha 33541d5e55c3114e01e06b27715ae04372ce027f

clarify interaction of pin drop guarantee and panics

view details

Kevin Per

commit sha dfbc143e65dd4dc8499f7296ddc7889854a8cc7d

Adding if to prevent borrowing suggestion in structs #71136

view details

Kevin Per

commit sha bc29f1d062feeb68207c961d254652d6bff9fd9b

Adding new test #71136

view details

Kevin Per

commit sha d232be80f82b052fd023eb2f4904ccad0aa42d7a

Fix tidy checks

view details

Eduardo Sánchez Muñoz

commit sha 68f89fcbf982d4b2a40d3175568bef194ee4f3b7

Make `std::char` functions and constants associated to `char`.

view details

Vadim Petrochenkov

commit sha 5c6f7b32aab683276d4feb1810244ccf72bda736

Stabilize fn-like proc macros in expression, pattern and statement positions

view details

Dylan MacKenzie

commit sha 41fe5c1ca73589fe9f63f2191fd0c869e5de34d0

Update clippy lint

view details

Eduardo Sánchez Muñoz

commit sha 0e12a9d9ac6f69ddd72f2c028f668c0b55ac2eda

Try to fix doc links in new `char` methods.

view details

csmoe

commit sha e07f63e79a618a0c5e53a71d053da0fa0dbc6970

add testcase for issue-70818

view details

Tobias Rapp

commit sha f99344ace44abc91f76df276625e048f1e8a9536

Stabilize saturating_abs and saturating_neg Stabilizes the following signed integer functions with saturation mechanics: * saturating_abs() * saturating_neg() Closes #59983

view details

csmoe

commit sha fb81c429ebd45f9ba2b1810f548cf59a45feb222

make yield span optional

view details

csmoe

commit sha a5d103ff90f4ad90b1f13f5b5de83a3eb758d9e2

record upvar into GeneratorInteriorTypeCause

view details

csmoe

commit sha d4bdcfd3cfbfa025c5363149a14f2b36a584b54a

don't record upvars into generator interior

view details

csmoe

commit sha 382a963c17122470918e1491a733b81fb545330d

filter upvars that cause trait obligation

view details

csmoe

commit sha d2e5a8e2e966df119021e3db6f6d4c2e189865cd

bless issue-70818 test case

view details

Jack Huey

commit sha 0e2f5c9862bff6889c57a802844e75ea9e576606

Fix nit and cargo.lock

view details

push time in 5 days

pull request commentrust-lang/rust

Preserve substitutions when making trait obligations for suggestions

Rebased to fix merge conflict. Can I r+ this? The original intent was to fix a rather embarrassing diagnostics bug. I will open an issue for removing self_ty and replacing it with no_bound_vars, as well as one for auditing uses of skip_binder in the diagnostics code more generally.

ecstatic-morse

comment created time in 5 days

push eventecstatic-morse/rust

Dylan MacKenzie

commit sha c282c1c654901bd523774dd7ce2e8d4272d24911

Use `OnceCell` instead of `Once`

view details

Dylan MacKenzie

commit sha f17e2c93a69443c93aa42e0df0a119d35c4d49d9

Use `OnceCell` for predecessor cache

view details

Dylan MacKenzie

commit sha 307153e611433f9224224a4511b6ea4f362ffe28

Switch to non-doc comment

view details

push time in 5 days

push eventecstatic-morse/rust

Josh Stone

commit sha b0fb57bd8d18946787a79d1244154f2512dcf15b

impl From<Cow> for boxed slices and strings These forward `Borrowed`/`Owned` values to existing `Box::from` impls. - `From<Cow<'_, [T]>> for Box<[T]>` - `From<Cow<'_, str>> for Box<str>` - `From<Cow<'_, CStr>> for Box<CStr>` - `From<Cow<'_, OsStr>> for Box<OsStr>` - `From<Cow<'_, Path>> for Box<Path>`

view details

Josh Stone

commit sha 6d40751b37ef453bee5d8a9c47b00ef205d61738

impl From<Cow> for Rc and Arc These forward `Borrowed`/`Owned` values to existing `From` impls. impl<'a, B> From<Cow<'a, B>> for Rc<B> where B: ToOwned + ?Sized, Rc<B>: From<&'a B> + From<B::Owned>, impl<'a, B> From<Cow<'a, B>> for Arc<B> where B: ToOwned + ?Sized, Arc<B>: From<&'a B> + From<B::Owned>,

view details

Josh Stone

commit sha 23f71fe5b518c6136990f79733155b4fa1314d2b

Add tests from Cow

view details

Josh Stone

commit sha 22efd959109b9a231edbc81a8bc818eaa5763e78

Bless From<Cow> UI changes

view details

Ralf Jung

commit sha 33541d5e55c3114e01e06b27715ae04372ce027f

clarify interaction of pin drop guarantee and panics

view details

Kevin Per

commit sha dfbc143e65dd4dc8499f7296ddc7889854a8cc7d

Adding if to prevent borrowing suggestion in structs #71136

view details

Kevin Per

commit sha bc29f1d062feeb68207c961d254652d6bff9fd9b

Adding new test #71136

view details

Kevin Per

commit sha d232be80f82b052fd023eb2f4904ccad0aa42d7a

Fix tidy checks

view details

Eduardo Sánchez Muñoz

commit sha 68f89fcbf982d4b2a40d3175568bef194ee4f3b7

Make `std::char` functions and constants associated to `char`.

view details

Vadim Petrochenkov

commit sha 5c6f7b32aab683276d4feb1810244ccf72bda736

Stabilize fn-like proc macros in expression, pattern and statement positions

view details

Dylan MacKenzie

commit sha 41fe5c1ca73589fe9f63f2191fd0c869e5de34d0

Update clippy lint

view details

Eduardo Sánchez Muñoz

commit sha 0e12a9d9ac6f69ddd72f2c028f668c0b55ac2eda

Try to fix doc links in new `char` methods.

view details

csmoe

commit sha e07f63e79a618a0c5e53a71d053da0fa0dbc6970

add testcase for issue-70818

view details

Tobias Rapp

commit sha f99344ace44abc91f76df276625e048f1e8a9536

Stabilize saturating_abs and saturating_neg Stabilizes the following signed integer functions with saturation mechanics: * saturating_abs() * saturating_neg() Closes #59983

view details

csmoe

commit sha fb81c429ebd45f9ba2b1810f548cf59a45feb222

make yield span optional

view details

csmoe

commit sha a5d103ff90f4ad90b1f13f5b5de83a3eb758d9e2

record upvar into GeneratorInteriorTypeCause

view details

csmoe

commit sha d4bdcfd3cfbfa025c5363149a14f2b36a584b54a

don't record upvars into generator interior

view details

csmoe

commit sha 382a963c17122470918e1491a733b81fb545330d

filter upvars that cause trait obligation

view details

csmoe

commit sha d2e5a8e2e966df119021e3db6f6d4c2e189865cd

bless issue-70818 test case

view details

Jack Huey

commit sha 0e2f5c9862bff6889c57a802844e75ea9e576606

Fix nit and cargo.lock

view details

push time in 5 days

pull request commentrust-lang/rust

Perform MIR NRVO even if types don't match

Single pointers get returned via register, so I think there's almost no chance this was actually responsible for the perf changes described in #72428. Just in case:

@bors try @rust-timer queue

ecstatic-morse

comment created time in 5 days

PR opened rust-lang/rust

Perform MIR NRVO even if types don't match

This is the most straightforward way to resolve #72428, but it could cause problems in codegen since the type of _0 may no longer match the return type of the body.

+6 -12

0 comment

1 changed file

pr created time in 5 days

push eventecstatic-morse/rust

Dylan MacKenzie

commit sha d24ba6d1243db648eac365eaf637264e6d04d5f1

Perform MIR NRVO even if types don't match

view details

push time in 5 days

create barnchecstatic-morse/rust

branch : nrvo-type-mismatch

created branch time in 5 days

push eventecstatic-morse/rust

Dylan MacKenzie

commit sha c3bb670380749945179326669ca2afc015d9e49f

Test new floating point bit casts

view details

push time in 5 days

PR opened rust-lang/rust

Const floating point bitcasts

Makes the f32 and f64 methods described in #72447 unstably const.

r? @RalfJung

+109 -16

0 comment

4 changed files

pr created time in 5 days

create barnchecstatic-morse/rust

branch : const-float-bitcast

created branch time in 5 days

issue openedrust-lang/rust

Tracking issue for `#![feature(const_float_bits_conv)]`

Makes the following functions unstably const behind the #![feature(const_float_bits_conv)] feature gate:

  • {f32,f64}::{to_bits, from_bits} (formerly #![feature(float_bits_conv)])
  • {f32,f64}::{to_bytes_{be,le,ne},from_bytes_{be,le,ne}} (formerly #![feature(float_to_from_bytes)])

These require transmute within a const fn to stabilize, and–unlike the recently stabilized #![feature(const_int_conversion)]–do not have a const-stable alternate implementation. Nevertheless, these may be useful for nightly users.

created time in 5 days

pull request commentrust-lang/rust

Update to LLVM 10

Personally, I would be happy to spend 10% longer compiling at -C opt-level=3 if there were an improvement in runtime performance, since you can always set a lower optimization level. However, non-codegened full builds seem to be the same or even slower for real-world crates, which means rustc isn't benefiting from whatever additional optimizations LLVM is doing.

nikic

comment created time in 5 days

pull request commentrust-lang/rust

Check for live drops in constants after drop elaboration

If I were to implement this on without relying on drop elaboration, I would need only the MaybeInitializedPlaces analysis. I don't think this would be too hard for me, although it would be more work than the current approach. The borrow checker uses several others: MaybeUninitializedPlaces to detect reads from places that are moved from or never assigned and EverInitializedPlaces to detect mutation of immutable variables, but I think you are correct that it is doing something very similar to drop elaboration.

I suppose this aspect of const-checking just seems more tied to drop elaboration than the borrow checking does. The first two are doing very similar things, whereas drop elaboration is sort of a small subset of what the borrow checker is doing. This is why it felt so natural to tie the two together.

In your opinion, how likely is the potential backwards compatibility hazard of relying on drop elaboration to materialize? My thinking is that both const-checking and drop elaboration will rely on the same dataflow analysis anyways, and it's highly unlikely that we will make drop elaboration less precise while MaybeInitializedPlaces remains unchanged.

ecstatic-morse

comment created time in 5 days

issue commentrust-lang/rust

Do NRVO when type of returned local does not match return type

Worth noting that an initial perf run of #72205 was a bit slower than for the one that was merged. This issue is one plausible explanation, although there was also an LLVM upgrade in between.

ecstatic-morse

comment created time in 6 days

pull request commentrust-lang/rust

Stabilize `#![feature(const_if_match)]`

While writing this, I found and fixed a bug in the HIR const-checker where it wasn't requiring allow_internal_unstable for rustc_const_stable functions, just the feature gates. I will probably split this out as part of an upcoming refactoring of the fn_queries module.

ecstatic-morse

comment created time in 6 days

PR opened rust-lang/rust

Stabilize `#![feature(const_if_match)]`

Resolves #49146.

FCP has elapsed, so the next step is to stabilize const_if_match with the semantics described in https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045.

Ideally, we would resolve #66753 before this lands on stable, so it might be worth pushing this back a release. Also, this means we should get the process started for #52000, otherwise people will have no recourse except recursion for iterative const fn.

r? @oli-obk

+311 -1296

0 comment

97 changed files

pr created time in 6 days

push eventecstatic-morse/rust

Dylan MacKenzie

commit sha 9e2cf37f08311c1174d2cd5a40820bd63b28f567

Update tests

view details

Dylan MacKenzie

commit sha f63e14eac09826dcfe51f0367d7fff2ec5cf04a5

Remove `const_if_match` from unstable book

view details

Dylan MacKenzie

commit sha 6fbec683161159a1718e545861aa26ee5571101a

Require `allow_internal_unstable` in HIR const-checker

view details

push time in 6 days

create barnchecstatic-morse/rust

branch : stabilize-const-if-match

created branch time in 6 days

pull request commentrust-lang/rust

Use `once_cell` crate instead of custom data structure

@bors r=Mark-Simulacrum

ecstatic-morse

comment created time in 6 days

push eventecstatic-morse/rust

Dylan MacKenzie

commit sha b8adbb71bb7f25c86b8453a37838f31182fc176a

Remove unnecessary call to `OnceCell::get` Co-authored-by: matklad <aleksey.kladov@gmail.com>

view details

push time in 6 days

issue commentrust-lang/rust

rustc --run option

Sure, but it's important to document alternatives for people that stumble on this issue. You're free to use /tmp/a.out as well.

muv1

comment created time in 6 days

issue commentrust-lang/rust

No definition of lexicographic order in docs for `Iterator::cmp*`

To resolve this, you can either write a definition of lexicographical order somewhere in the rust documentation or link to an easily understandable source. Then link to that definition wherever "lexicographical" appears in the source.

brmmm3

comment created time in 6 days

issue commentrust-lang/rust

rustc --run option

I would recommend something like the following instead of cargo script, but I think a convenient shorthand might be nice.

rustc -o a.out test.rs && ./a.out
muv1

comment created time in 6 days

delete branch ecstatic-morse/rust

delete branch : nrvo

delete time in 6 days

issue openedrust-lang/rust

Do NRVO when type of returned local does not match return type

#72205 will fail to fire for code such as the following:

fn foo(x: &mut i32) -> &i32 { x }

This is because, by the time we get to the RenameReturnPlace pass, the reborrow has been optimized away and we have MIR like:

_0: &i32 = _1: &mut i32

To merge these locals, we need to pick a type for the unified LocalDecl. However, I wasn't sure how or if codegen makes use of the types of locals, so for now #72205 just doesn't run if the locals have different type. We should come up with a solution here.

created time in 6 days

issue openedrust-lang/rust

Remove `Session::crate_types_opt`?

See https://github.com/rust-lang/rust/pull/72256#discussion_r428775106 for context.

There's only one place in the compiler that can't call Session::crate_types because that field is sometimes uninitialized.

https://github.com/rust-lang/rust/blob/31add7e60709445617ab54a69f6f21cfcb2e3122/src/librustc_codegen_llvm/context.rs#L100-L103

Perhaps this indicates that we want to force initialization of crate_types somewhere?

created time in 6 days

pull request commentrust-lang/rust

Remove all uses of `NodeId` in `ResolverOutputs`

Thanks @marmeladema! It's possible that someone with more knowledge of AST -> HIR lowering (@petrochenkov?) could find a solution to https://github.com/rust-lang/rust/pull/72402#discussion_r428368228. However, because this may unlock https://github.com/rust-lang/rust/issues/50928#issuecomment-631594659, I'm happy to approve in its present state.

@bors r+

marmeladema

comment created time in 6 days

Pull request review commentrust-lang/rust

Use `once_cell` crate instead of custom data structure

 impl Session {     }      pub fn local_crate_disambiguator(&self) -> CrateDisambiguator {-        *self.crate_disambiguator.get()+        self.crate_disambiguator.get().copied().unwrap()+    }++    #[inline]+    pub fn crate_types(&self) -> &[CrateType] {+        self.crate_types_opt().unwrap()+    }++    #[inline]+    pub fn crate_types_opt(&self) -> Option<&[CrateType]> {

Will do.

ecstatic-morse

comment created time in 6 days

Pull request review commentrust-lang/rust

Preserve substitutions when making trait obligations for suggestions

 impl<'a, 'tcx> InferCtxtExt<'tcx> for InferCtxt<'a, 'tcx> {                     return;                 } -                let trait_type = match mutability {+                let suggested_ty = match mutability {                     hir::Mutability::Mut => self.tcx.mk_imm_ref(region, t_type),                     hir::Mutability::Not => self.tcx.mk_mut_ref(region, t_type),                 }; -                let new_obligation = self.mk_obligation_for_def_id(-                    trait_ref.skip_binder().def_id,-                    trait_type,-                    ObligationCause::dummy(),+                let new_obligation = self.mk_trait_obligation_with_new_self_ty(                     obligation.param_env,+                    &trait_ref,+                    suggested_ty,

It seems like we want to change PolyTraitRef::self_ty to return a Binder<Ty>. Is this correct? This will have a significant amount of fallout I think. Do you want me to open an issue to track this? I could check the result of self_ty for no_bound_vars in this PR, but we need to be doing this across all diagnostics code, not just here.

ecstatic-morse

comment created time in 6 days

Pull request review commentrust-lang/rust

Use `once_cell` crate instead of custom data structure

 impl Session {     }      pub fn local_crate_disambiguator(&self) -> CrateDisambiguator {-        *self.crate_disambiguator.get()+        self.crate_disambiguator.get().copied().unwrap()+    }++    #[inline]+    pub fn crate_types(&self) -> &[CrateType] {+        self.crate_types_opt().unwrap()+    }++    #[inline]+    pub fn crate_types_opt(&self) -> Option<&[CrateType]> {

Sorry. I see I forgot to respond to this. I did initially try unwrapping crate_types here, but it wasn't populated at this point.

ecstatic-morse

comment created time in 6 days

Pull request review commentrust-lang/rust

Remove all uses of `NodeId` in `ResolverOutputs`

 impl<'a> Resolver<'a> {         ResolverOutputs {             definitions: self.definitions.clone(),             cstore: Box::new(self.cstore().clone()),-            extern_crate_map: self.extern_crate_map.clone(),-            export_map: self.export_map.clone(),-            trait_map: self.trait_map.clone(),-            glob_map: self.glob_map.clone(),-            maybe_unused_trait_imports: self.maybe_unused_trait_imports.clone(),-            maybe_unused_extern_crates: self.maybe_unused_extern_crates.clone(),+            extern_crate_map: self+                .extern_crate_map+                .iter()+                .map(|(k, v)| (self.definitions.local_def_id(k.clone()).to_def_id(), v.clone()))

Ah that's right. In that case use the argument binding approach (|(&k, &v)|) for the Copy types. Cloning the entire map will cause the backing storage to be unnecessarily cloned as well.

marmeladema

comment created time in 6 days

Pull request review commentrust-lang/rust

Remove all uses of `NodeId` in `ResolverOutputs`

 mod sty; pub struct ResolverOutputs {     pub definitions: rustc_hir::definitions::Definitions,     pub cstore: Box<CrateStoreDyn>,-    pub extern_crate_map: NodeMap<CrateNum>,-    pub trait_map: TraitMap<NodeId>,-    pub maybe_unused_trait_imports: NodeSet,-    pub maybe_unused_extern_crates: Vec<(NodeId, Span)>,-    pub export_map: ExportMap<NodeId>,-    pub glob_map: GlobMap,+    pub extern_crate_map: FxHashMap<DefId, CrateNum>,+    pub trait_map: FxHashMap<hir::HirId, Vec<hir::TraitCandidate<hir::HirId>>>,+    pub maybe_unused_trait_imports: FxHashSet<LocalDefId>,+    pub maybe_unused_extern_crates: Vec<(DefId, Span)>,+    pub export_map: ExportMap<hir::HirId>,+    pub glob_map: FxHashMap<LocalDefId, FxHashSet<Symbol>>,

@petrochenkov I see you've assigned yourself. Any recommendations here? Is there a reason that trait_map and export_map cannot use DefIds?

marmeladema

comment created time in 6 days

Pull request review commentrust-lang/rust

Remove all uses of `NodeId` in `ResolverOutputs`

 impl<'a> Resolver<'a> {         ResolverOutputs {             definitions: self.definitions.clone(),             cstore: Box::new(self.cstore().clone()),-            extern_crate_map: self.extern_crate_map.clone(),-            export_map: self.export_map.clone(),-            trait_map: self.trait_map.clone(),-            glob_map: self.glob_map.clone(),-            maybe_unused_trait_imports: self.maybe_unused_trait_imports.clone(),-            maybe_unused_extern_crates: self.maybe_unused_extern_crates.clone(),+            extern_crate_map: self+                .extern_crate_map+                .iter()+                .map(|(k, v)| (self.definitions.local_def_id(k.clone()).to_def_id(), v.clone()))

I don't care so much about cloned vs clone, but there do seem to be some calls to clone for Copy types, which clippy will lint against. Only using clone when necessary makes it easier to spot places that do excessive heap allocation. Using |(&k, &v)| here, or preferably Iterator::copied would be preferable.

marmeladema

comment created time in 6 days

pull request commentrust-lang/rust

Dumb NRVO

Hmm. Apparently I didn't get to rustc_ast_lowering when testing whether a stage 1. It seems the return place is sometimes assigned a local with a different type. In this case, &T vs &mut T. I've updated the code to bail out instead of panicking when this occurs. I'm going to tentatively reapprove this, but we should figure out what to do here long-term.

@bors r=oli-obk

ecstatic-morse

comment created time in 6 days

push eventecstatic-morse/rust

Dylan MacKenzie

commit sha f50986205756075fb05a9371b94facd58cc048a6

Bail out if new return place has different type than old

view details

push time in 6 days

push eventecstatic-morse/rust

Dylan MacKenzie

commit sha 3bf9663a4121c7076c4edfdccc7efd6249690cd3

Return place type can differ from local assigned to it

view details

push time in 6 days

Pull request review commentrust-lang/rust

Remove all uses of `NodeId` in `ResolverOutputs`

 mod sty; pub struct ResolverOutputs {     pub definitions: rustc_hir::definitions::Definitions,     pub cstore: Box<CrateStoreDyn>,-    pub extern_crate_map: NodeMap<CrateNum>,-    pub trait_map: TraitMap<NodeId>,-    pub maybe_unused_trait_imports: NodeSet,-    pub maybe_unused_extern_crates: Vec<(NodeId, Span)>,-    pub export_map: ExportMap<NodeId>,-    pub glob_map: GlobMap,+    pub extern_crate_map: FxHashMap<DefId, CrateNum>,+    pub trait_map: FxHashMap<hir::HirId, Vec<hir::TraitCandidate<hir::HirId>>>,+    pub maybe_unused_trait_imports: FxHashSet<LocalDefId>,+    pub maybe_unused_extern_crates: Vec<(DefId, Span)>,+    pub export_map: ExportMap<hir::HirId>,+    pub glob_map: FxHashMap<LocalDefId, FxHashSet<Symbol>>,

It does seem like all of these could plausibly be DefId. Did you find something during your experiments that wasn't a definition? If not, we should open a cleanup issue once this gets merged.

marmeladema

comment created time in 6 days

Pull request review commentrust-lang/rust

Remove all uses of `NodeId` in `ResolverOutputs`

 impl<'a> Resolver<'a> {     }      pub fn into_outputs(self) -> ResolverOutputs {+        let definitions = self.definitions;+        let extern_crate_map = {

HashMap implements FromIterator. Why not use collect for all these like the old code does?

marmeladema

comment created time in 6 days

PR opened rust-lang/rust

Use correct function for detecting `const fn` in unsafety checking

Resolves #72394.

+26 -2

0 comment

3 changed files

pr created time in 7 days

create barnchecstatic-morse/rust

branch : issue-72394

created branch time in 7 days

issue commentrust-lang/rust

Unsafety checks for "unconst" operations do not fire trigger in unstable functions

Oh, the names are different than in the email I got because you edited.

Damn. I was hoping no one would catch me :smile:.

is_const_callable_fn would indeed take feature flags into account. My original name was is_stably_const_fn, but that's not really true, since it would also return true if the function was unstable but the correct feature flags were set.

ecstatic-morse

comment created time in 7 days

issue openedrust-lang/rust

Unsafety checks for "unconst" operations do not fire for unstable functions

Some operations, such as raw pointer comparisons, require unsafe when inside a const context. To my knowledge, none of these operations have been const-stabilized. Accordingly, the following example fails to compile due to a missing unsafe block.

#![feature(const_compare_raw_pointers)]
#![feature(const_fn)]

const fn unstable(a: *const i32, b: *const i32) -> bool {
    a == b
}

However, the check does not run for const_unstable functions. The following compiles successfully:

#![stable(feature = "foo", since = "1.33.0")]
#![feature(staged_api)]
#![feature(const_compare_raw_pointers)]
#![feature(const_fn)]

#[stable(feature = "foo", since = "1.33.0")]
#[rustc_const_unstable(feature = "const_foo", issue = "none")]
const fn unstable(a: *const i32, b: *const i32) -> bool {
    a == b
}

This is an easy problem to fix, but the root cause here is poor naming. Specifically, fn_queries::is_const_fn should be renamed fn_queries::is_stably_const_fn and is_const_fn_raw should be is_declared_const_fn. We have had other issues due to this in the past. cc @rust-lang/wg-const-eval to weigh in on the renaming.

created time in 7 days

issue commentrust-lang/rust

`unsafe` blocks do not apply to array length expressions they contain

The ticket is valid, but of curiosity, why would you need to use unchecked_add in the array length?

The example is not derived from real code.

not sure which one array length expressions are "closer" to.

To me, array length expressions feel even more part of their containing item than closures, and much more so than nested functions. Not sure how widely shared this is. I suppose we don't allow array length expressions to reference in-scope generic parameters, while we do allow closures to refer to them. I think this is more a technical limitation than a concious choice, however.

ecstatic-morse

comment created time in 7 days

pull request commentrust-lang/rust

Update to LLVM 10

Oh yeah that's right. I just didn't see your comment in time XD. Thank you BTW!

nikic

comment created time in 7 days

pull request commentrust-lang/rust

Update to LLVM 10

@bors p=2

More important than #72205.

nikic

comment created time in 7 days

Pull request review commentrust-lang/rust

Fix `is_const_context`, update `check_for_cast`

 impl<'hir> Map<'hir> {     /// Whether the expression pointed at by `hir_id` belongs to a `const` evaluation context.     /// Used exclusively for diagnostics, to avoid suggestion function calls.     pub fn is_const_context(&self, hir_id: HirId) -> bool {

Just a personal opinion, but what about renaming this to is_expr_inside_const_context? I feel like it's not clear when to use this vs. body_const_context().is_some() at the moment.

lcnr

comment created time in 7 days

pull request commentrust-lang/rust

Dumb NRVO

@Dylan-DPC Can I increase this to p=1? I'd like this to get as much testing as possible before it reaches stable.

ecstatic-morse

comment created time in 7 days

issue commentrust-lang/rust

`HirId`-ification initiative

I suspect we'll need a "pre-HIR" and "post-HIR" version of that data structure, converting between them during lowering. This is easier said than done obviously.

zackmdavis

comment created time in 7 days

issue commentrust-lang/rust

`HirId`-ification initiative

Seems like ResolverOutputs could be updated to use DefIds instead of NodeIds.

https://github.com/rust-lang/rust/blob/89988fe727a5f055da78a4278448cfbca0c49e19/src/librustc_middle/ty/mod.rs#L120-L132

zackmdavis

comment created time in 7 days

pull request commentrust-lang/rust

Remove unused `StableHashingContext::node_to_hir_id` method

@bors r+ rollup

marmeladema

comment created time in 7 days

pull request commentrust-lang/rust

Use `once_cell` crate instead of custom data structure

@bors retry

ecstatic-morse

comment created time in 7 days

more