T Compiler Meeting Agenda 2024 05 16

T-compiler Meeting Agenda 2024-05-16

Announcements

  • Special reminder for rfcs#3599: needs just one more vote :thank_you: cc: @cjgillot @Esteban Küber and @Aaron Hill
  • Reminder: if you see a PR/issue that seems like there might be legal implications due to copyright/IP/etc, please let us know (or at least message @davidtwco or @Wesley Wiser so we can pass it along).

Other WG meetings

MCPs/FCPs

WG checkins

None this week

Backport nominations

T-compiler beta / T-compiler stable

  • :beta: “Make non-local-def lint Allow by default” rust#124950
    • authored by @_Wesley Wiser
    • calms down a slew of warnings on non-local definitions until we figure out how to better implement this lint (relevant RFC#3373)
  • :beta: “Don’t do post-method-probe error reporting steps if we’re in a suggestion” rust#125100
    • authored by @_Michael Goulet (compiler-errors)
    • nominated because it can pretty negatively affect user experience when a programmer has many method errors in large projects (comment)
    • Regressed in #120730
  • :stable: “When comparing SVG tests against their blessed version, ignore the first line” rust#122779
    • authored by @_Esteban Küber
    • Fixes a regression in #122779 (comment)
    • nominated with the clause “nice to have, if a dot release happens” (comment), fix didn’t make to 1.78

T-types stable / T-types beta

  • No beta nominations for T-types this time.
  • No stable nominations for T-types this time.

PRs S-waiting-on-team

T-compiler

  • “Uplift clippy::precedence lint” rust#117161
  • “Better errors with bad/missing identifiers in MBEs” rust#118939
  • “Uplift clippy::invalid_null_ptr_usage lint” rust#119220
  • “Rename AsyncIterator back to Stream, introduce an AFIT-based AsyncIterator trait” rust#119550
  • “Disallow deriving (other than Copy/Clone) on types with unnamed fields” rust#121270
  • “Implement lint against unexpected unary precedence” rust#121364
  • “Show files produced by --emit foo in json artifact notifications” rust#122597
  • “Emit a warning if a match is too complex” rust#122685
  • “Support C23’s Variadics Without a Named Parameter” rust#124048
  • “Warn (or error) when Self ctor from outer item is referenced in inner nested item” rust#124187
  • Issues in progress or waiting on other teams

Issues of Note

Short Summary

P-critical

T-compiler

  • “-C target_cpu=cortex-a72 (and -target-cpu=native on Raspberry Pi) wrongly enables crypto features that are optional on Cortex-A72” rust#125033
    • @_apiraino assigned P-critical (reasoning) but happy to hear other opinions
    • In any case upstream LLVM issue has been filed llvm#90365

T-types

  • No P-critical issues for T-types this time.

P-high regressions

P-high beta regressions

  • None

Unassigned P-high nightly regressions

  • “New rustc nightly suggests adding a build.rs to use conditional compilation” rust#124800
    • Question from cargo team to T-compiler was:

      If we go with lint configuration, any thoughts or concerns about Cargo “owning” lint configuration under [lints.rust] where Cargo translates the configuration into CLI flags for rustc, leaving rustc to be more generic?

    • Discussed last week, agreed that cargo can use such section as they see fit
    • FYI @Wesley Wiser I’ve added your comment here, please lmk if I represented it correctly :)

Performance logs

triage logs for 2024-05-14

A pretty quiet week with only a few PRs being flagged for analysis. More improvements than regressions this week, and also several nice binary size reductions caused by generating less LLVM IR.

Triage done by @kobzol*. Revision range: 69f53f5e..9105c57b

Summary:

(instructions:u) mean range count
Regressions (primary) 0.4% [0.2%, 0.9%] 8
Regressions (secondary) 0.9% [0.2%, 2.4%] 18
Improvements (primary) -1.1% [-2.3%, -0.2%] 51
Improvements (secondary) -0.6% [-1.4%, -0.3%] 19
All (primary) -0.9% [-2.3%, 0.9%] 59

1 Regression, 0 Improvements, 3 Mixed; 0 of them in rollups 75 artifact comparisons made in total

Regressions

Do not add leading asterisk in the PartialEq #124157 (Comparison Link)

(instructions:u) mean range count
Regressions (primary) 0.3% [0.2%, 0.5%] 9
Regressions (secondary) 0.4% [0.3%, 0.8%] 9
Improvements (primary) - - 0
Improvements (secondary) - - 0
All (primary) 0.3% [0.2%, 0.5%] 9
  • Small regression on a few benchmarks caused by a change in code generation of #[derive(PartialEq)], which leads to more valid code being allowed to compile.
  • Marked as triaged.

Mixed

Avoid a cast in ptr::slice_from_raw_parts(_mut)_) #124795 (Comparison Link)

(instructions:u) mean range count
Regressions (primary) 0.3% [0.3%, 0.3%] 1
Regressions (secondary) - - 0
Improvements (primary) -0.4% [-0.6%, -0.3%] 6
Improvements (secondary) -0.3% [-0.4%, -0.2%] 16
All (primary) -0.3% [-0.6%, 0.3%] 7
  • A single tiny regression outweighed by several performance wins.
  • This PR also reduced binary size nicely.

Avoid allocas in codegen for simple mir::Aggregate statements #123886 (Comparison Link)

(instructions:u) mean range count
Regressions (primary) 0.2% [0.2%, 0.3%] 6
Regressions (secondary) 0.5% [0.2%, 1.3%] 4
Improvements (primary) -0.6% [-1.0%, -0.3%] 6
Improvements (secondary) -0.7% [-1.1%, -0.4%] 2
All (primary) -0.2% [-1.0%, 0.3%] 12
  • The regression was limited to a single primary benchmark, there were more primary benchmark wins.
  • Also a nice binary size reduction in debug builds.

Remove NtIdent and NtLifetime #124256 (Comparison Link)

(instructions:u) mean range count
Regressions (primary) 0.2% [0.2%, 0.2%] 1
Regressions (secondary) 1.9% [1.2%, 2.7%] 8
Improvements (primary) -0.8% [-2.0%, -0.1%] 24
Improvements (secondary) -0.6% [-1.1%, -0.3%] 9
All (primary) -0.7% [-2.0%, 0.2%] 25
  • Pretty much a pure performance improvement, the instruction count regression on tt-muncher was actually a decent win in cycle count.

Nominated Issues

T-compiler

  • “The const-eval interpreter is called on incomplete/invalid/ill-formed code” rust#124789
    • Nominated by @Jieyou Xu (comment)

      It’s probably desirable to discuss some error handling strategy that preserves the “fail as late as possible, report as many errors as possible” idea and yet does not let inputs that const-eval does not expect to handle to go through, at the item granularity. Maybe this involves some pre-const-eval validation/guard, or hardening const-eval against invalid inputs, or some other strategy.

    • Discussion on Zulip, where @lcnr points out that we already have the tainted_by_errors mechanism for this. But either the MIR bodies containing these invalid operations do not get tainted properly, or the interpreter is not properly skipping execution of tainted MIR bodies.

RFC

  • No I-compiler-nominated RFCs this time.

Oldest PRs waiting for review

T-compiler

  • Skipping this week

Next week’s WG checkins

None

Next meetings' agenda draft: hackmd link