profile
viewpoint
Wesley Wiser wesleywiser HighGear Maryland @rust-lang Compiler Team, Senior Software Enginer @SwiftSoftware-Inc

rust-lang/measureme 116

Support crate for rustc's self-profiling feature

wesleywiser/process_path 4

A Rust library to get the path of the currently executing process

JasonKleban/Unbounded 2

F# to T-SQL. Remote command execution and domain invariant enforcement

wesleywiser/Expert-System 1

An example expert system for CS 428

wesleywiser/FSharpSnippets 1

Snippets and modules of F# code.

wesleywiser/IronJS 1

IronJS - A JavaScript implementation for .NET written in F#

wesleywiser/jquery-mobile 1

jQuery Mobile Framework

wesleywiser/Reconnect-wifi-daemon 1

A simple daemon for Ubuntu which causes your computer to automatically reconnect to a specific wifi access point.

pull request commentrust-lang/rust

Completes support for coverage in external crates

@bors r+

richkadel

comment created time in 2 hours

pull request commentrust-lang/rust

Completes support for coverage in external crates

I'm not super familiar with the new CI setup. IIRC try runs in a different repo for some reason related to permissions? Are the links here what you're looking for? https://github.com/rust-lang/rust/pull/75037#issuecomment-668626344

richkadel

comment created time in 8 hours

pull request commentrust-lang/rust

Completes support for coverage in external crates

@bors r+ rollup=maybe

richkadel

comment created time in 9 hours

issue commentrust-lang/rust

Optimize `matches!()` invocations at the MIR level

Oh yeah, even better. I just trying to match the existing semantics as closely as possible.

wesleywiser

comment created time in 9 hours

pull request commentrust-lang/rust

Completes support for coverage in external crates

Yeah, we can give it a go.

@bors try

richkadel

comment created time in 9 hours

issue openedrust-lang/rust

Optimize `matches!()` invocations at the MIR level

Right now, matches!() generates MIR that sometimes has more branches than required. As an example:

fn foo(bar: Option<()>) {
    if matches!(bar, None) {
        stuff();
    }
}

generates this MIR:

fn foo(_1: std::option::Option<()>) -> () {
    debug bar => _1;
    let mut _0: ();
    let mut _2: bool;
    let mut _3: isize;
    let _4: ();

    bb0: {
        StorageLive(_2);
        _3 = discriminant(_1);
        switchInt(move _3) -> [0isize: bb2, otherwise: bb1];
    }

    bb1: {
        _2 = const false;
        goto -> bb3;
    }

    bb2: {
        _2 = const true;
        goto -> bb3;
    }

    bb3: {
        switchInt(_2) -> [false: bb4, otherwise: bb5];
    }

    bb4: {
        _0 = const ();
        goto -> bb7;
    }

    bb5: {
        StorageLive(_4);
        _4 = const stuff() -> bb6;
    }

    bb6: {
        StorageDead(_4);
        _0 = const ();
        goto -> bb7;
    }

    bb7: {
        StorageDead(_2);
        return;
    }
}

Notice blocks bb0, bb1, bb2 and bb3 which we could transform into something like this:

bb0: {
    StorageLive(_2);
    _3 = discriminant(_1);
    _2 = Eq(move _3, const 0isize);
    switchInt(_2) -> [false: bb4, otherwise: bb5];
}

There may be a compile-time win since we can hand LLVM less code but the optimization would have to be implemented to be sure.

cc @rust-lang/wg-mir-opt

created time in 10 hours

pull request commentrust-lang/rust

Completes support for coverage in external crates

Looks good!

@bors r+

richkadel

comment created time in a day

pull request commentrust-lang/rust

Completes support for coverage in external crates

This leads me to believe that only one copy of the byte array representation of each file will be stored in the encoded MIR.

Does that make sense to you as well?

Yes, that's correct. intern_const_alloc uses allocation_interner which "Stores the value of constants (and deduplicates the actual memory)"

https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.GlobalCtxt.html#structfield.allocation_interner

richkadel

comment created time in a day

pull request commentrust-lang/rust

Completes support for coverage in external crates

@bors r-

richkadel

comment created time in a day

pull request commentrust-lang/rust

Completes support for coverage in external crates

@bors r=wesleywiser r+ rollup=always

richkadel

comment created time in 2 days

Pull request review commentrust-lang/rust

Completes support for coverage in external crates

 impl<'tcx> ConstValue<'tcx> {         }     } +    pub fn try_to_str_slice(&self) -> Option<&'tcx str> {+        match *self {+            ConstValue::Slice { data, start, end } => ::std::str::from_utf8(+                data.inspect_with_undef_and_ptr_outside_interpreter(start..end),+            )+            .map_or(None, |s| Some(s)),+            _ => None,+        }
        if let ConstVal::Slice { data, start, end } = *self {
            str::from_utf8(data.inspect_with_undef_and_ptr_outside_interpreter(start .. end).ok()
        } else {
            None
        }
richkadel

comment created time in 2 days

push eventrust-lang/measureme

Aaron Hill

commit sha 7855b1e932b895f49c8e4387d4112444faa40997

Update to parking_lot 0.11.0

view details

Wesley Wiser

commit sha 048883e08dc896b33465bf963f4b2fb03ac2792c

Merge pull request #122 from Aaron1011/update/parking-lot Update to parking_lot 0.11.0

view details

push time in 2 days

pull request commentrust-lang/measureme

Update to parking_lot 0.11.0

Thanks!

Aaron1011

comment created time in 2 days

push eventSwiftSoftware-Inc/react-datetime-swift

dependabot[bot]

commit sha 442ff53223e0f3334fee302783d74035b512e0e6

Bump elliptic from 6.4.0 to 6.5.3 Bumps [elliptic](https://github.com/indutny/elliptic) from 6.4.0 to 6.5.3. - [Release notes](https://github.com/indutny/elliptic/releases) - [Commits](https://github.com/indutny/elliptic/compare/v6.4.0...v6.5.3) Signed-off-by: dependabot[bot] <support@github.com>

view details

push time in 3 days

PR merged SwiftSoftware-Inc/react-datetime-swift

Bump elliptic from 6.4.0 to 6.5.3 dependencies

Bumps elliptic from 6.4.0 to 6.5.3. <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/indutny/elliptic/commit/8647803dc3d90506aa03021737f7b061ba959ae1"><code>8647803</code></a> 6.5.3</li> <li><a href="https://github.com/indutny/elliptic/commit/856fe4d99fe7b6200556e6400b3bf585b1721bec"><code>856fe4d</code></a> signature: prevent malleability and overflows</li> <li><a href="https://github.com/indutny/elliptic/commit/60489415e545efdfd3010ae74b9726facbf08ca8"><code>6048941</code></a> 6.5.2</li> <li><a href="https://github.com/indutny/elliptic/commit/9984964457c9f8a63b91b01ea103260417eca237"><code>9984964</code></a> package: bump dependencies</li> <li><a href="https://github.com/indutny/elliptic/commit/ec735edde187a43693197f6fa3667ceade751a3a"><code>ec735ed</code></a> utils: leak less information in <code>getNAF()</code></li> <li><a href="https://github.com/indutny/elliptic/commit/71e4e8e2f5b8f0bdbfbe106c72cc9fbc746d3d60"><code>71e4e8e</code></a> 6.5.1</li> <li><a href="https://github.com/indutny/elliptic/commit/7ec66ffa255079260126d87b1762a59ea10de5ea"><code>7ec66ff</code></a> short: add infinity check before multiplying</li> <li><a href="https://github.com/indutny/elliptic/commit/ee7970b92f388e981d694be0436c4c8036b5d36c"><code>ee7970b</code></a> travis: really move on</li> <li><a href="https://github.com/indutny/elliptic/commit/637d0216b58de7edee4f3eb5641295ac323acadb"><code>637d021</code></a> travis: move on</li> <li><a href="https://github.com/indutny/elliptic/commit/5ed0babb6467cd8575a9218265473fda926d9d42"><code>5ed0bab</code></a> package: update deps</li> <li>Additional commits viewable in <a href="https://github.com/indutny/elliptic/compare/v6.4.0...v6.5.3">compare view</a></li> </ul> </details> <br />

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
  • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
  • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
  • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

+3 -3

0 comment

1 changed file

dependabot[bot]

pr closed time in 3 days

pull request commentrust-lang/rust

Fixed coverage map issues; better aligned with LLVM APIs

@richkadel That seems fine to me. I don't think I've ever touched those tests but I think in general, we'd like to see --bless or some equivalent be available everywhere.

Full integration tests would be great but I'd also like to see more mir-opt tests since they're going to be the most precise.

richkadel

comment created time in 5 days

pull request commentrust-lang/rust

Fixed coverage map issues; better aligned with LLVM APIs

@richkadel By the way, thanks for splitting this work up into lots of PRs! I'm sure it would probably be easier for you to just iterate on the code and dump it over the fence but doing it this way makes reviewing it much more manageable.

When you have this a bit closer to working (which sounds like it may be very soon!), we might want to think about adding a lot more tests both to ensure things are working correctly and to make sure they keep working correctly in the future.

richkadel

comment created time in 5 days

Pull request review commentrust-lang/rust

Fixed coverage map issues; better aligned with LLVM APIs

-use rustc_data_structures::sync::Lrc;-use rustc_middle::mir;-use rustc_span::source_map::{Pos, SourceFile, SourceMap};-use rustc_span::{BytePos, FileName, RealFileName};+use rustc_middle::ty::Instance;+use rustc_middle::ty::TyCtxt;+use rustc_span::source_map::{Pos, SourceMap};+use rustc_span::{BytePos, FileName, Loc, RealFileName};  use std::cmp::{Ord, Ordering};-use std::collections::BTreeMap; use std::fmt; use std::path::PathBuf; +/// Aligns to C++ struct llvm::coverage::Counter::CounterKind.+/// The order of discriminators is important. #[derive(Copy, Clone, Debug)] #[repr(C)]-pub enum CounterOp {-    // Note the order (and therefore the default values) is important. With the attribute-    // `#[repr(C)]`, this enum matches the layout of the LLVM enum defined for the nested enum,-    // `llvm::coverage::CounterExpression::ExprKind`, as shown in the following source snippet:-    // https://github.com/rust-lang/llvm-project/blob/f208b70fbc4dee78067b3c5bd6cb92aa3ba58a1e/llvm/include/llvm/ProfileData/Coverage/CoverageMapping.h#L146-    Subtract,-    Add,+enum CounterKind {+    Zero,+    CounterValueReference,+    Expression, } +/// Aligns to C++ struct llvm::coverage::Counter. Note that `id` has+/// different interpretations, depending on the `kind`:+///   * For `CounterKind::Zero`, `id` is assumed to be `0`+///   * For `CounterKind::CounterValueReference`,  `id` matches the `counter_id` of the injected+///     instrumentation counter (the `index` argument to the LLVM intrinsic `instrprof.increment()`)+///   * For `CounterKind::Expression`, `id` is the index into the array of counter expressions.+/// The order of fields is important. #[derive(Copy, Clone, Debug)]-pub enum CoverageKind {-    Counter,-    CounterExpression(u32, CounterOp, u32),-    Unreachable,+#[repr(C)]+pub struct Counter {+    kind: CounterKind,+    id: u32, } -#[derive(Clone, Debug)]-pub struct CoverageRegion {-    pub kind: CoverageKind,-    pub start_byte_pos: u32,-    pub end_byte_pos: u32,-}+impl Counter {+    pub fn zero() -> Self {+        Self { kind: CounterKind::Zero, id: 0 }+    } -impl CoverageRegion {-    pub fn source_loc(&self, source_map: &SourceMap) -> Option<(Lrc<SourceFile>, CoverageLoc)> {-        let (start_file, start_line, start_col) =-            lookup_file_line_col(source_map, BytePos::from_u32(self.start_byte_pos));-        let (end_file, end_line, end_col) =-            lookup_file_line_col(source_map, BytePos::from_u32(self.end_byte_pos));-        let start_file_path = match &start_file.name {-            FileName::Real(RealFileName::Named(path)) => path,-            _ => {-                bug!("start_file_path should be a RealFileName, but it was: {:?}", start_file.name)-            }-        };-        let end_file_path = match &end_file.name {-            FileName::Real(RealFileName::Named(path)) => path,-            _ => bug!("end_file_path should be a RealFileName, but it was: {:?}", end_file.name),-        };-        if start_file_path == end_file_path {-            Some((start_file, CoverageLoc { start_line, start_col, end_line, end_col }))-        } else {-            None-            // FIXME(richkadel): There seems to be a problem computing the file location in-            // some cases. I need to investigate this more. When I generate and show coverage-            // for the example binary in the crates.io crate `json5format`, I had a couple of-            // notable problems:-            //-            //   1. I saw a lot of coverage spans in `llvm-cov show` highlighting regions in-            //      various comments (not corresponding to rustdoc code), indicating a possible-            //      problem with the byte_pos-to-source-map implementation.-            //-            //   2. And (perhaps not related) when I build the aforementioned example binary with:-            //      `RUST_FLAGS="-Zinstrument-coverage" cargo build --example formatjson5`-            //      and then run that binary with-            //      `LLVM_PROFILE_FILE="formatjson5.profraw" ./target/debug/examples/formatjson5 \-            //      some.json5` for some reason the binary generates *TWO* `.profraw` files. One-            //      named `default.profraw` and the other named `formatjson5.profraw` (the expected-            //      name, in this case).-            //-            // If the byte range conversion is wrong, fix it. But if it-            // is right, then it is possible for the start and end to be in different files.-            // Can I do something other than ignore coverages that span multiple files?-            //-            // If I can resolve this, remove the "Option<>" result type wrapper-            // `regions_in_file_order()` accordingly.-        }+    pub fn counter_value_reference(counter_id: u32) -> Self {+        Self { kind: CounterKind::CounterValueReference, id: counter_id }+    }++    pub fn expression(final_expression_index: u32) -> Self {+        Self { kind: CounterKind::Expression, id: final_expression_index }     } } -impl Default for CoverageRegion {-    fn default() -> Self {-        Self {-            // The default kind (Unreachable) is a placeholder that will be overwritten before-            // backend codegen.-            kind: CoverageKind::Unreachable,-            start_byte_pos: 0,-            end_byte_pos: 0,-        }+/// Aligns to C++ struct llvm::coverage::CounterExpression::ExprKind.+/// The order of discriminators is important.+#[derive(Copy, Clone, Debug)]+#[repr(C)]+pub enum ExprKind {+    Subtract,+    Add,+}++/// Aligns to C++ struct llvm::coverage::CounterExpression.+/// The order of fields is important.+#[derive(Copy, Clone, Debug)]+#[repr(C)]+pub struct CounterExpression {+    // Note the field order is important.+    kind: ExprKind,+    lhs: Counter,+    rhs: Counter,+}++impl CounterExpression {+    pub fn new(lhs: Counter, kind: ExprKind, rhs: Counter) -> Self {+        Self { kind, lhs, rhs }     } } -/// A source code region used with coverage information.-#[derive(Debug, Eq, PartialEq)]-pub struct CoverageLoc {-    /// The (1-based) line number of the region start.-    pub start_line: u32,-    /// The (1-based) column number of the region start.-    pub start_col: u32,-    /// The (1-based) line number of the region end.-    pub end_line: u32,-    /// The (1-based) column number of the region end.-    pub end_col: u32,+#[derive(Clone, Debug)]+pub struct Region {+    start: Loc,+    end: Loc, } -impl Ord for CoverageLoc {+impl Ord for Region {

Ah, ok. Makes sense.

richkadel

comment created time in 7 days

Pull request review commentrust-lang/rust

Fixed coverage map issues; better aligned with LLVM APIs

 impl CoverageInfoBuilderMethods<'tcx> for Builder<'a, 'll, 'tcx> {         let mut coverage_regions = self.coverage_context().function_coverage_map.borrow_mut();         coverage_regions             .entry(instance)-            .or_insert_with(|| {-                FunctionCoverage::with_coverageinfo(self.tcx.coverageinfo(instance.def_id()))-            })-            .add_unreachable(start_byte_pos, end_byte_pos);+            .or_insert_with(|| FunctionCoverage::new(self.tcx, instance))+            .add_unreachable_region(start_byte_pos, end_byte_pos);     } } -/// This struct wraps an opaque reference to the C++ template instantiation of-/// `llvm::SmallVector<coverage::CounterExpression>`. Each `coverage::CounterExpression` object is-/// constructed from primative-typed arguments, and pushed to the `SmallVector`, in the C++-/// implementation of `LLVMRustCoverageSmallVectorCounterExpressionAdd()` (see-/// `src/rustllvm/CoverageMappingWrapper.cpp`).-pub struct SmallVectorCounterExpression<'a> {-    pub raw: &'a mut llvm::coverageinfo::SmallVectorCounterExpression<'a>,-}+/// Aligns to C++ struct llvm::coverage::Counter::CounterKind.+/// The order of discrimiators is important.+#[derive(Copy, Clone, Debug)]+#[repr(C)]+enum RegionKind {+    /// A CodeRegion associates some code with a counter+    CodeRegion,

I think linking to a specific version is fine. IIRC we do similar things in other places so there's precedent for that.

richkadel

comment created time in 7 days

Pull request review commentrust-lang/rust

Fixed coverage map issues; better aligned with LLVM APIs

 impl CoverageInfoBuilderMethods<'tcx> for Builder<'a, 'll, 'tcx> {         let mut coverage_regions = self.coverage_context().function_coverage_map.borrow_mut();         coverage_regions             .entry(instance)-            .or_insert_with(|| {-                FunctionCoverage::with_coverageinfo(self.tcx.coverageinfo(instance.def_id()))-            })-            .add_unreachable(start_byte_pos, end_byte_pos);+            .or_insert_with(|| FunctionCoverage::new(self.tcx, instance))+            .add_unreachable_region(start_byte_pos, end_byte_pos);     } } -/// This struct wraps an opaque reference to the C++ template instantiation of-/// `llvm::SmallVector<coverage::CounterExpression>`. Each `coverage::CounterExpression` object is-/// constructed from primative-typed arguments, and pushed to the `SmallVector`, in the C++-/// implementation of `LLVMRustCoverageSmallVectorCounterExpressionAdd()` (see-/// `src/rustllvm/CoverageMappingWrapper.cpp`).-pub struct SmallVectorCounterExpression<'a> {-    pub raw: &'a mut llvm::coverageinfo::SmallVectorCounterExpression<'a>,-}+/// Aligns to C++ struct llvm::coverage::Counter::CounterKind.+/// The order of discrimiators is important.

Yeah, that makes sense!

richkadel

comment created time in 7 days

pull request commentrust-lang/rust

MIR-OPT: New pass to allow removal of identity match with fieldless variant

I agree, I think we should work on improving the SimplifyBranchSame pass instead of introducing another pass. SimplifyBranchSame already checks for a number of required preconditions (such as ensuring we don't introduce a use-after-move) that would have to be replicated in this pass anyway.

simonvandel

comment created time in 7 days

Pull request review commentrust-lang/rust

Fixed coverage map issues; better aligned with LLVM APIs

-use rustc_data_structures::sync::Lrc;-use rustc_middle::mir;-use rustc_span::source_map::{Pos, SourceFile, SourceMap};-use rustc_span::{BytePos, FileName, RealFileName};+use rustc_middle::ty::Instance;+use rustc_middle::ty::TyCtxt;+use rustc_span::source_map::{Pos, SourceMap};+use rustc_span::{BytePos, FileName, Loc, RealFileName};  use std::cmp::{Ord, Ordering};-use std::collections::BTreeMap; use std::fmt; use std::path::PathBuf; +/// Aligns to C++ struct llvm::coverage::Counter::CounterKind.+/// The order of discriminators is important. #[derive(Copy, Clone, Debug)] #[repr(C)]-pub enum CounterOp {-    // Note the order (and therefore the default values) is important. With the attribute-    // `#[repr(C)]`, this enum matches the layout of the LLVM enum defined for the nested enum,-    // `llvm::coverage::CounterExpression::ExprKind`, as shown in the following source snippet:-    // https://github.com/rust-lang/llvm-project/blob/f208b70fbc4dee78067b3c5bd6cb92aa3ba58a1e/llvm/include/llvm/ProfileData/Coverage/CoverageMapping.h#L146-    Subtract,-    Add,+enum CounterKind {+    Zero,+    CounterValueReference,+    Expression, } +/// Aligns to C++ struct llvm::coverage::Counter. Note that `id` has+/// different interpretations, depending on the `kind`:+///   * For `CounterKind::Zero`, `id` is assumed to be `0`+///   * For `CounterKind::CounterValueReference`,  `id` matches the `counter_id` of the injected+///     instrumentation counter (the `index` argument to the LLVM intrinsic `instrprof.increment()`)+///   * For `CounterKind::Expression`, `id` is the index into the array of counter expressions.+/// The order of fields is important. #[derive(Copy, Clone, Debug)]-pub enum CoverageKind {-    Counter,-    CounterExpression(u32, CounterOp, u32),-    Unreachable,+#[repr(C)]+pub struct Counter {+    kind: CounterKind,+    id: u32, } -#[derive(Clone, Debug)]-pub struct CoverageRegion {-    pub kind: CoverageKind,-    pub start_byte_pos: u32,-    pub end_byte_pos: u32,-}+impl Counter {+    pub fn zero() -> Self {+        Self { kind: CounterKind::Zero, id: 0 }+    } -impl CoverageRegion {-    pub fn source_loc(&self, source_map: &SourceMap) -> Option<(Lrc<SourceFile>, CoverageLoc)> {-        let (start_file, start_line, start_col) =-            lookup_file_line_col(source_map, BytePos::from_u32(self.start_byte_pos));-        let (end_file, end_line, end_col) =-            lookup_file_line_col(source_map, BytePos::from_u32(self.end_byte_pos));-        let start_file_path = match &start_file.name {-            FileName::Real(RealFileName::Named(path)) => path,-            _ => {-                bug!("start_file_path should be a RealFileName, but it was: {:?}", start_file.name)-            }-        };-        let end_file_path = match &end_file.name {-            FileName::Real(RealFileName::Named(path)) => path,-            _ => bug!("end_file_path should be a RealFileName, but it was: {:?}", end_file.name),-        };-        if start_file_path == end_file_path {-            Some((start_file, CoverageLoc { start_line, start_col, end_line, end_col }))-        } else {-            None-            // FIXME(richkadel): There seems to be a problem computing the file location in-            // some cases. I need to investigate this more. When I generate and show coverage-            // for the example binary in the crates.io crate `json5format`, I had a couple of-            // notable problems:-            //-            //   1. I saw a lot of coverage spans in `llvm-cov show` highlighting regions in-            //      various comments (not corresponding to rustdoc code), indicating a possible-            //      problem with the byte_pos-to-source-map implementation.-            //-            //   2. And (perhaps not related) when I build the aforementioned example binary with:-            //      `RUST_FLAGS="-Zinstrument-coverage" cargo build --example formatjson5`-            //      and then run that binary with-            //      `LLVM_PROFILE_FILE="formatjson5.profraw" ./target/debug/examples/formatjson5 \-            //      some.json5` for some reason the binary generates *TWO* `.profraw` files. One-            //      named `default.profraw` and the other named `formatjson5.profraw` (the expected-            //      name, in this case).-            //-            // If the byte range conversion is wrong, fix it. But if it-            // is right, then it is possible for the start and end to be in different files.-            // Can I do something other than ignore coverages that span multiple files?-            //-            // If I can resolve this, remove the "Option<>" result type wrapper-            // `regions_in_file_order()` accordingly.-        }+    pub fn counter_value_reference(counter_id: u32) -> Self {+        Self { kind: CounterKind::CounterValueReference, id: counter_id }+    }++    pub fn expression(final_expression_index: u32) -> Self {+        Self { kind: CounterKind::Expression, id: final_expression_index }     } } -impl Default for CoverageRegion {-    fn default() -> Self {-        Self {-            // The default kind (Unreachable) is a placeholder that will be overwritten before-            // backend codegen.-            kind: CoverageKind::Unreachable,-            start_byte_pos: 0,-            end_byte_pos: 0,-        }+/// Aligns to C++ struct llvm::coverage::CounterExpression::ExprKind.+/// The order of discriminators is important.+#[derive(Copy, Clone, Debug)]+#[repr(C)]+pub enum ExprKind {+    Subtract,+    Add,+}++/// Aligns to C++ struct llvm::coverage::CounterExpression.+/// The order of fields is important.+#[derive(Copy, Clone, Debug)]+#[repr(C)]+pub struct CounterExpression {+    // Note the field order is important.+    kind: ExprKind,+    lhs: Counter,+    rhs: Counter,+}++impl CounterExpression {+    pub fn new(lhs: Counter, kind: ExprKind, rhs: Counter) -> Self {+        Self { kind, lhs, rhs }     } } -/// A source code region used with coverage information.-#[derive(Debug, Eq, PartialEq)]-pub struct CoverageLoc {-    /// The (1-based) line number of the region start.-    pub start_line: u32,-    /// The (1-based) column number of the region start.-    pub start_col: u32,-    /// The (1-based) line number of the region end.-    pub end_line: u32,-    /// The (1-based) column number of the region end.-    pub end_col: u32,+#[derive(Clone, Debug)]+pub struct Region {+    start: Loc,+    end: Loc, } -impl Ord for CoverageLoc {+impl Ord for Region {

You can probably #[derive(PartialOrd, Ord)]

richkadel

comment created time in 8 days

Pull request review commentrust-lang/rust

Fixed coverage map issues; better aligned with LLVM APIs

-use rustc_data_structures::sync::Lrc;-use rustc_middle::mir;-use rustc_span::source_map::{Pos, SourceFile, SourceMap};-use rustc_span::{BytePos, FileName, RealFileName};+use rustc_middle::ty::Instance;+use rustc_middle::ty::TyCtxt;+use rustc_span::source_map::{Pos, SourceMap};+use rustc_span::{BytePos, FileName, Loc, RealFileName};  use std::cmp::{Ord, Ordering};-use std::collections::BTreeMap; use std::fmt; use std::path::PathBuf; +/// Aligns to C++ struct llvm::coverage::Counter::CounterKind.+/// The order of discriminators is important. #[derive(Copy, Clone, Debug)] #[repr(C)]-pub enum CounterOp {-    // Note the order (and therefore the default values) is important. With the attribute-    // `#[repr(C)]`, this enum matches the layout of the LLVM enum defined for the nested enum,-    // `llvm::coverage::CounterExpression::ExprKind`, as shown in the following source snippet:-    // https://github.com/rust-lang/llvm-project/blob/f208b70fbc4dee78067b3c5bd6cb92aa3ba58a1e/llvm/include/llvm/ProfileData/Coverage/CoverageMapping.h#L146-    Subtract,-    Add,+enum CounterKind {+    Zero,+    CounterValueReference,+    Expression, } +/// Aligns to C++ struct llvm::coverage::Counter. Note that `id` has+/// different interpretations, depending on the `kind`:+///   * For `CounterKind::Zero`, `id` is assumed to be `0`+///   * For `CounterKind::CounterValueReference`,  `id` matches the `counter_id` of the injected+///     instrumentation counter (the `index` argument to the LLVM intrinsic `instrprof.increment()`)+///   * For `CounterKind::Expression`, `id` is the index into the array of counter expressions.+/// The order of fields is important. #[derive(Copy, Clone, Debug)]-pub enum CoverageKind {-    Counter,-    CounterExpression(u32, CounterOp, u32),-    Unreachable,+#[repr(C)]+pub struct Counter {+    kind: CounterKind,+    id: u32, } -#[derive(Clone, Debug)]-pub struct CoverageRegion {-    pub kind: CoverageKind,-    pub start_byte_pos: u32,-    pub end_byte_pos: u32,-}+impl Counter {+    pub fn zero() -> Self {+        Self { kind: CounterKind::Zero, id: 0 }+    } -impl CoverageRegion {-    pub fn source_loc(&self, source_map: &SourceMap) -> Option<(Lrc<SourceFile>, CoverageLoc)> {-        let (start_file, start_line, start_col) =-            lookup_file_line_col(source_map, BytePos::from_u32(self.start_byte_pos));-        let (end_file, end_line, end_col) =-            lookup_file_line_col(source_map, BytePos::from_u32(self.end_byte_pos));-        let start_file_path = match &start_file.name {-            FileName::Real(RealFileName::Named(path)) => path,-            _ => {-                bug!("start_file_path should be a RealFileName, but it was: {:?}", start_file.name)-            }-        };-        let end_file_path = match &end_file.name {-            FileName::Real(RealFileName::Named(path)) => path,-            _ => bug!("end_file_path should be a RealFileName, but it was: {:?}", end_file.name),-        };-        if start_file_path == end_file_path {-            Some((start_file, CoverageLoc { start_line, start_col, end_line, end_col }))-        } else {-            None-            // FIXME(richkadel): There seems to be a problem computing the file location in-            // some cases. I need to investigate this more. When I generate and show coverage-            // for the example binary in the crates.io crate `json5format`, I had a couple of-            // notable problems:-            //-            //   1. I saw a lot of coverage spans in `llvm-cov show` highlighting regions in-            //      various comments (not corresponding to rustdoc code), indicating a possible-            //      problem with the byte_pos-to-source-map implementation.-            //-            //   2. And (perhaps not related) when I build the aforementioned example binary with:-            //      `RUST_FLAGS="-Zinstrument-coverage" cargo build --example formatjson5`-            //      and then run that binary with-            //      `LLVM_PROFILE_FILE="formatjson5.profraw" ./target/debug/examples/formatjson5 \-            //      some.json5` for some reason the binary generates *TWO* `.profraw` files. One-            //      named `default.profraw` and the other named `formatjson5.profraw` (the expected-            //      name, in this case).-            //-            // If the byte range conversion is wrong, fix it. But if it-            // is right, then it is possible for the start and end to be in different files.-            // Can I do something other than ignore coverages that span multiple files?-            //-            // If I can resolve this, remove the "Option<>" result type wrapper-            // `regions_in_file_order()` accordingly.-        }+    pub fn counter_value_reference(counter_id: u32) -> Self {+        Self { kind: CounterKind::CounterValueReference, id: counter_id }+    }++    pub fn expression(final_expression_index: u32) -> Self {+        Self { kind: CounterKind::Expression, id: final_expression_index }     } } -impl Default for CoverageRegion {-    fn default() -> Self {-        Self {-            // The default kind (Unreachable) is a placeholder that will be overwritten before-            // backend codegen.-            kind: CoverageKind::Unreachable,-            start_byte_pos: 0,-            end_byte_pos: 0,-        }+/// Aligns to C++ struct llvm::coverage::CounterExpression::ExprKind.+/// The order of discriminators is important.+#[derive(Copy, Clone, Debug)]+#[repr(C)]+pub enum ExprKind {+    Subtract,+    Add,

Same here

richkadel

comment created time in 8 days

Pull request review commentrust-lang/rust

Fixed coverage map issues; better aligned with LLVM APIs

-use rustc_data_structures::sync::Lrc;-use rustc_middle::mir;-use rustc_span::source_map::{Pos, SourceFile, SourceMap};-use rustc_span::{BytePos, FileName, RealFileName};+use rustc_middle::ty::Instance;+use rustc_middle::ty::TyCtxt;+use rustc_span::source_map::{Pos, SourceMap};+use rustc_span::{BytePos, FileName, Loc, RealFileName};  use std::cmp::{Ord, Ordering};-use std::collections::BTreeMap; use std::fmt; use std::path::PathBuf; +/// Aligns to C++ struct llvm::coverage::Counter::CounterKind.+/// The order of discriminators is important. #[derive(Copy, Clone, Debug)] #[repr(C)]-pub enum CounterOp {-    // Note the order (and therefore the default values) is important. With the attribute-    // `#[repr(C)]`, this enum matches the layout of the LLVM enum defined for the nested enum,-    // `llvm::coverage::CounterExpression::ExprKind`, as shown in the following source snippet:-    // https://github.com/rust-lang/llvm-project/blob/f208b70fbc4dee78067b3c5bd6cb92aa3ba58a1e/llvm/include/llvm/ProfileData/Coverage/CoverageMapping.h#L146-    Subtract,-    Add,+enum CounterKind {+    Zero,+    CounterValueReference,+    Expression, } +/// Aligns to C++ struct llvm::coverage::Counter. Note that `id` has+/// different interpretations, depending on the `kind`:+///   * For `CounterKind::Zero`, `id` is assumed to be `0`+///   * For `CounterKind::CounterValueReference`,  `id` matches the `counter_id` of the injected+///     instrumentation counter (the `index` argument to the LLVM intrinsic `instrprof.increment()`)+///   * For `CounterKind::Expression`, `id` is the index into the array of counter expressions.+/// The order of fields is important. #[derive(Copy, Clone, Debug)]-pub enum CoverageKind {-    Counter,-    CounterExpression(u32, CounterOp, u32),-    Unreachable,+#[repr(C)]+pub struct Counter {+    kind: CounterKind,+    id: u32, } -#[derive(Clone, Debug)]-pub struct CoverageRegion {-    pub kind: CoverageKind,-    pub start_byte_pos: u32,-    pub end_byte_pos: u32,-}+impl Counter {+    pub fn zero() -> Self {+        Self { kind: CounterKind::Zero, id: 0 }+    } -impl CoverageRegion {-    pub fn source_loc(&self, source_map: &SourceMap) -> Option<(Lrc<SourceFile>, CoverageLoc)> {-        let (start_file, start_line, start_col) =-            lookup_file_line_col(source_map, BytePos::from_u32(self.start_byte_pos));-        let (end_file, end_line, end_col) =-            lookup_file_line_col(source_map, BytePos::from_u32(self.end_byte_pos));-        let start_file_path = match &start_file.name {-            FileName::Real(RealFileName::Named(path)) => path,-            _ => {-                bug!("start_file_path should be a RealFileName, but it was: {:?}", start_file.name)-            }-        };-        let end_file_path = match &end_file.name {-            FileName::Real(RealFileName::Named(path)) => path,-            _ => bug!("end_file_path should be a RealFileName, but it was: {:?}", end_file.name),-        };-        if start_file_path == end_file_path {-            Some((start_file, CoverageLoc { start_line, start_col, end_line, end_col }))-        } else {-            None-            // FIXME(richkadel): There seems to be a problem computing the file location in-            // some cases. I need to investigate this more. When I generate and show coverage-            // for the example binary in the crates.io crate `json5format`, I had a couple of-            // notable problems:-            //-            //   1. I saw a lot of coverage spans in `llvm-cov show` highlighting regions in-            //      various comments (not corresponding to rustdoc code), indicating a possible-            //      problem with the byte_pos-to-source-map implementation.-            //-            //   2. And (perhaps not related) when I build the aforementioned example binary with:-            //      `RUST_FLAGS="-Zinstrument-coverage" cargo build --example formatjson5`-            //      and then run that binary with-            //      `LLVM_PROFILE_FILE="formatjson5.profraw" ./target/debug/examples/formatjson5 \-            //      some.json5` for some reason the binary generates *TWO* `.profraw` files. One-            //      named `default.profraw` and the other named `formatjson5.profraw` (the expected-            //      name, in this case).-            //-            // If the byte range conversion is wrong, fix it. But if it-            // is right, then it is possible for the start and end to be in different files.-            // Can I do something other than ignore coverages that span multiple files?-            //-            // If I can resolve this, remove the "Option<>" result type wrapper-            // `regions_in_file_order()` accordingly.-        }+    pub fn counter_value_reference(counter_id: u32) -> Self {+        Self { kind: CounterKind::CounterValueReference, id: counter_id }+    }++    pub fn expression(final_expression_index: u32) -> Self {+        Self { kind: CounterKind::Expression, id: final_expression_index }     } } -impl Default for CoverageRegion {-    fn default() -> Self {-        Self {-            // The default kind (Unreachable) is a placeholder that will be overwritten before-            // backend codegen.-            kind: CoverageKind::Unreachable,-            start_byte_pos: 0,-            end_byte_pos: 0,-        }+/// Aligns to C++ struct llvm::coverage::CounterExpression::ExprKind.+/// The order of discriminators is important.+#[derive(Copy, Clone, Debug)]+#[repr(C)]+pub enum ExprKind {+    Subtract,+    Add,+}++/// Aligns to C++ struct llvm::coverage::CounterExpression.+/// The order of fields is important.+#[derive(Copy, Clone, Debug)]+#[repr(C)]+pub struct CounterExpression {+    // Note the field order is important.+    kind: ExprKind,+    lhs: Counter,+    rhs: Counter,+}++impl CounterExpression {+    pub fn new(lhs: Counter, kind: ExprKind, rhs: Counter) -> Self {+        Self { kind, lhs, rhs }     } } -/// A source code region used with coverage information.-#[derive(Debug, Eq, PartialEq)]-pub struct CoverageLoc {-    /// The (1-based) line number of the region start.-    pub start_line: u32,-    /// The (1-based) column number of the region start.-    pub start_col: u32,-    /// The (1-based) line number of the region end.-    pub end_line: u32,-    /// The (1-based) column number of the region end.-    pub end_col: u32,+#[derive(Clone, Debug)]+pub struct Region {+    start: Loc,+    end: Loc, } -impl Ord for CoverageLoc {+impl Ord for Region {     fn cmp(&self, other: &Self) -> Ordering {-        (self.start_line, &self.start_col, &self.end_line, &self.end_col).cmp(&(-            other.start_line,-            &other.start_col,-            &other.end_line,-            &other.end_col,-        ))+        (&self.start.file.name, &self.start.line, &self.start.col, &self.end.line, &self.end.col)+            .cmp(&(+                &other.start.file.name,+                &other.start.line,+                &other.start.col,+                &other.end.line,+                &other.end.col,+            ))     } } -impl PartialOrd for CoverageLoc {+impl PartialOrd for Region {     fn partial_cmp(&self, other: &Self) -> Option<Ordering> {         Some(self.cmp(other))     } } -impl fmt::Display for CoverageLoc {+impl PartialEq for Region {

Same with PartialEq and Eq

richkadel

comment created time in 8 days

Pull request review commentrust-lang/rust

Fixed coverage map issues; better aligned with LLVM APIs

-use rustc_data_structures::sync::Lrc;-use rustc_middle::mir;-use rustc_span::source_map::{Pos, SourceFile, SourceMap};-use rustc_span::{BytePos, FileName, RealFileName};+use rustc_middle::ty::Instance;+use rustc_middle::ty::TyCtxt;+use rustc_span::source_map::{Pos, SourceMap};+use rustc_span::{BytePos, FileName, Loc, RealFileName};  use std::cmp::{Ord, Ordering};-use std::collections::BTreeMap; use std::fmt; use std::path::PathBuf; +/// Aligns to C++ struct llvm::coverage::Counter::CounterKind.+/// The order of discriminators is important. #[derive(Copy, Clone, Debug)] #[repr(C)]-pub enum CounterOp {-    // Note the order (and therefore the default values) is important. With the attribute-    // `#[repr(C)]`, this enum matches the layout of the LLVM enum defined for the nested enum,-    // `llvm::coverage::CounterExpression::ExprKind`, as shown in the following source snippet:-    // https://github.com/rust-lang/llvm-project/blob/f208b70fbc4dee78067b3c5bd6cb92aa3ba58a1e/llvm/include/llvm/ProfileData/Coverage/CoverageMapping.h#L146-    Subtract,-    Add,+enum CounterKind {+    Zero,+    CounterValueReference,+    Expression,

Same thing here

richkadel

comment created time in 8 days

Pull request review commentrust-lang/rust

Fixed coverage map issues; better aligned with LLVM APIs

 impl CoverageInfoBuilderMethods<'tcx> for Builder<'a, 'll, 'tcx> {         let mut coverage_regions = self.coverage_context().function_coverage_map.borrow_mut();         coverage_regions             .entry(instance)-            .or_insert_with(|| {-                FunctionCoverage::with_coverageinfo(self.tcx.coverageinfo(instance.def_id()))-            })-            .add_unreachable(start_byte_pos, end_byte_pos);+            .or_insert_with(|| FunctionCoverage::new(self.tcx, instance))+            .add_unreachable_region(start_byte_pos, end_byte_pos);     } } -/// This struct wraps an opaque reference to the C++ template instantiation of-/// `llvm::SmallVector<coverage::CounterExpression>`. Each `coverage::CounterExpression` object is-/// constructed from primative-typed arguments, and pushed to the `SmallVector`, in the C++-/// implementation of `LLVMRustCoverageSmallVectorCounterExpressionAdd()` (see-/// `src/rustllvm/CoverageMappingWrapper.cpp`).-pub struct SmallVectorCounterExpression<'a> {-    pub raw: &'a mut llvm::coverageinfo::SmallVectorCounterExpression<'a>,-}+/// Aligns to C++ struct llvm::coverage::Counter::CounterKind.+/// The order of discrimiators is important.+#[derive(Copy, Clone, Debug)]+#[repr(C)]+enum RegionKind {+    /// A CodeRegion associates some code with a counter+    CodeRegion,
    CodeRegion = 0,

etc

richkadel

comment created time in 8 days

Pull request review commentrust-lang/rust

Fixed coverage map issues; better aligned with LLVM APIs

 use std::path::PathBuf; /// undocumented details in Clang's implementation (that may or may not be important) were also /// replicated for Rust's Coverage Map. pub fn finalize<'ll, 'tcx>(cx: &CodegenCx<'ll, 'tcx>) {-    let mut coverage_writer = CoverageMappingWriter::new(cx);-     let function_coverage_map = cx.coverage_context().take_function_coverage_map();+    if function_coverage_map.len() == 0 {+        // This module has no functions with coverage instrumentation+        return;+    }++    let mut mapgen = CoverageMapGenerator::new();      // Encode coverage mappings and generate function records     let mut function_records = Vec::<&'ll llvm::Value>::new();     let coverage_mappings_buffer = llvm::build_byte_buffer(|coverage_mappings_buffer| {         for (instance, function_coverage) in function_coverage_map.into_iter() {-            if let Some(function_record) = coverage_writer.write_function_mappings_and_record(-                instance,-                function_coverage,-                coverage_mappings_buffer,-            ) {-                function_records.push(function_record);-            }+            debug!("Generate coverage map for: {:?}", instance);++            let mangled_function_name = cx.tcx.symbol_name(instance).to_string();+            let function_source_hash = function_coverage.source_hash();+            let (expressions, counter_regions) =+                function_coverage.get_expressions_and_counter_regions();++            let old_len = coverage_mappings_buffer.len();+            mapgen.write_coverage_mappings(expressions, counter_regions, coverage_mappings_buffer);+            let mapping_data_size = coverage_mappings_buffer.len() - old_len;+            debug_assert!(+                mapping_data_size > 0,+                "Every `FunctionCoverage` should have at least one counter"+            );++            let function_record = mapgen.make_function_record(+                cx,+                mangled_function_name,+                function_source_hash,+                mapping_data_size,+            );+            function_records.push(function_record);         }     }); -    // Encode all filenames covered in this module, ordered by `file_id`+    // Encode all filenames referenced by counters/expressions in this module     let filenames_buffer = llvm::build_byte_buffer(|filenames_buffer| {-        coverageinfo::write_filenames_section_to_buffer(-            &coverage_writer.filenames,-            filenames_buffer,-        );+        coverageinfo::write_filenames_section_to_buffer(&mapgen.filenames, filenames_buffer);     }); -    if coverage_mappings_buffer.len() > 0 {-        // Generate the LLVM IR representation of the coverage map and store it in a well-known-        // global constant.-        coverage_writer.write_coverage_map(-            function_records,-            filenames_buffer,-            coverage_mappings_buffer,-        );-    }+    // Generate the LLVM IR representation of the coverage map and store it in a well-known global+    mapgen.save_generated_coverage_map(+        cx,+        function_records,+        filenames_buffer,+        coverage_mappings_buffer,+    ); } -struct CoverageMappingWriter<'a, 'll, 'tcx> {-    cx: &'a CodegenCx<'ll, 'tcx>,+struct CoverageMapGenerator {     filenames: Vec<CString>,     filename_to_index: FxHashMap<CString, u32>, } -impl<'a, 'll, 'tcx> CoverageMappingWriter<'a, 'll, 'tcx> {-    fn new(cx: &'a CodegenCx<'ll, 'tcx>) -> Self {-        Self { cx, filenames: Vec::new(), filename_to_index: FxHashMap::<CString, u32>::default() }+impl CoverageMapGenerator {+    fn new() -> Self {+        Self { filenames: Vec::new(), filename_to_index: FxHashMap::<CString, u32>::default() }

Nit: You can just say FxHashMap::default() here.

richkadel

comment created time in 8 days

Pull request review commentrust-lang/rust

Fixed coverage map issues; better aligned with LLVM APIs

 impl CoverageInfoBuilderMethods<'tcx> for Builder<'a, 'll, 'tcx> {         let mut coverage_regions = self.coverage_context().function_coverage_map.borrow_mut();         coverage_regions             .entry(instance)-            .or_insert_with(|| {-                FunctionCoverage::with_coverageinfo(self.tcx.coverageinfo(instance.def_id()))-            })-            .add_unreachable(start_byte_pos, end_byte_pos);+            .or_insert_with(|| FunctionCoverage::new(self.tcx, instance))+            .add_unreachable_region(start_byte_pos, end_byte_pos);     } } -/// This struct wraps an opaque reference to the C++ template instantiation of-/// `llvm::SmallVector<coverage::CounterExpression>`. Each `coverage::CounterExpression` object is-/// constructed from primative-typed arguments, and pushed to the `SmallVector`, in the C++-/// implementation of `LLVMRustCoverageSmallVectorCounterExpressionAdd()` (see-/// `src/rustllvm/CoverageMappingWrapper.cpp`).-pub struct SmallVectorCounterExpression<'a> {-    pub raw: &'a mut llvm::coverageinfo::SmallVectorCounterExpression<'a>,-}+/// Aligns to C++ struct llvm::coverage::Counter::CounterKind.+/// The order of discrimiators is important.

Nit: these are usually called "variants". We should probably go ahead and give them explicit values as well.

richkadel

comment created time in 8 days

PR opened rust-lang/rust

Stable backport of #73669

This is the backport of #73669 to stable.

r? @ghost

cc @Mark-Simulacrum

+202 -50

0 comment

8 changed files

pr created time in 10 days

create barnchwesleywiser/rust

branch : stable_backport_73669

created branch time in 10 days

issue commentrust-lang/rust

Regression from 1.44 to 1.45

As far as I know, rustup has no support for yanking releases. Doing so would probably have to be done manually by the infra team and it could cause more harm than good. For example, are current or old versions of rustup going to gracefully handle the case where a user has an installed release that doesn't exist anymore? We've had other point releases for major issues in the past and users are generally quick to upgrade.

There is already a 1.45.1 release scheduled for later this week with other backports and this fix will almost certainly be included.

mcarton

comment created time in 10 days

pull request commentrust-lang/rust

[mir-opt] Allow debuginfo to be generated for a constant or a Place

Rebased and added

// compile-flags: -C overflow-checks=no

to the new test case which fixed the failure on i686-gnu-nopt.

wesleywiser

comment created time in 11 days

push eventwesleywiser/rust

Caio

commit sha 187aea7c34adf06b0db39f688d60d3fdac8e7e3e

Impl Default for ranges

view details

Jamie Cunliffe

commit sha fc52b47e8013da325fc0a0f5d3897143243ba206

va_args implementation for AAPCS. Implement the va args in codegen for AAPCS, this will be used as the default va_args implementation for AArch64 rather than the va_args llvm-ir as it currently is. Copyright (c) 2020, Arm Limited.

view details

Dan Gohman

commit sha 83bd3d3975bd56e0bd959b5df8129e4ee21aeca3

Add `RawFd` to WASI's `std::os::wasi::prelude`. Add `RawFd` to WASI's `std::os::wasi::prelude`, making it consistent with all other platforms which also have `AsRawFd`, `FromRawFd`, and `IntoRawFd` in their respective preludes.

view details

Andy Russell

commit sha 133e91da627a42218721caf2083c3f309e1b0dcc

libstd/libcore: fix various typos

view details

Caio

commit sha c3756927478afe8d3a880edc469afd766c2f9e82

Remove some Default impls

view details

Andrew Paverd

commit sha 31c7aae1136b4d80f0256e269ca8086fd3fbdddd

Stabilize control-flow-guard codegen option

view details

Guillaume Gomez

commit sha 839216a57c841c5cdd099cdecf8bd6dbf5808ae4

Improve logo image display in different themes

view details

Bastian Kauschke

commit sha 5300ca38d88b924f7108274c50d918728c53aecd

cleanup ty_is_~non~_local_constructor

view details

Bastian Kauschke

commit sha 1ac3713f256dd379d8fe24b09bc8ba6643ea41b4

refactor ty_is_non_local

view details

Yuki Okushi

commit sha a11024f4f312a49db84d816bf43c7c55d8a21074

Fix debug assertion in typeck

view details

Bastian Kauschke

commit sha e8d16fdf9f95e4110df53650779be842b6749f60

add note to `opt_const_param_of`

view details

Jane Lusby

commit sha 8561b67b6f263b6647f02d36e0824b6c54544bf0

add a Backtrace::disabled function

view details

Jane Lusby

commit sha 397c82bae15031f97bf12f0114834af1ba844b4f

remove trailing semi

view details

Lzu Tao

commit sha 174abeb6cb9553bae0a59fbf0aba186da300d390

Add an border around the Run button

view details

Jarek Samic

commit sha dec70767e533a4603baafb4c209ac3b90bba79f7

Fix search input focus in ayu theme

view details

Lzu Tao

commit sha 0eff3d5d886a2290b4557a4438efe8a6aa6cfba7

Ayu: use different background color to make Run button easy-to-spot Co-authored-by: Cldfire <cldfire@3grid.net>

view details

Lzu Tao

commit sha cfa3a330149b78c4d827b10d9ac4ff8d381e7342

compiletest: Rewrite extract_lldb_version function This makes extract_lldb_version has the same version type like extract_gdb_version. This is technically a breaking change for rustc-dev users. But note that rustc-dev is a nightly component.

view details

Lzu Tao

commit sha d778f326c385b2df7053b84fb5e3f89361b5fc3a

compiletest: Rewrite extract_gdb_version function

view details

Lzu Tao

commit sha 07d56cba8ffd854f1c8b91bb1372130e5abe6169

Fix panic as passing wrong format to `extract_gdb_version`

view details

Lzu Tao

commit sha 79d5cbbf867a888000b8bbd47194bc57b343b72a

Use Option::as_deref

view details

push time in 11 days

pull request commentrust-lang/rust

Rename HAIR to THIR (Typed HIR).

Judging by the reactions to @nagisa's comment, it seems like most of the compiler team is in favor of this change. I think this can be r+'d after a rebase.

Lezzz

comment created time in 11 days

pull request commentrust-lang/rust

Add a system for creating diffs across multiple mir optimizations.

This is awesome!

@bors r+ rollup=always

oli-obk

comment created time in 11 days

pull request commentrust-lang/rust

Refactor the partitioning module to make it easier to introduce new algorithms

Rebased.

@pnkfelix if you are interested in doing the review, I don't mind waiting for that, otherwise we can find someone else from wg-incr-comp to do the review.

wesleywiser

comment created time in 12 days

issue commentrust-lang/rust

1.46.0-nightly panics on a particular proc macro invocation

Great, thank you!

drahnr

comment created time in 12 days

issue commentrust-lang/rust

1.46.0-nightly panics on a particular proc macro invocation

Hi @apopiak and @drahnr, have either of you had a chance to upgrade to a recently nightly? I just wanted to confirm this is fixed for you.

drahnr

comment created time in 13 days

pull request commentrust-lang/rust

Disable polymorphisation

@bors r+ p=1

Raising the priority because of nightly breakage

davidtwco

comment created time in 13 days

pull request commentrust-lang/rust

Disable polymorphisation

r=me with the test added. We shouldn't roll this up since it will swing perf results again.

@bors rollup=never

davidtwco

comment created time in 13 days

push eventwesleywiser/rust

Caio

commit sha 187aea7c34adf06b0db39f688d60d3fdac8e7e3e

Impl Default for ranges

view details

Alexis Bourget

commit sha 249e07b237bd3049eb7fd94afe450b7c09b6a3d9

Short documentation for the false keyword

view details

Alexis Bourget

commit sha ba6857d801b6217a190e92e43cacd8468ff2d72a

Document the trait keyword

view details

Dan Gohman

commit sha 83bd3d3975bd56e0bd959b5df8129e4ee21aeca3

Add `RawFd` to WASI's `std::os::wasi::prelude`. Add `RawFd` to WASI's `std::os::wasi::prelude`, making it consistent with all other platforms which also have `AsRawFd`, `FromRawFd`, and `IntoRawFd` in their respective preludes.

view details

Caio

commit sha c3756927478afe8d3a880edc469afd766c2f9e82

Remove some Default impls

view details

Yoshua Wuyts

commit sha 18be370342c9b2a93f1d56b2b674bd2fbdcbb019

Add core::ready! macro

view details

Alexis Bourget

commit sha c38230e3b639783483277465ff3c3436a8fd5545

Deny unsafe op in unsafe functions in libstd/alloc.rs

view details

Lzu Tao

commit sha afbfe603fc1c288a0cff63b3b1cad43902a66e9b

Remove combine function Comparing two array directly helps generate better assert message

view details

Josh Stone

commit sha 75748a4116c1d3bbdedd9d2f9c1cf95d9f4d9df7

ci: Update dist-{i686,x86_64}-linux to Debian 6 This increases the minimum `{i686,x86_64}-unknown-linux-gnu` platform from RHEL/CentOS 5 (glibc 2.5 and kernel 2.6.18) to a slightly newer Debian 6 `squeeze` (glibc 2.11 and kernel 2.6.32). While that release is already EOL, it happens to match the minimum common versions of two enterprise distros that do still need Rust support -- RHEL 6 (glibc 2.12 and kernel 2.6.32) and SLES 11 SP4 (glibc 2.11 and kernel 3.0).

view details

Lokathor

commit sha 48ec236c8c7c5a32077c465eb254646a9860f802

start GBA file.

view details

Aleksey Kladov

commit sha cac1768b03c8d6673c51605dca03997876979d68

First cut of `std::lazy` module

view details

Ashley Mannix

commit sha 237a97760ad79a21ce0655b9f5adc0cc5b5cbc79

integrate Lazy into std layout This commit refactors the initial implementation to fit into std and makes some other changes: - use MaybeUninit internally in SyncOnceCell - correctly impl Drop for lazy::Once - port Lazy::take from once_cell from: https://github.com/matklad/once_cell/pull/100 Co-Authored-By: Paul Dicker <pitdicker@users.noreply.github.com>

view details

Ashley Mannix

commit sha d1263f5e66d31ad170c524a70aa5f21e08474326

use set() in SyncOnceCell::from

view details

Ashley Mannix

commit sha d1017940d77f35f841008c3e108e3da5e48a592f

remove inlined lazy::Waiter in favor of sync::Once

view details

Ashley Mannix

commit sha 1f1cda65d9a5c88855d3fbcb3912095474e557de

appease tidy

view details

Alexis Bourget

commit sha 8a2f147b5b9756e67dc2299777b8b534bbd73d0b

Fix small nits, clarfying some confusing vocabulary and using more consistent wording

view details

Lokathor

commit sha e190bdf710101d8fdf12195dcc73749719a57e72

fill in all those options.

view details

Kristofer Rye

commit sha ab23a2a9c54fed2acbd553407a761f19af6e8ed4

ci: Set `shell: bash` as a default, remove duplicates A follow-up to #74406, this commit merely removes the `shell: bash` lines where they are explicitly added in favor of setting defaults for *all* "run" steps. Signed-off-by: Kristofer Rye <kristofer.rye@gmail.com>

view details

Lokathor

commit sha 9c4ac7395953435a5f39cfaf93c7679df068bade

Docs clarifications.

view details

Lokathor

commit sha 72fa7f82503d4eb3c09e5dce600ac044c2835688

Add to supported_targets list.

view details

push time in 13 days

pull request commentrust-lang/rust

[mir-opt] Allow debuginfo to be generated for a constant or a Place

Looks like a networking issue:

error: failed to get `cc` as a dependency of package `bootstrap v0.0.0 (/checkout/src/bootstrap)`

Caused by:
  failed to fetch `https://github.com/rust-lang/crates.io-index`

Caused by:
  error inflating zlib stream; class=Zlib (5)
failed to run: /checkout/obj/build/i686-unknown-linux-gnu/stage0/bin/cargo build --manifest-path /checkout/src/bootstrap/Cargo.toml --locked
Build completed unsuccessfully in 0:00:35
make: *** [prepare] Error 1
Makefile:60: recipe for target 'prepare' failed

@bors retry

wesleywiser

comment created time in 13 days

pull request commentrust-lang/rust

[mir-opt] Allow debuginfo to be generated for a constant or a Place

They didn't actually disappear, they just got renamed because their names are now only part of debuginfo which that test doesn't generate.

wesleywiser

comment created time in 14 days

push eventwesleywiser/rust

Wesley Wiser

commit sha a1327f736d8402a007bfcef26f570a59a25ffa1b

[mir-opt] Allow debuginfo to be generated for a constant or a Place Prior to this commit, debuginfo was always generated by mapping a name to a Place. This has the side-effect that `SimplifyLocals` cannot remove locals that are only used for debuginfo because their other uses have been const-propagated. To allow these locals to be removed, we now allow debuginfo to point to a constant value. The `ConstProp` pass detects when debuginfo points to a local with a known constant value and replaces it with the value. This allows the later `SimplifyLocals` pass to remove the local.

view details

push time in 14 days

Pull request review commentrust-lang/measureme

Add named "additional data" support

 use crate::{Profiler, SerializationSink, StringComponent, StringId}; -/// Event IDs are strings conforming to the following grammar:+/// Event IDs are strings conforming to the following (eBNF) grammar: /// /// ```ignore ///   <event_id> = <label> {<argument>} ///   <label> = <text>-///   <argument> = '\x1E' <text>+///   <argument> = ['\x1D' <argument_name>] '\x1E' <argument_value>+///   <argument_name> = <text>+///   <argument_value> = <text>

I wonder if it would be simpler to make the grammar:

<argument> = '\x1E' (<argument_name_value_pair> | <argument_value>)
<argument_name_value_pair> = <text> '\x1D' <text>
<argument_value> = <text>

Then we could always parse the leading \x1E and then do a string split on the \x1D if it exists.

nagisa

comment created time in 14 days

Pull request review commentrust-lang/measureme

Add named "additional data" support

 use crate::{Profiler, SerializationSink, StringComponent, StringId}; -/// Event IDs are strings conforming to the following grammar:+/// Event IDs are strings conforming to the following (eBNF) grammar: /// /// ```ignore ///   <event_id> = <label> {<argument>} ///   <label> = <text>-///   <argument> = '\x1E' <text>+///   <argument> = ['\x1D' <argument_name>] '\x1E' <argument_value>+///   <argument_name> = <text>+///   <argument_value> = <text>

I think that would also make the format compatible with the current format. It's fine if we need to break that but we'll have to bump the format number and coordinate redeploying new versions on perf.rlo.

nagisa

comment created time in 14 days

pull request commentrust-lang/rust

Generating the coverage map

@eggyal Thanks for the repro! This feature is still very much "in progress" so lots of stuff doesn't work correctly. Even still, I think it would be helpful to open bug reports as you find things so that we can track what issues have been resolved and which are still open.

richkadel

comment created time in 14 days

push eventwesleywiser/rust

Wesley Wiser

commit sha b13ea34b2617d47a0b4f9bca187d1c29443e8fda

[mir-opt] Allow debuginfo to be generated for a constant or a Place Prior to this commit, debuginfo was always generated by mapping a name to a Place. This has the side-effect that `SimplifyLocals` cannot remove locals that are only used for debuginfo because their other uses have been const-propagated. To allow these locals to be removed, we now allow debuginfo to point to a constant value. The `ConstProp` pass detects when debuginfo points to a local with a known constant value and replaces it with the value. This allows the later `SimplifyLocals` pass to remove the local.

view details

push time in 15 days

Pull request review commentrust-lang/rust

[mir-opt] Allow debuginfo to be generated for a constant or a Place

 pub fn change_mutability_of_slot() {  #[cfg(not(cfail1))] #[rustc_clean(cfg="cfail2",-    except="hir_owner_nodes,typeck,optimized_mir")]

Yep, that's exactly it!

wesleywiser

comment created time in 15 days

delete branch SwiftSoftware-Inc/react-datetime-swift

delete branch : dependabot/npm_and_yarn/lodash-4.17.19

delete time in 15 days

push eventSwiftSoftware-Inc/react-datetime-swift

dependabot[bot]

commit sha da785f9a310ebbb79e9a4caea98a6bfa2d64cacd

Bump lodash from 4.17.15 to 4.17.19 Bumps [lodash](https://github.com/lodash/lodash) from 4.17.15 to 4.17.19. - [Release notes](https://github.com/lodash/lodash/releases) - [Commits](https://github.com/lodash/lodash/compare/4.17.15...4.17.19) Signed-off-by: dependabot[bot] <support@github.com>

view details

push time in 15 days

PR merged SwiftSoftware-Inc/react-datetime-swift

Bump lodash from 4.17.15 to 4.17.19 dependencies

Bumps lodash from 4.17.15 to 4.17.19. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/lodash/lodash/releases">lodash's releases</a>.</em></p> <blockquote> <h2>4.17.16</h2> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/lodash/lodash/commit/d7fbc52ee0466a6d248f047b5d5c3e6d1e099056"><code>d7fbc52</code></a> Bump to v4.17.19</li> <li><a href="https://github.com/lodash/lodash/commit/2e1c0f22f425e9c013815b2cd7c2ebd51f49a8d6"><code>2e1c0f2</code></a> Add npm-package</li> <li><a href="https://github.com/lodash/lodash/commit/1b6c282299f4e0271f932b466c67f0f822aa308e"><code>1b6c282</code></a> Bump to v4.17.18</li> <li><a href="https://github.com/lodash/lodash/commit/a370ac81408de2da77a82b3c4b61a01a3b9c2fac"><code>a370ac8</code></a> Bump to v4.17.17</li> <li><a href="https://github.com/lodash/lodash/commit/1144918f3578a84fcc4986da9b806e63a6175cbb"><code>1144918</code></a> Rebuild lodash and docs</li> <li><a href="https://github.com/lodash/lodash/commit/3a3b0fd339c2109563f7e8167dc95265ed82ef3e"><code>3a3b0fd</code></a> Bump to v4.17.16</li> <li><a href="https://github.com/lodash/lodash/commit/c84fe82760fb2d3e03a63379b297a1cc1a2fce12"><code>c84fe82</code></a> fix(zipObjectDeep): prototype pollution (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4759">#4759</a>)</li> <li><a href="https://github.com/lodash/lodash/commit/e7b28ea6cb17b4ca021e7c9d66218c8c89782f32"><code>e7b28ea</code></a> Sanitize sourceURL so it cannot affect evaled code (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4518">#4518</a>)</li> <li><a href="https://github.com/lodash/lodash/commit/0cec225778d4ac26c2bac95031ecc92a94f08bbb"><code>0cec225</code></a> Fix lodash.isEqual for circular references (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4320">#4320</a>) (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4515">#4515</a>)</li> <li><a href="https://github.com/lodash/lodash/commit/94c3a8133cb4fcdb50db72b4fd14dd884b195cd5"><code>94c3a81</code></a> Document matches* shorthands for over* methods (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4510">#4510</a>) (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4514">#4514</a>)</li> <li>Additional commits viewable in <a href="https://github.com/lodash/lodash/compare/4.17.15...4.17.19">compare view</a></li> </ul> </details> <details> <summary>Maintainer changes</summary> <p>This version was pushed to npm by <a href="https://www.npmjs.com/~mathias">mathias</a>, a new releaser for lodash since your current version.</p> </details> <br />

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
  • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
  • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
  • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

+3 -9

0 comment

1 changed file

dependabot[bot]

pr closed time in 15 days

Pull request review commentrust-lang/rust

[mir-opt] Allow debuginfo to be generated for a constant or a Place

 impl<'mir, 'tcx> MutVisitor<'tcx> for ConstPropagator<'mir, 'tcx> {             if let Ok(place_layout) = self.tcx.layout_of(self.param_env.and(place_ty)) {                 let can_const_prop = self.can_const_prop[place.local];                 if let Some(()) = self.const_prop(rval, place_layout, source_info, place) {-                    // This will return None if the above `const_prop` invocation only "wrote" a-                    // type whose creation requires no write. E.g. a generator whose initial state-                    // consists solely of uninitialized memory (so it doesn't capture any locals).-                    if let Some(value) = self.get_const(place) {-                        if self.should_const_prop(value) {-                            trace!("replacing {:?} with {:?}", rval, value);-                            self.replace_with_const(rval, value, source_info);-                            if can_const_prop == ConstPropMode::FullConstProp-                                || can_const_prop == ConstPropMode::OnlyInsideOwnBlock-                            {-                                trace!("propagated into {:?}", place);+                    if can_const_prop != ConstPropMode::NoPropagation {+                        // This will return None for variables that are from other blocks,+                        // so it should be okay to propagate from here on down.+                        if let Some(value) = self.get_const(place) {+                            if self.should_const_prop(value) {+                                trace!("replacing {:?} with {:?}", rval, value);+                                self.replace_with_const(rval, value, statement.source_info);+                                if can_const_prop == ConstPropMode::FullConstProp+                                    || can_const_prop == ConstPropMode::OnlyInsideOwnBlock+                                {+                                    trace!("propagated into {:?}", place);++                                    if place.projection.is_empty()+                                        && !self.has_mutation.contains(place.local)+                                    {+                                        self.fully_propagated_locals[place.local] = Some(value);

Another alternative is to make it a separate mir optimization

I did this and I like the result a lot better.

wesleywiser

comment created time in 16 days

Pull request review commentrust-lang/rust

[mir-opt] Allow debuginfo to be generated for a constant or a Place

+//! Finds locals which are assigned once to a const and unused except for debuginfo and converts+//! their debuginfo to use the const directly, allowing the local to be removed.++use rustc_middle::{ty::{Const, TyCtxt}, mir::{Location, visit::{PlaceContext, Visitor}, Local, Body, StatementKind, Rvalue, Operand, VarDebugInfoContents}};

RA likes to do this and I don't actually mind it when it's properly formatted.

wesleywiser

comment created time in 16 days

push eventwesleywiser/rust

Mohsen Zohrevandi

commit sha c4b02659c16d2ad0ac36d2c8602edd002e559f7a

Enable some timeouts in SGX platform This would partially resolve https://github.com/fortanix/rust-sgx/issues/31

view details

Mohsen Zohrevandi

commit sha d7dc64bdfea4fbf8974774800ab51e04eaa4f082

Handle spurious wakeups in wait_timeout_sgx

view details

Mohsen Zohrevandi

commit sha c5d1fcd2309b6903fed82aba6e0fdc2fa85bc874

Allow more ui tests for SGX

view details

Teddy_Wang

commit sha 40ee620e51c86c72e3c2b65df71f5f0a4a79797f

Added a lint for .map(|x| x)

view details

Mohsen Zohrevandi

commit sha 3442d23c1a12f1f01a0e07b6bec72b58998f49ef

Improve wait_timeout_sgx, simplify usercalls::wait

view details

CAD97

commit sha 7779a11448927e208ed6eb9bb609dd23595f77ce

Use step_unchecked more liberally

view details

flip1995

commit sha 80bcbf521c7ff95e38a7567432b5519cc18e5b2a

Merge commit 'c2c07fa9d095931eb5684a42942a7b573a0c5238' into clippyup

view details

Teddy_Wang

commit sha fb4f9a0ad7a4656beb01c85b02b3e6ef15d914ec

Fix pattern match of ExprKind::MethodCall

view details

bors

commit sha 583d64493484f72425ecac55eaf5eddbba10b132

Auto merge of #5694 - wangtheo:issue-5626, r=matthiaskrgr #5626: lint iterator.map(|x| x) changelog: adds a new lint for iterator.map(|x| x) (see https://github.com/rust-lang/rust-clippy/issues/5626) The code also lints for result.map(|x| x) and option.map(|x| x). Also, I'm not sure if I'm checking for type adjustments correctly and I can't think of an example where .map(|x| x) would apply type adjustments.

view details

Ayaz Hafiz

commit sha 7c1b3aa0ddb81954a804455ca45fcf09fdb17dd8

Record span of `const` kw in GenericParamKind Context: this is needed to fix https://github.com/rust-lang/rustfmt/issues/4263, which currently records the span of a const generic param incorrectly because the location of the `const` kw is not known. I am not sure how to add tests for this; any guidance in how to do so would be appreciated :slightly_smiling_face:

view details

Eduardo Broto

commit sha 5987c7d4041ce5d72c8412d2ad73fe3b63308b51

cmp_owned: avoid FP when PartialEq is not implemented symmetrically

view details

Eduardo Broto

commit sha b498e1d71537a79e7aff5378da625aca8b4eef96

cmp_owned: reverse operands if necessary

view details

Tim Nielens

commit sha 6bf5434e19ce6d2a501589d1fcbc0d1748c531a6

copy_on_clone - add machine applicability

view details

bors

commit sha a14eab389f6e9f8bdaffbba184b20220041b036f

Auto merge of #5745 - montrivo:copy_on_clone, r=phansch clone_on_copy - add machine applicability Fix #4826. Change the applicability of the lint clone_on_copy. Split a test file and run rustfix on the clone_on_copy part. changelog: clone_on_copy - add machine applicability

view details

bors

commit sha 46d33043d5de0403a2a3dab9e7817041999bf9dd

Auto merge of #5701 - ebroto:4874_cmp_owned_fp, r=flip1995 cmp_owned: handle when PartialEq is not implemented symmetrically changelog: Handle asymmetrical implementations of PartialEq in [`cmp_owned`]. Fixes #4874

view details

Alexis Bourget

commit sha 249e07b237bd3049eb7fd94afe450b7c09b6a3d9

Short documentation for the false keyword

view details

Guillaume Gomez

commit sha 3e48aaea03aef6e6e7ac678d11995a2a39ba9d99

Clean up E0704 error explanation

view details

Carol (Nichols || Goulding)

commit sha fa0f1d3e5353df04e3d2e68e65810ca1a231c220

Change a noun to a verb to make the sentence complete

view details

bors

commit sha 88fec89c16312de60ca7ab6d660b1ae8917b35f8

Auto merge of #5748 - carols10cents:tiny-docs-fix, r=flip1995 Change a noun to a verb to make the sentence complete changelog: Fixed some grammar in the documentation for `await_holding_lock`. Just a tiny little thing I found while using clippy <3

view details

Eduard-Mihai Burtescu

commit sha f5ce0e5fe960d09db01cf912c475cd1a52131120

rustc_lint: only query `typeck_tables_of` when a lint needs it.

view details

push time in 16 days

Pull request review commentrust-lang/rust

[mir-opt] Allow debuginfo to be generated for a constant or a Place

 fn try_identity(_1: std::result::Result<u32, i32>) -> std::result::Result<u32, i32> {     debug x => _1;                       // in scope 0 at $DIR/simplify_try.rs:5:17: 5:18     let mut _0: std::result::Result<u32, i32>; // return place in scope 0 at $DIR/simplify_try.rs:5:41: 5:57+    let _2: u32;                         // in scope 0 at $DIR/simplify_try.rs:6:9: 6:10

The SimplifyTry pass changes didn't work right.

wesleywiser

comment created time in 16 days

Pull request review commentrust-lang/rust

[mir-opt] Allow debuginfo to be generated for a constant or a Place

 impl<'tcx> MirPass<'tcx> for SimplifyArmIdentity {                 // Fix the debug info to point to the right local                 for dbg_index in opt_info.dbg_info_to_adjust {                     let dbg_info = &mut debug_info[dbg_index];-                    assert!(dbg_info.place.projection.is_empty());-                    dbg_info.place.local = opt_info.local_0;-                    dbg_info.place.projection = opt_info.dbg_projection;+                    assert!(+                        matches!(dbg_info.value, VarDebugInfoContents::Place(_)),+                        "value was not a Place"+                    );+                    if let VarDebugInfoContents::Place(mut p) = dbg_info.value {

Ouch, this doesn't do what you think. Since VarDebugInfoContents is Copy, this creates a new copy and mutates it. This should be

                    if let VarDebugInfoContents::Place(p) = &mut dbg_info.value {
wesleywiser

comment created time in 16 days

push eventwesleywiser/rust

Yoshua Wuyts

commit sha a31f103fd27bde3f83b9dd54af8e41d64e5001f4

Add core::future::{poll_fn, PollFn}

view details

Chris Denton

commit sha 912963bd0856239828253af8d04e4f62e75cafd7

Remove legacy InnoSetup GUI installer On Windows the InnoSetup installer was superseded by the MSI installer. It's no longer needed.

view details

djugei

commit sha b4337ab8c387658b7012fa242e429f46c5f31141

added .collect() into String from Box<str> with fake feature/stability annotation

view details

Tomasz Miąsko

commit sha 291dce91b24d70382ebf1116fa836fd91960de84

Fallback to xml.etree.ElementTree The xml.etree.cElementTree has been deprecated since Python 3.3 and removed in Python 3.9 https://bugs.python.org/issue36543.

view details

Alexis Bourget

commit sha 049f6eaa792fbbf2b727fc278ddd23d1e11d57bd

Fixing broken link for the Eq trait

view details

Caleb Zulawski

commit sha 144206e6d8c1ab4ffdbaf6d7b0f5a4201c0f2da4

Don't implement Fn* traits for #[target_feature] functions

view details

Caleb Zulawski

commit sha c98b4c8fdde7812d7af5a060a1e22fd7e3775d3f

Add error note when trying fn as Fn trait

view details

mark

commit sha 3f6928f1f6eff367e6ddbfb63ebc5e568ffe0eb1

move contributing.md to rustc-dev-guide and point at getting started

view details

Alexis Bourget

commit sha 6e8251742071d56545b6ce160ed71bb60597ee01

Documenting the separate behaviors of edition 2015 and 2018

view details

Alexis Bourget

commit sha 59701360dc0c76bfa45204d307ac5055f8bff538

Fix some small mistakes

view details

David Hewitt

commit sha 6b95f3102d657a5cd0549213a073b28c7e0fe609

Add `format_args_capture` feature

view details

MaulingMonkey

commit sha f8eb81ba4e85b02d90cfc33fcba0a6a7d5cbf810

Modify type names on MSVC to make tuples .natvis compatible. - Mangles (T0, T1) as tuple<T0, T1>, possibly unblocking rust-lang/rust#70052 "Update hashbrown to 0.8.0" - Prettifies Rust tuples similar to VS2017's std::tuple - Improves debuginfo test coverage

view details

MaulingMonkey

commit sha 24a728a8eb4832568509eb757c2374934a76cb98

debuginfo: Define int/float types in terms of MSVC-recognized types. PDB debug information doesn't appear to be emitted for basic types. By defining u32 as a typedef for unsigned __int32 when targeting MSVC, we allow CDB and other debuggers to recognize "u32" as a type/expression. This in turn unblocks rust-lang#70052 "Update hashbrown to 0.8.0" by allowing $T1 ..= $T3 to resolve, which would otherwise fail to resolve when builtin types fail to parse.

view details

Simonas Kazlauskas

commit sha df88972f8ce9ddbebec6d551810f7127fe25d2a3

Update psm version This new version includes a fix for building on aarch64 windows.

view details

Ivan Tham

commit sha f772587aba7b2be9a2fa708a26ba2605e32148ff

Add unstable docs for rustc_attrs

view details

Vadim Petrochenkov

commit sha 79a42e37084d0fc584c9f312c2a355104a113889

linker: Create GNU_EH_FRAME header by default when producing ELFs

view details

Aaron Hill

commit sha 765bd47fa0f0e0d5d893283a94c76e2b1009d680

Recover extra trailing angle brackets in struct definition This commit applies the existing 'extra angle bracket recovery' logic when parsing fields in struct definitions. This allows us to continue parsing the struct's fields, avoiding spurious 'missing field' errors in code that tries to use the struct.

view details

Ivan Tham

commit sha 725918f17e9a2c1e8a0ffec658d1363681f768bd

Update src/doc/unstable-book/src/language-features/rustc-attrs.md Co-authored-by: Ralf Jung <post@ralfj.de>

view details

David Hewitt

commit sha 8caf60407033e84592821a3f7b3917fe80d343e0

Improve messaging from PR feedback

view details

Caleb Zulawski

commit sha 8e899b1cbe6209842e112f0b7ec450a3cdfdb36d

Don't implement Fn* for unsafe #[target_feature] functions

view details

push time in 16 days

pull request commentrust-lang/rust

Generating the coverage map

@bors retry

richkadel

comment created time in 17 days

pull request commentrust-lang/rust

Generating the coverage map

Intermittent timeouts are relatively common so it's probably just that. I'm not at a computer to verify but we can give it another try on the assumption that's the issue.

@bors rety

richkadel

comment created time in 17 days

push eventwesleywiser/rust

Mohsen Zohrevandi

commit sha c4b02659c16d2ad0ac36d2c8602edd002e559f7a

Enable some timeouts in SGX platform This would partially resolve https://github.com/fortanix/rust-sgx/issues/31

view details

Mohsen Zohrevandi

commit sha d7dc64bdfea4fbf8974774800ab51e04eaa4f082

Handle spurious wakeups in wait_timeout_sgx

view details

Mohsen Zohrevandi

commit sha c5d1fcd2309b6903fed82aba6e0fdc2fa85bc874

Allow more ui tests for SGX

view details

Teddy_Wang

commit sha 40ee620e51c86c72e3c2b65df71f5f0a4a79797f

Added a lint for .map(|x| x)

view details

Mohsen Zohrevandi

commit sha 3442d23c1a12f1f01a0e07b6bec72b58998f49ef

Improve wait_timeout_sgx, simplify usercalls::wait

view details

CAD97

commit sha 7779a11448927e208ed6eb9bb609dd23595f77ce

Use step_unchecked more liberally

view details

flip1995

commit sha 80bcbf521c7ff95e38a7567432b5519cc18e5b2a

Merge commit 'c2c07fa9d095931eb5684a42942a7b573a0c5238' into clippyup

view details

Teddy_Wang

commit sha fb4f9a0ad7a4656beb01c85b02b3e6ef15d914ec

Fix pattern match of ExprKind::MethodCall

view details

bors

commit sha 583d64493484f72425ecac55eaf5eddbba10b132

Auto merge of #5694 - wangtheo:issue-5626, r=matthiaskrgr #5626: lint iterator.map(|x| x) changelog: adds a new lint for iterator.map(|x| x) (see https://github.com/rust-lang/rust-clippy/issues/5626) The code also lints for result.map(|x| x) and option.map(|x| x). Also, I'm not sure if I'm checking for type adjustments correctly and I can't think of an example where .map(|x| x) would apply type adjustments.

view details

Ayaz Hafiz

commit sha 7c1b3aa0ddb81954a804455ca45fcf09fdb17dd8

Record span of `const` kw in GenericParamKind Context: this is needed to fix https://github.com/rust-lang/rustfmt/issues/4263, which currently records the span of a const generic param incorrectly because the location of the `const` kw is not known. I am not sure how to add tests for this; any guidance in how to do so would be appreciated :slightly_smiling_face:

view details

Eduardo Broto

commit sha 5987c7d4041ce5d72c8412d2ad73fe3b63308b51

cmp_owned: avoid FP when PartialEq is not implemented symmetrically

view details

Eduardo Broto

commit sha b498e1d71537a79e7aff5378da625aca8b4eef96

cmp_owned: reverse operands if necessary

view details

Tim Nielens

commit sha 6bf5434e19ce6d2a501589d1fcbc0d1748c531a6

copy_on_clone - add machine applicability

view details

bors

commit sha a14eab389f6e9f8bdaffbba184b20220041b036f

Auto merge of #5745 - montrivo:copy_on_clone, r=phansch clone_on_copy - add machine applicability Fix #4826. Change the applicability of the lint clone_on_copy. Split a test file and run rustfix on the clone_on_copy part. changelog: clone_on_copy - add machine applicability

view details

bors

commit sha 46d33043d5de0403a2a3dab9e7817041999bf9dd

Auto merge of #5701 - ebroto:4874_cmp_owned_fp, r=flip1995 cmp_owned: handle when PartialEq is not implemented symmetrically changelog: Handle asymmetrical implementations of PartialEq in [`cmp_owned`]. Fixes #4874

view details

Guillaume Gomez

commit sha 3e48aaea03aef6e6e7ac678d11995a2a39ba9d99

Clean up E0704 error explanation

view details

Carol (Nichols || Goulding)

commit sha fa0f1d3e5353df04e3d2e68e65810ca1a231c220

Change a noun to a verb to make the sentence complete

view details

bors

commit sha 88fec89c16312de60ca7ab6d660b1ae8917b35f8

Auto merge of #5748 - carols10cents:tiny-docs-fix, r=flip1995 Change a noun to a verb to make the sentence complete changelog: Fixed some grammar in the documentation for `await_holding_lock`. Just a tiny little thing I found while using clippy <3

view details

Eduard-Mihai Burtescu

commit sha f5ce0e5fe960d09db01cf912c475cd1a52131120

rustc_lint: only query `typeck_tables_of` when a lint needs it.

view details

Manish Goregaokar

commit sha a671ea4d3f9d416d9520d2ea902cb9f48eb35898

Rollup merge of #73597 - ayazhafiz:i/const-span, r=ecstatic-morse Record span of `const` kw in GenericParamKind Context: this is needed for a fix of https://github.com/rust-lang/rustfmt/issues/4263, which currently records the span of a const generic param incorrectly because the location of the `const` kw is not known. I am not sure how to add tests for this; any guidance in how to do so would be appreciated :slightly_smiling_face:

view details

push time in 17 days

pull request commentrust-lang/rust

Generating the coverage map

@bors retry

richkadel

comment created time in 17 days

issue commentrust-lang/rust

Exponential growth in compile time, memory usage for obligation evaluation

@rustbot ping icebreakers-cleanup-crew

Help creating a smaller MCVE would be appreciated!

syntacticsugarglider

comment created time in 18 days

pull request commentrust-lang/rust

Generating the coverage map

But yeah, if we run into more merge conflicts, I don't have an issue bumping the priority.

richkadel

comment created time in 18 days

pull request commentrust-lang/rust

Generating the coverage map

@richkadel There's been some changes recently to the ordering of PRs in the build queue so rollup=never PRs are automatically weighted higher than regular PRs (unless those PRs have p=1). At least based on the current build queue, I think this PR will land at about position 3 in the list.

richkadel

comment created time in 18 days

Pull request review commentrust-lang/rfcs

RFC: Promote aarch64-unknown-linux-gnu to a Tier-1 Rust target

+- Feature Name: `promote-aarch64-unknown-linux-gnu-to-tier-1`+- Start Date: 2020-07-17+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++Promote the Arm aarch64-unknown-linux-gnu Rust target to Tier-1.++# Motivation+[motivation]: #motivation++Arch64-unknown-linux-gnu is [currently a Tier-2 Rust target](https://forge.rust-lang.org/release/platform-support.html#tier-2), in accordance with the target tier policy articulated [here](https://rust-lang.github.io/compiler-team/minutes/design-meeting/2019-09-20-target-tier-policy/).++In the last 2 quarters, very good progress has been made in understanding and filling the gaps that remain in the path to attaining Tier-1 status for this target.++As a direct result, those gaps have either already been filled or are very close to being filled.++As such, this RFC aims to:++- Evidence what has been done.++- On the basis of that evidence propose that the proceeedings to promote the aarch64-unknown-linux-gnu target to the Tier-1 category may please be kickstarted.++- Culminate in the actual promotion of the aarch64-unknown-linux-gnu target to Tier-1, including any and all of the relevant processes and actions as appropriate.++Please note that the narrative here doesn't always match the RFC template so some liberties may have been taken in the expression.++Please also note, by way of wilful disclosure, that this RFC's author is an employee of Arm.++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++1. **In essence, the target tier policy for a Tier-1 target aims to obtain the following technical and tangible assurances:**++   a. The Rust compiler and compiler tests must all build and pass reliably for the target in question.++   b. All necessary supporting infrastructure, including dedicated hardware, to build and run the Rust compiler and compiler tests reliably must be available openly.++   c. There must exist a robust and convenient CI integration for the target in question.++2. **In addition, the target tier policy for a Tier-1 target aims to obtain the following stategic assurances:**++   a. The long term viability of the existence of a target specific ecosystem should be clear.++   b. The long term viability of supporting the target should be clear.++   c. The target must have substantial and widespread interest within the Rust developer community.++   d. The target must serve the interests of multiple production users of Rust across multiple organizations or projects.++3. **Finally, the target tier policy for a Tier-1 target aims to obtain the following approvals:**++   a. An approval from the Compiler Team that Tier-1 target requirements have been met.++   b. An approval from the Infrastructure Team that the target in question may be integrated into CI.++   c. An approval from the Release Team that supporting the target in question is viable in the long term.++The following section details how points 1 and 2 of the above assurances have either already been met or are close to being met. ++Items in point 3 are addressed in the section titled [Unresolved Questions](#Unresolved-questions). That is not to say that they are unresolved per se but more that they are proposed next steps.++# Reference-level explanation+[reference-level-explanation]: #reference-level-explanation++**1.a. The Rust compiler and compiler tests must all build and pass reliably for the target in question.**++ - As of today, all tests pass reliably barring one test. + + - A fix addressing the failing test [has been posted for review.](https://github.com/rust-lang/rust/pull/73655)++    The failure will likely be addressed very shortly.++ - In addition, as a result of inputs from the core team, engineers from Arm performed an audit of all tests that are currently marked **'only-x86_64'** and **'only-aarch64'** has been done. This was to ascertain whether past viewpoints and/or decisions that led to those markings are still valid. +     - The audit report is available [here.](https://docs.google.com/spreadsheets/d/1B-Jg1Ml6nAF6Tf9wJGTgqkFUNeJEejC3aMikGl6vXlc/edit?usp=sharing)++     - Work is being planned under the guidance of core team members to upstream patches that came out of the audit as well as to address any open questions that came about.++**1.b. All necessary supporting infrastructure, including dedicated hardware, to build and run the Rust compiler and compiler tests reliably must be available openly.**++ - Two quarters ago, Arm donated a [Packet c2.large.arm system](https://www.packet.com/cloud/servers/c2-large-arm/) to the core team.++ - It is noteworthy that the core team have done a brilliant job in integrating this system into Rust's CI infrastructure while also circumventing myriad Github Actions security problems that popped up.++ - Over time, Arm intends to further donate newer and more capable hardware to this initiative.++**1.c. There must exist a robust and convenient CI integration for the target in question.**++ - The happy outcome of the core team's work with the donated system is that the system integrates largely seamlessly with existing Rust CI infrastructure. ++ - The integration has been verified to produce green runs once patches from the two outstanding PRs are in place.++**2.a. The long term viability of the existence of a target specific ecosystem should be clear.**++ - It is hard to concretely quantify this aspect.++ - That said, Arm AArch64 silicon is either already prevalent or is en-route to prevalance in a wide spectrum of application domains ranging from 'traditional' embedded systems at one end of the spectrum, on to mobile phones, clam-shell devices, desktops, vehicle autonomy controllers, datacenter servers etc all the way to high performance super-computers.++ - The evidence to that effect is too numerous to quote but generally easy to verify openly. ++ - It is fair to state that this is an ongoing reality which is unlikely to stop trending upwards and sidewards for the forseeable future.++ - Software stacks built for those domains predominantly use an AArch64 Linux kernel build.++ - Rust presents an attractive value proposition across all such domains, irrespective of the underlying processor architecture.++ - **As such, the Rust aarch64-unknown-linux-gnu target's ecosystem presents very strong viability for the long term.**++**2.b. The long term viability of supporting the target should be clear.**++ - It is hard to concretely quantify this aspect.++ - It is worth calling out, in the same vein as the previous point, that given the increasing prevalance of AArch64 silicon deployments and given Rust's general value proposition, **supporting the Rust aarch64-unknown-linux-gnu target presents very strong viability for the long term.**++**2.c. The target must have substantial and widespread interest within the Rust developer community.**++ - It is hard to concretely quantify this aspect.++ - It is generally fair to state that **there is already substantial and widespread interest for the aarch64-unknown-linux-gnu target in the Rust developer commmunity**.++ - It is also generally fair to state that there is a clear upward trend in the use of AArch64 systems as self hosted development environments. ++ - Most major operating system environments support hosted development on AArch64 based systems and this trend is increasing.++ - As a somewhat related note: Slow but steady progress is being made to support Windows AArch64 targets, initially for cross-platform development. This shall inevitably trend towards hosted development.++ - As such, **it is very likely that developer interest in Rust on aarch64-unknown-linux-gnu will continue to increase in the medium to long term.**++**2.d. The target must serve the interests of multiple production users of Rust across multiple organizations or projects.**++ - It is hard to concretely quantify this aspect.++ - Most major Arm software ecosystem partners are either already using Rust extensively, or are building up to extensive use. A few publically known examples are Microsoft and Google. There are many more.++ - Arm itself recognises Rust as an important component to consider in a broader horizontal safety and security foundation across multiple processor portfolios. ++ - Arm has dedicated a small team to help improve Rust for the aarch64-unknown-linux-gnu target.++ - **It is very likely that support for aarch64-unknown-linux-gnu in these organisations will trend upwards commensurate with the increasing prevalence of AArch64 silicon based systems.**++Points 3.a through 3.c from the [Guide-level explanation](#Guide-level-explanation) section above are addressed in the [Unresolved questions](#unresolved-questions) section below.++# Drawbacks+[drawbacks]: #drawbacks++**There is no drawback envisioned in promoting the Rust aarch64-unknown-linux-gnu to Tier-1.**

Another possibility would be to use a cloud based aarch64 system like the one linked to in the RFC (Packet c2-large-arm) which seems reasonably priced in comparison to x86_64 options.

raw-bin

comment created time in 18 days

pull request commentrust-lang/rust

Generating the coverage map

Looks like there's a CI failure.

richkadel

comment created time in 18 days

pull request commentrust-lang/rust

Polymorphization

I was able to reproduce the error by pulling and then running ./x.py test:

<details>

error: internal compiler error: src/librustc_codegen_llvm/context.rs:854:17: failed to get layout for `rustc_infer::infer::nll_relate::TypeRelating<D>`: the type `D` has an unknown layout

thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:916:9
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /home/wesley/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86
   1: backtrace::backtrace::trace_unsynchronized
             at /home/wesley/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:78
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:59
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1076
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1537
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:62
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:49
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:198
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:217
  10: <alloc::boxed::Box<F> as core::ops::function::Fn<A>>::call
             at ./src/liballoc/boxed.rs:1095
  11: rustc_driver::report_ice
             at src/librustc_driver/lib.rs:1159
  12: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:530
  13: std::panicking::begin_panic
             at ./src/libstd/panicking.rs:456
  14: rustc_errors::HandlerInner::bug
             at src/librustc_errors/lib.rs:916
  15: rustc_errors::Handler::bug
             at src/librustc_errors/lib.rs:666
  16: rustc_middle::util::bug::opt_span_bug_fmt::{{closure}}
             at src/librustc_middle/util/bug.rs:33
  17: rustc_middle::ty::context::tls::with_opt::{{closure}}
             at src/librustc_middle/ty/context.rs:1830
  18: rustc_middle::ty::context::tls::with_context_opt
             at src/librustc_middle/ty/context.rs:1782
  19: rustc_middle::ty::context::tls::with_opt
             at src/librustc_middle/ty/context.rs:1830
  20: rustc_middle::util::bug::opt_span_bug_fmt
             at src/librustc_middle/util/bug.rs:29
  21: rustc_middle::util::bug::bug_fmt
             at src/librustc_middle/util/bug.rs:14
  22: <rustc_codegen_llvm::context::CodegenCx as rustc_target::abi::LayoutOf>::spanned_layout_of::{{closure}}
             at src/librustc_codegen_llvm/context.rs:854
  23: core::result::Result<T,E>::unwrap_or_else
             at ./src/libcore/result.rs:853
  24: <rustc_codegen_llvm::context::CodegenCx as rustc_target::abi::LayoutOf>::spanned_layout_of
             at src/librustc_codegen_llvm/context.rs:850
  25: <rustc_codegen_llvm::context::CodegenCx as rustc_target::abi::LayoutOf>::layout_of
             at src/librustc_codegen_llvm/context.rs:846
  26: rustc_codegen_llvm::type_of::<impl rustc_codegen_llvm::context::CodegenCx>::size_and_align_of
             at src/librustc_codegen_llvm/type_of.rs:179
  27: rustc_codegen_llvm::debuginfo::metadata::create_struct_stub
             at src/librustc_codegen_llvm/debuginfo/metadata.rs:2385
  28: rustc_codegen_llvm::debuginfo::metadata::prepare_struct_metadata
             at src/librustc_codegen_llvm/debuginfo/metadata.rs:1249
  29: rustc_codegen_llvm::debuginfo::metadata::type_metadata
             at src/librustc_codegen_llvm/debuginfo/metadata.rs:688
  30: rustc_codegen_llvm::debuginfo::<impl rustc_codegen_ssa::traits::debuginfo::DebugInfoMethods for rustc_codegen_llvm::context::CodegenCx>::create_function_debug_context::get_containing_scope::{{closure}}
             at src/librustc_codegen_llvm/debuginfo/mod.rs:474
  31: core::option::Option<T>::and_then
             at ./src/libcore/option.rs:667
  32: rustc_codegen_llvm::debuginfo::<impl rustc_codegen_ssa::traits::debuginfo::DebugInfoMethods for rustc_codegen_llvm::context::CodegenCx>::create_function_debug_context::get_containing_scope
             at src/librustc_codegen_llvm/debuginfo/mod.rs:459
  33: rustc_codegen_llvm::debuginfo::<impl rustc_codegen_ssa::traits::debuginfo::DebugInfoMethods for rustc_codegen_llvm::context::CodegenCx>::create_function_debug_context
             at src/librustc_codegen_llvm/debuginfo/mod.rs:249
  34: rustc_codegen_ssa::mir::codegen_mir
             at ./src/librustc_codegen_ssa/mir/mod.rs:147
  35: rustc_codegen_ssa::base::codegen_instance
             at ./src/librustc_codegen_ssa/base.rs:388
  36: <rustc_middle::mir::mono::MonoItem as rustc_codegen_ssa::mono_item::MonoItemExt>::define
             at ./src/librustc_codegen_ssa/mono_item.rs:42
  37: rustc_codegen_llvm::base::compile_codegen_unit::module_codegen
             at src/librustc_codegen_llvm/base.rs:129
  38: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task_impl
             at ./src/librustc_query_system/dep_graph/graph.rs:303
  39: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task
             at ./src/librustc_query_system/dep_graph/graph.rs:200
  40: rustc_codegen_llvm::base::compile_codegen_unit
             at src/librustc_codegen_llvm/base.rs:108
  41: <rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_ssa::traits::backend::ExtraBackendMethods>::compile_codegen_unit
             at src/librustc_codegen_llvm/lib.rs:107
  42: rustc_codegen_ssa::base::codegen_crate
             at ./src/librustc_codegen_ssa/base.rs:675
  43: <rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_ssa::traits::backend::CodegenBackend>::codegen_crate
             at src/librustc_codegen_llvm/lib.rs:258
  44: rustc_interface::passes::start_codegen::{{closure}}
             at src/librustc_interface/passes.rs:1032
  45: rustc_data_structures::profiling::VerboseTimingGuard::run
             at ./src/librustc_data_structures/profiling.rs:573
  46: rustc_session::utils::<impl rustc_session::session::Session>::time
             at ./src/librustc_session/utils.rs:9
  47: rustc_interface::passes::start_codegen
             at src/librustc_interface/passes.rs:1031
  48: rustc_interface::queries::Queries::ongoing_codegen::{{closure}}::{{closure}}
             at src/librustc_interface/queries.rs:282
  49: rustc_middle::ty::context::tls::enter_global::{{closure}}
             at ./src/librustc_middle/ty/context.rs:1744
  50: rustc_middle::ty::context::tls::enter_context::{{closure}}
             at ./src/librustc_middle/ty/context.rs:1721
  51: rustc_middle::ty::context::tls::set_tlv
             at ./src/librustc_middle/ty/context.rs:1705
  52: rustc_middle::ty::context::tls::enter_context
             at ./src/librustc_middle/ty/context.rs:1721
  53: rustc_middle::ty::context::tls::enter_global
             at ./src/librustc_middle/ty/context.rs:1744
  54: rustc_interface::passes::QueryContext::enter
             at src/librustc_interface/passes.rs:761
  55: rustc_interface::queries::Queries::ongoing_codegen::{{closure}}
             at src/librustc_interface/queries.rs:273
  56: rustc_interface::queries::Query<T>::compute
             at src/librustc_interface/queries.rs:33
  57: rustc_interface::queries::Queries::ongoing_codegen
             at src/librustc_interface/queries.rs:271
  58: rustc_driver::run_compiler::{{closure}}::{{closure}}
             at src/librustc_driver/lib.rs:387
  59: rustc_interface::queries::<impl rustc_interface::interface::Compiler>::enter
             at ./src/librustc_interface/queries.rs:385
  60: rustc_driver::run_compiler::{{closure}}
             at src/librustc_driver/lib.rs:284
  61: rustc_interface::interface::create_compiler_and_run::{{closure}}
             at ./src/librustc_interface/interface.rs:192
  62: rustc_span::with_source_map
             at ./src/librustc_span/lib.rs:733
  63: rustc_interface::interface::create_compiler_and_run
             at ./src/librustc_interface/interface.rs:186
  64: rustc_interface::interface::run_compiler::{{closure}}
             at ./src/librustc_interface/interface.rs:208
  65: rustc_interface::util::setup_callbacks_and_run_in_thread_pool_with_globals::{{closure}}::{{closure}}::{{closure}}
             at ./src/librustc_interface/util.rs:151
  66: scoped_tls::ScopedKey<T>::set
             at /home/wesley/.cargo/registry/src/github.com-1ecc6299db9ec823/scoped-tls-1.0.0/src/lib.rs:137
  67: rustc_interface::util::setup_callbacks_and_run_in_thread_pool_with_globals::{{closure}}::{{closure}}
             at ./src/librustc_interface/util.rs:147
  68: scoped_tls::ScopedKey<T>::set
             at /home/wesley/.cargo/registry/src/github.com-1ecc6299db9ec823/scoped-tls-1.0.0/src/lib.rs:137
  69: rustc_ast::attr::with_session_globals::{{closure}}
             at ./src/librustc_ast/attr/mod.rs:49
  70: scoped_tls::ScopedKey<T>::set
             at /home/wesley/.cargo/registry/src/github.com-1ecc6299db9ec823/scoped-tls-1.0.0/src/lib.rs:137
  71: rustc_ast::attr::with_session_globals
             at ./src/librustc_ast/attr/mod.rs:48
  72: rustc_interface::util::setup_callbacks_and_run_in_thread_pool_with_globals::{{closure}}
             at ./src/librustc_interface/util.rs:146
  73: rustc_interface::util::scoped_thread::{{closure}}
             at ./src/librustc_interface/util.rs:121
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.46.0-dev running on x86_64-unknown-linux-gnu

note: compiler flags: -Z macro-backtrace -Z unstable-options -Z binary-dep-depinfo -Z force-unstable-if-unmarked -C opt-level=3 -C embed-bitcode=no -C codegen-units=16 -C debuginfo=2 -C debug-assertions=on -C overflow-checks=off -C link-args=-Wl,-rpath,$ORIGIN/../lib -C prefer-dynamic --crate-type lib

note: some of the compiler flags provided by cargo are hidden

query stack during panic:
end of query stack

</details>

davidtwco

comment created time in 19 days

pull request commentrust-lang/rust

move Deaggregate pass to post_borrowck_cleanup

The huge regressions are the CGU partitioning issue:

Query/Function Time (s) Time (%) Time delta Executions Executions delta Incremental loading (s) Incremental loading delta
LLVM_lto_optimize 113.016 33.99% 98.9% (56.198) 106 89.3% (50.000) 0.000 0.0% (0.000)
LLVM_thin_lto_import 78.149 23.50% 68.6% (31.802) 106 89.3% (50.000) 0.000 0.0% (0.000)
LLVM_module_codegen_emit_obj 59.497 17.89% 100.2% (29.772) 106 89.3% (50.000) 0.000 0.0% (0.000)
codegen_module_perform_lto 2.110 0.63% 113.5% (1.122) 106 89.3% (50.000) 0.000 0.0% (0.000)
LLVM_module_codegen 0.803 0.24% 89.2% (0.379) 106 89.3% (50.000) 0.000 0.0% (0.000)
oli-obk

comment created time in 19 days

issue commentrust-lang/rust

`todo!()`, `unimplemented!()`, `panic!()`, … don't play well with `impl Trait`

I believe this is a duplicate of https://github.com/rust-lang/rust/issues/69882

robinmoussu

comment created time in 20 days

pull request commentrust-lang/rust

Generating the coverage map

@bors try

richkadel

comment created time in 20 days

pull request commentrust-lang/rust

Polymorphization

I would like to nominate this PR for discussion at the compiler team triage meeting.

As I understand it, the current state of this PR is that:

It seems to me that a bit of direction from the compiler team would be helpful at this time. I would like to discuss:

  • Assuming those final reviews are completed and feedback addressed, is this ready to merge?

    • If not, what else needs to be done before this PR can be merged?
  • Should we merge this enabled by default or disabled by default?

davidtwco

comment created time in 20 days

pull request commentrust-lang/rust

Don't panic if the lhs of a div by zero is not statically known

Looks like we just missed the beta train? #74323

oli-obk

comment created time in 20 days

pull request commentrust-lang/rust

move Deaggregate pass to post_borrowck_cleanup

 memory allocation of 1073741828 bytes failed[RUSTC-TIMING] hex test:false 1.487
rustc exited with signal: 6
error: could not compile `hex`.

Caused by:
  process didn't exit successfully: `/checkout/obj/build/bootstrap/debug/rustc --crate-name hex /cargo/registry/src/github.com-1285ae84e5963aae/hex-0.3.2/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -Cembed-bitcode=no -C debuginfo=0 -C metadata=7aa1d73c5dd23801 -C extra-filename=-7aa1d73c5dd23801 --out-dir /checkout/obj/build/i686-unknown-linux-gnu/stage1-tools/i686-unknown-linux-gnu/release/deps --target i686-unknown-linux-gnu -C linker=clang -L dependency=/checkout/obj/build/i686-unknown-linux-gnu/stage1-tools/i686-unknown-linux-gnu/release/deps -L dependency=/checkout/obj/build/i686-unknown-linux-gnu/stage1-tools/release/deps --cap-lints allow -Zmacro-backtrace '-Clink-args=-Wl,-rpath,$ORIGIN/../lib' -Zbinary-dep-depinfo` (exit code: 254)
oli-obk

comment created time in 20 days

pull request commentrust-lang/rust

Refactor the partitioning module to make it easier to introduce new algorithms

Responded to review feedback so far.

wesleywiser

comment created time in 21 days

push eventwesleywiser/rust

Wesley Wiser

commit sha 6c7ab8daf37ad69a133b2864332c754c1896e1b9

Add partitioning -Z option to control which partitioning scheme is used

view details

push time in 21 days

Pull request review commentrust-lang/rust

Refactor the partitioning module to make it easier to introduce new algorithms

 options! {DebuggingOptions, DebuggingSetter, basic_debugging_options,         "support compiling tests with panic=abort (default: no)"),     parse_only: bool = (false, parse_bool, [UNTRACKED],         "parse only; do not compile, assemble, or link (default: no)"),+    partitioning_strategy: Option<String> = (None, parse_opt_string, [TRACKED],

I agree (and went with cgu-partitioning-strategy)

wesleywiser

comment created time in 21 days

pull request commentrust-lang/rust

Generating the coverage map

@bors try

richkadel

comment created time in 21 days

push eventrust-lang/compiler-team

Joshua Nelson

commit sha 0d106fb4f95794cf2683309dc09c8b62838fc877

Add rustdoc to 'experts' list

view details

Joshua Nelson

commit sha 5431a42593080ad9c88a34af12a114eba500df78

Add ollie27; move Manishearth to expert

view details

Wesley Wiser

commit sha d239183dbb12b5dc31830b25b6d9461294ae03ad

Merge pull request #311 from jyn514/rustdoc Add rustdoc to 'experts' list

view details

push time in 21 days

PR merged rust-lang/compiler-team

Add rustdoc to 'experts' list

I noticed this link from https://github.com/rust-lang/rustc-dev-guide/pull/731/files#diff-a75a5daa4f7310d9e1bebc2021f72c16R26 and saw that rustdoc wasn't here at all!

r? @GuillaumeGomez

Let me know if I missed anyone, I'm not sure exactly how the rustdoc team is setup.

+9 -0

0 comment

1 changed file

jyn514

pr closed time in 21 days

pull request commentrust-lang/rust

Generating the coverage map

If we have to disable it on Windows to land this change, I think that's ok (but not my preferred solution). In that case, we should make sure we have an issue documenting that which can be referenced in the code which disables it on Windows. That may be a blocker before this feature can be stabilized but that's not something we have to consider for a while.

There's also a set of people we can ping with Windows specific questions but I don't know how much they know about LLVM internals so we should try figuring out the issue before pinging them.

richkadel

comment created time in 21 days

pull request commentrust-lang/rust

Don't panic if the lhs of a div by zero is not statically known

Is ConstProp not actually running in check mode or something?

oli-obk

comment created time in 21 days

pull request commentrust-lang/rust

move Deaggregate pass to post_borrowck_cleanup

Since this does seem to have some impact on the optimized MIR, I think there could be some perf impacts (hopefully positive 🤞 ). Therefore:

@bors r+ rollup=never

oli-obk

comment created time in 21 days

pull request commentrust-lang/rust

Generating the coverage map

@bors try

richkadel

comment created time in 21 days

Pull request review commentrust-lang/rust

move Deaggregate pass to post_borrowck_cleanup

 // MIR for `main::{{closure}}#0` 0 generator_resume /* generator_layout = GeneratorLayout {-    field_tys: {-        _0: HasDrop,

Should we be concerned about this change?

oli-obk

comment created time in 21 days

Pull request review commentrust-lang/rust

move Deaggregate pass to post_borrowck_cleanup

 fn main::{{closure}}#0(_1: std::pin::Pin<&mut [generator@$DIR/generator-tiny.rs:      bb1: {         _10 = move _2;                   // scope 0 at $DIR/generator-tiny.rs:19:16: 25:6-        nop;                             // scope 0 at $DIR/generator-tiny.rs:20:13: 20:15-        (((*(_1.0: &mut [generator@$DIR/generator-tiny.rs:19:16: 25:6 {u8, HasDrop, ()}])) as variant#3).0: HasDrop) = HasDrop; // scope 0 at $DIR/generator-tiny.rs:20:18: 20:25

Looks like this HasDrop value got optimized out completely? I guess that's what's causing the above. I'm not sure how significant that is to this test.

oli-obk

comment created time in 21 days

Pull request review commentrust-lang/rust

move Deaggregate pass to post_borrowck_cleanup

 // MIR for `main::{{closure}}#0` 0 generator_resume /* generator_layout = GeneratorLayout {-    field_tys: {-        _0: HasDrop,-    },+    field_tys: {},     variant_fields: {         Unresumed(0): [],         Returned (1): [],         Panicked (2): [],-        Suspend0 (3): [_0],-    },-    storage_conflicts: BitMatrix(1x1) {-        (_0, _0),+        Suspend0 (3): [],

Similarly _0 is no longer in this list.

oli-obk

comment created time in 21 days

pull request commentrust-lang/rust

Generating the coverage map

I was able to generate coverage on the entire json5format crate, which was awesome.

This is really great work!

Let's hold off with bors try until I submit one more change. I found the problem with MacOS.

Ok, lmk when you want to try again. 🙂

richkadel

comment created time in 22 days

Pull request review commentrust-lang/rust

Generating the coverage map

 use rustc_data_structures::fx::FxHashMap;+use rustc_data_structures::sync::Lrc;+use rustc_span::source_map::{BytePos, Pos, SourceFile, SourceMap};+ use std::collections::hash_map;+use std::fmt; use std::slice;  #[derive(Copy, Clone, Debug)]+#[repr(C)] pub enum CounterOp {-    Add,+    // Note the order (and therefore the default values) is important. With the attribute+    // `#[repr(C)]`, this enum matches the layout of the LLVM enum defined for the nested enum,+    // `llvm::coverage::CounterExpression::ExprKind`, as shown in the following source snippet:+    // https://github.com/rust-lang/llvm-project/blob/f208b70fbc4dee78067b3c5bd6cb92aa3ba58a1e/llvm/include/llvm/ProfileData/Coverage/CoverageMapping.h#L146     Subtract,+    Add, } +#[derive(Debug)] pub enum CoverageKind {     Counter,     CounterExpression(u32, CounterOp, u32), } +#[derive(Debug)] pub struct CoverageSpan {     pub start_byte_pos: u32,     pub end_byte_pos: u32, } +#[derive(Debug)] pub struct CoverageRegion {     pub kind: CoverageKind,     pub coverage_span: CoverageSpan, } +/// A source code region used with coverage information.+#[derive(Debug)]+pub struct CoverageLoc {+    /// Information about the original source file.+    pub file: Lrc<SourceFile>,+    /// The (1-based) line number of the region start.+    pub start_line: u32,+    /// The (1-based) column number of the region start.+    pub start_col: u32,+    /// The (1-based) line number of the region end.+    pub end_line: u32,+    /// The (1-based) column number of the region end.+    pub end_col: u32,+}++impl fmt::Display for CoverageLoc {+    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {+        // Customize debug format, and repeat the file name, so generated location strings are+        // "clickable" in many IDEs.+        write!(+            f,+            "{}:{}:{} - {}:{}:{}",+            (*self).file.name,+            self.start_line,+            self.start_col,+            (*self).file.name,+            self.end_line,+            self.end_col+        )+    }+}++fn lookup_file_line_col(source_map: &SourceMap, byte_pos: BytePos) -> (Lrc<SourceFile>, u32, u32) {+    let found = source_map+        .lookup_line(byte_pos)+        .expect("should find coverage region byte position in source");+    let file = found.sf;+    let line_pos = file.line_begin_pos(byte_pos);++    // Use 1-based indexing.+    let line = (found.line + 1) as u32;+    let col = (byte_pos - line_pos).to_u32() + 1;++    (file, line, col)+}++impl CoverageRegion {+    pub fn coverage_loc(&self, source_map: &SourceMap) -> CoverageLoc {+        let (file, start_line, start_col) =+            lookup_file_line_col(source_map, BytePos::from_u32(self.coverage_span.start_byte_pos));+        let (_, end_line, end_col) =

@richkadel I wonder if any of those are related to macros? If you look at the MIR for a simple hello world (playground), you can see that some of the spans come from the playground file (src/lib.rs) while many of the others come from the expansion of the println!() macro and point into the std library (/rustc/{git commit}/src/libstd/macros.rs).

richkadel

comment created time in 22 days

Pull request review commentrust-lang/rust

Generating the coverage map

+#include "rustllvm.h"+#include "llvm/ProfileData/Coverage/CoverageMapping.h"+#include "llvm/ProfileData/Coverage/CoverageMappingWriter.h"+#include "llvm/ProfileData/InstrProf.h"+#include "llvm/Support/FileSystem.h"+#include "llvm/Support/Path.h"+#include "llvm/ADT/ArrayRef.h"++#include <iostream>++using namespace llvm;++extern "C" SmallVectorTemplateBase<coverage::CounterExpression>+    *LLVMRustCoverageSmallVectorCounterExpressionCreate() {+  return new SmallVector<coverage::CounterExpression, 32>();+}++extern "C" void LLVMRustCoverageSmallVectorCounterExpressionDispose(+    SmallVectorTemplateBase<coverage::CounterExpression> *Vector) {+  delete Vector;+}++extern "C" void LLVMRustCoverageSmallVectorCounterExpressionAdd(+    SmallVectorTemplateBase<coverage::CounterExpression> *Expressions,+    coverage::CounterExpression::ExprKind Kind,+    unsigned LeftIndex,+    unsigned RightIndex) {+  auto LHS = coverage::Counter::getCounter(LeftIndex);+  auto RHS = coverage::Counter::getCounter(RightIndex);+  Expressions->push_back(coverage::CounterExpression { Kind, LHS, RHS });+}++extern "C" SmallVectorTemplateBase<coverage::CounterMappingRegion>+    *LLVMRustCoverageSmallVectorCounterMappingRegionCreate() {+  return new SmallVector<coverage::CounterMappingRegion, 32>();+}++extern "C" void LLVMRustCoverageSmallVectorCounterMappingRegionDispose(+    SmallVectorTemplateBase<coverage::CounterMappingRegion> *Vector) {+  delete Vector;+}++extern "C" void LLVMRustCoverageSmallVectorCounterMappingRegionAdd(+    SmallVectorTemplateBase<coverage::CounterMappingRegion> *MappingRegions,+    unsigned Index,+    unsigned FileID,+    unsigned LineStart,+    unsigned ColumnStart,+    unsigned LineEnd,+    unsigned ColumnEnd) {+  auto Counter = coverage::Counter::getCounter(Index);+  MappingRegions->push_back(coverage::CounterMappingRegion::makeRegion(+           Counter, FileID, LineStart,+           ColumnStart, LineEnd, ColumnEnd));++  // FIXME(richkadel): As applicable, implement additional CounterMappingRegion types using the+  // static method alternatives to `coverage::CounterMappingRegion::makeRegion`:+  //+  //   makeExpansion(unsigned FileID, unsigned ExpandedFileID, unsigned LineStart,+  //                 unsigned ColumnStart, unsigned LineEnd, unsigned ColumnEnd) {+  //   makeSkipped(unsigned FileID, unsigned LineStart, unsigned ColumnStart,+  //               unsigned LineEnd, unsigned ColumnEnd) {+  //   makeGapRegion(Counter Count, unsigned FileID, unsigned LineStart,+  //                 unsigned ColumnStart, unsigned LineEnd, unsigned ColumnEnd) {+}++extern "C" void LLVMRustCoverageWriteFilenamesSectionToBuffer(+    const char* const Filenames[],+    size_t FilenamesLen,+    RustStringRef BufferOut) {+  SmallVector<StringRef,32> FilenameRefs;+  for (size_t i = 0; i < FilenamesLen; i++) {+    FilenameRefs.push_back(StringRef(Filenames[i]));+  }+  auto FilenamesWriter = coverage::CoverageFilenamesSectionWriter(+    makeArrayRef(FilenameRefs));+  RawRustStringOstream OS(BufferOut);+  FilenamesWriter.write(OS);+}++extern "C" void LLVMRustCoverageWriteMappingToBuffer(+    const unsigned *VirtualFileMappingIDs,+    unsigned NumVirtualFileMappingIDs,

Oh, ok that's fine. I just happened to see some of the "Count" functions.

richkadel

comment created time in 22 days

Pull request review commentrust-lang/rust

[mir-opt] Allow debuginfo to be generated for a constant or a Place

 impl<'mir, 'tcx> MutVisitor<'tcx> for ConstPropagator<'mir, 'tcx> {             if let Ok(place_layout) = self.tcx.layout_of(self.param_env.and(place_ty)) {                 let can_const_prop = self.can_const_prop[place.local];                 if let Some(()) = self.const_prop(rval, place_layout, source_info, place) {-                    // This will return None if the above `const_prop` invocation only "wrote" a-                    // type whose creation requires no write. E.g. a generator whose initial state-                    // consists solely of uninitialized memory (so it doesn't capture any locals).-                    if let Some(value) = self.get_const(place) {-                        if self.should_const_prop(value) {-                            trace!("replacing {:?} with {:?}", rval, value);-                            self.replace_with_const(rval, value, source_info);-                            if can_const_prop == ConstPropMode::FullConstProp-                                || can_const_prop == ConstPropMode::OnlyInsideOwnBlock-                            {-                                trace!("propagated into {:?}", place);+                    if can_const_prop != ConstPropMode::NoPropagation {+                        // This will return None for variables that are from other blocks,+                        // so it should be okay to propagate from here on down.+                        if let Some(value) = self.get_const(place) {+                            if self.should_const_prop(value) {+                                trace!("replacing {:?} with {:?}", rval, value);+                                self.replace_with_const(rval, value, statement.source_info);+                                if can_const_prop == ConstPropMode::FullConstProp+                                    || can_const_prop == ConstPropMode::OnlyInsideOwnBlock+                                {+                                    trace!("propagated into {:?}", place);++                                    if place.projection.is_empty()+                                        && !self.has_mutation.contains(place.local)+                                    {+                                        self.fully_propagated_locals[place.local] = Some(value);

I'm personally not a huge fan of having this field. It seems easy to add logic later that uses it incorrectly.

Here's a different idea, I think we could remove this field entirely and instead loop over the debuginfo here and update it accordingly. @oli-obk do you think that would be better?

wesleywiser

comment created time in 23 days

pull request commentrust-lang/rust

Refactor the partitioning module to make it easier to introduce new algorithms

r? @pnkfelix cc @rust-lang/wg-incr-comp

wesleywiser

comment created time in 23 days

push eventrust-lang/measureme

Simonas Kazlauskas

commit sha 617dff52ac69d7d4653170a7481f0cacaf44d3ae

API: Take AsRef<Path> and Send+Sync errors Having errors be `Send+Sync` is a good practice in the Rust ecosystem as it allows at least passing the errors in and out of threads as it is propagated. `AsRef<Path>` allows more convenient use of the constructor wherein you have the convenience of being able to pass in e.g. a string literal.

view details

Simonas Kazlauskas

commit sha 567d37944041c595196bd05316d287200d96cf45

mmview: Do not panic when there are no events

view details

Simonas Kazlauskas

commit sha 8cf87a6004b95d41f0d2b1a09b7a2c831df47f6d

analyzeme: Don't panic decoding StringId::INVALID

view details

Simonas Kazlauskas

commit sha 75758ca9d424df45fd15e70185173aa737392dcb

Sort the workspace members

view details

Wesley Wiser

commit sha 88522bb33a652a9517e182a7126239d98b91aa21

Merge pull request #119 from nagisa/nagisa/assorted-fixes Assorted fixes and improvements

view details

push time in 23 days

PR merged rust-lang/measureme

Assorted fixes and improvements

See individual commits for descriptions.

If I come across other problems I might add onto what is currently here.

+25 -22

0 comment

7 changed files

nagisa

pr closed time in 23 days

Pull request review commentrust-lang/rust

[WIP] Refactor the partitioning module to make it easier to introduce new schemes

 options! {DebuggingOptions, DebuggingSetter, basic_debugging_options,         "support compiling tests with panic=abort (default: no)"),     parse_only: bool = (false, parse_bool, [UNTRACKED],         "parse only; do not compile, assemble, or link (default: no)"),+    partitioning_strategy: Option<String> = (None, parse_opt_string, [TRACKED],

Maybe this should be -Zcgu-partitioning-strategy instead?

wesleywiser

comment created time in 23 days

Pull request review commentrust-lang/rust

[WIP] Refactor the partitioning module to make it easier to introduce new schemes

+//! Partitioning Codegen Units for Incremental Compilation

This comment block is taken verbatim from its original location. Parts of it describe the partitioning process over all and parts are specific to the algorithm (now called DefaultPartitioner).

This could probably be left as is for now but eventually we should split it into two parts and move the bits about the algorithm into module documentation for the DefaultPartitioner algorithm.

wesleywiser

comment created time in 23 days

Pull request review commentrust-lang/rust

[WIP] Refactor the partitioning module to make it easier to introduce new schemes

+//! Partitioning Codegen Units for Incremental Compilation+//! ======================================================+//!+//! The task of this module is to take the complete set of monomorphizations of+//! a crate and produce a set of codegen units from it, where a codegen unit+//! is a named set of (mono-item, linkage) pairs. That is, this module+//! decides which monomorphization appears in which codegen units with which+//! linkage. The following paragraphs describe some of the background on the+//! partitioning scheme.+//!+//! The most important opportunity for saving on compilation time with+//! incremental compilation is to avoid re-codegenning and re-optimizing code.+//! Since the unit of codegen and optimization for LLVM is "modules" or, how+//! we call them "codegen units", the particulars of how much time can be saved+//! by incremental compilation are tightly linked to how the output program is+//! partitioned into these codegen units prior to passing it to LLVM --+//! especially because we have to treat codegen units as opaque entities once+//! they are created: There is no way for us to incrementally update an existing+//! LLVM module and so we have to build any such module from scratch if it was+//! affected by some change in the source code.+//!+//! From that point of view it would make sense to maximize the number of+//! codegen units by, for example, putting each function into its own module.+//! That way only those modules would have to be re-compiled that were actually+//! affected by some change, minimizing the number of functions that could have+//! been re-used but just happened to be located in a module that is+//! re-compiled.+//!+//! However, since LLVM optimization does not work across module boundaries,+//! using such a highly granular partitioning would lead to very slow runtime+//! code since it would effectively prohibit inlining and other inter-procedure+//! optimizations. We want to avoid that as much as possible.+//!+//! Thus we end up with a trade-off: The bigger the codegen units, the better+//! LLVM's optimizer can do its work, but also the smaller the compilation time+//! reduction we get from incremental compilation.+//!+//! Ideally, we would create a partitioning such that there are few big codegen+//! units with few interdependencies between them. For now though, we use the+//! following heuristic to determine the partitioning:+//!+//! - There are two codegen units for every source-level module:+//! - One for "stable", that is non-generic, code+//! - One for more "volatile" code, i.e., monomorphized instances of functions+//!   defined in that module+//!+//! In order to see why this heuristic makes sense, let's take a look at when a+//! codegen unit can get invalidated:+//!+//! 1. The most straightforward case is when the BODY of a function or global+//! changes. Then any codegen unit containing the code for that item has to be+//! re-compiled. Note that this includes all codegen units where the function+//! has been inlined.+//!+//! 2. The next case is when the SIGNATURE of a function or global changes. In+//! this case, all codegen units containing a REFERENCE to that item have to be+//! re-compiled. This is a superset of case 1.+//!+//! 3. The final and most subtle case is when a REFERENCE to a generic function+//! is added or removed somewhere. Even though the definition of the function+//! might be unchanged, a new REFERENCE might introduce a new monomorphized+//! instance of this function which has to be placed and compiled somewhere.+//! Conversely, when removing a REFERENCE, it might have been the last one with+//! that particular set of generic arguments and thus we have to remove it.+//!+//! From the above we see that just using one codegen unit per source-level+//! module is not such a good idea, since just adding a REFERENCE to some+//! generic item somewhere else would invalidate everything within the module+//! containing the generic item. The heuristic above reduces this detrimental+//! side-effect of references a little by at least not touching the non-generic+//! code of the module.+//!+//! A Note on Inlining+//! ------------------+//! As briefly mentioned above, in order for LLVM to be able to inline a+//! function call, the body of the function has to be available in the LLVM+//! module where the call is made. This has a few consequences for partitioning:+//!+//! - The partitioning algorithm has to take care of placing functions into all+//!   codegen units where they should be available for inlining. It also has to+//!   decide on the correct linkage for these functions.+//!+//! - The partitioning algorithm has to know which functions are likely to get+//!   inlined, so it can distribute function instantiations accordingly. Since+//!   there is no way of knowing for sure which functions LLVM will decide to+//!   inline in the end, we apply a heuristic here: Only functions marked with+//!   `#[inline]` are considered for inlining by the partitioner. The current+//!   implementation will not try to determine if a function is likely to be+//!   inlined by looking at the functions definition.+//!+//! Note though that as a side-effect of creating a codegen units per+//! source-level module, functions from the same module will be available for+//! inlining, even when they are not marked `#[inline]`.++mod default;+mod merging;++use rustc_data_structures::fx::{FxHashMap, FxHashSet};+use rustc_data_structures::sync;+use rustc_hir::def_id::{CrateNum, DefIdSet, LOCAL_CRATE};+use rustc_middle::mir::mono::MonoItem;+use rustc_middle::mir::mono::{CodegenUnit, Linkage};+use rustc_middle::ty::query::Providers;+use rustc_middle::ty::TyCtxt;+use rustc_span::symbol::Symbol;++use crate::monomorphize::collector::InliningMap;+use crate::monomorphize::collector::{self, MonoItemCollectionMode};++trait Partitioner<'tcx> {+    fn place_root_mono_items(+        &mut self,+        tcx: TyCtxt<'tcx>,+        mono_items: &mut dyn Iterator<Item = MonoItem<'tcx>>,+    ) -> PreInliningPartitioning<'tcx>;++    fn merge_codegen_units(+        &mut self,+        tcx: TyCtxt<'tcx>,+        initial_partitioning: &mut PreInliningPartitioning<'tcx>,+        target_cgu_count: usize,+    );++    fn place_inlined_mono_items(

This name & signature was taken from the existing code. One that that was not immediately obvious to me was that this does a lot more than just add copies of #[inline] functions into CGUs. This function is primary responsible for instantiating monomorphized functions in the modules that call them. (Perhaps that's what was meant by "inlined"?)

wesleywiser

comment created time in 23 days

Pull request review commentrust-lang/rust

[WIP] Refactor the partitioning module to make it easier to introduce new schemes

+use std::cmp;++use rustc_data_structures::fx::FxHashMap;+use rustc_hir::def_id::LOCAL_CRATE;+use rustc_middle::mir::mono::{CodegenUnit, CodegenUnitNameBuilder};+use rustc_middle::ty::TyCtxt;+use rustc_span::symbol::{Symbol, SymbolStr};++use crate::monomorphize::partitioning::PreInliningPartitioning;++pub fn merge_codegen_units<'tcx>(

I pulled this out into a separate module since it seemed like we might want a few different merge algorithms to choose from.

wesleywiser

comment created time in 23 days

pull request commentrust-lang/rust

[WIP] Refactor the partitioning module to make it easier to introduce new schemes

Let's make sure this doesn't hurt performance.

@bors try @rust-timer queue

wesleywiser

comment created time in 23 days

more