profile
viewpoint
Eduard-Mihai Burtescu eddyb @LykenSol Bucharest, Romania Senior Compiler/PL Engineer

alexcrichton/rustc-demangle 79

Rust symbol demangling

Centril/rfc-effects 8

Preparing an RFC on effect polymorphism in Rust with focus on 'const'

eddyb/aoc 2

Advent of Code solutions in Rust

eddyb/bootstrap 2

HTML, CSS, and JS toolkit from Twitter

eddyb/hematite 2

A simple Minecraft written in Rust with the Piston game engine

eddyb/1ml 0

1ML prototype interpreter

eddyb/cargo 0

The Rust package manager

eddyb/clap-rs 0

A full featured, fast Command Line Argument Parser for Rust

push eventeddyb/rust

Daniel Frampton

commit sha d19562062c546dd568455547c50cfb9fb9017dea

Ensure there are versions of test code for aarch64 windows

view details

Bastian Kauschke

commit sha 626fdbce8bd2a6c62ab648129f6cbf8e12c8a239

add `fn make_contiguous` to VecDeque

view details

Bastian Kauschke

commit sha ecf301d987ed944ef96f627757a0fc58608ff1bb

document invariant of `VecDeque::as_(mut)_slice`

view details

Bastian Kauschke

commit sha d068545bfb7364e8409355e98f8c579e0930750b

update `make_contiguous` docs Co-Authored-By: Amanieu d'Antras <amanieu@gmail.com>

view details

Ben Wolsieffer

commit sha c2f1097adebcae41197bf6053e691a5c8e947378

Upgrade GCC to 8.3.0, glibc to 2.17.0 and crosstool-ng to 1.24.0 for dist-arm-linux and dist-armhf-linux

view details

Bastian Kauschke

commit sha e0a08351a23d06903badd6f79d0971d2adf1b645

add visit_anon_const to EarlyContextAndPass

view details

Bastian Kauschke

commit sha b3d744c9f51b6bb42c7cebeb8f7fcefac8778d1e

add `unused_braces`, lint anon_const

view details

Russell Cohen

commit sha 840a5769b0879f39e21d973a60ac0b0db172f050

Move raw string tests into the raw directory

view details

Dylan MacKenzie

commit sha 4d099e63083b4730f57d1ccb5d27c251dbddfb56

Add `-Z dump-mir-dataflow`

view details

Dylan MacKenzie

commit sha edbd7c86027c7205076832924ee7999796c2405f

`dump_enabled` takes a `DefId` instead of `MirSource`

view details

Dylan MacKenzie

commit sha c8004027ba11a7611ead54275ab14f58a8b0edb8

Dump graphviz dataflow results with flag

view details

Dylan MacKenzie

commit sha 4d1194c31a8548f554212abb8fa724319631e2fc

Ensure output dir for dataflow results exists

view details

Russell Cohen

commit sha 629e97a5a02edb3d8dc63c5157962c093217d441

Improve error messages for raw strings (#60762) This diff improves error messages around raw strings in a few ways: - Catch extra trailing `#` in the parser. This can't be handled in the lexer because we could be in a macro that actually expects another # (see test) - Refactor & unify error handling in the lexer between ByteStrings and RawByteStrings - Detect potentially intended terminators (longest sequence of "#*" is suggested)

view details

Stein Somers

commit sha a6cae3d5cfad59e16afa95926324bf8e93250019

Add benchmarks of drain_filter-like behaviour

view details

Stein Somers

commit sha 0405db3a341a094f421a762a15c14b392fec94f8

BTreeMap/BTreeSet: implement and test drain_filter

view details

Russell Cohen

commit sha c15f86b4b35a260b105dc472fc6e3556af8a8db0

Cleanup error messages, improve docstrings

view details

Russell Cohen

commit sha 82b2989ae0dbb1166289a360620e07865135a5e8

More raw string tests

view details

Russell Cohen

commit sha bceab25d6c206a7b92716e0c9e9a89b97d131e8e

Cleanup match expression

view details

Julien Philippon

commit sha 8f7eb6229cb301c2ee7900a36a13f2906518378f

Add long error code for error E0226

view details

Mazdak Farrokhzad

commit sha 96d73536782fb4a6a4b98db330ac5446c63a8005

parse_and_disallow_postfix_after_cast: account for `ExprKind::Err`.

view details

push time in 4 minutes

Pull request review commentrust-lang/rust

add `STILL_FURTHER_SPECIALIZABLE` flag

 bitflags! {         // Does this have parameters? Used to determine whether substitution is         // required.         /// Does this have [Param]?-        const HAS_TY_PARAM              = 1 << 0;+        const HAS_TY_PARAM                = 1 << 0;         /// Does this have [ReEarlyBound]?-        const HAS_RE_PARAM              = 1 << 1;+        const HAS_RE_PARAM                = 1 << 1;         /// Does this have [ConstKind::Param]?-        const HAS_CT_PARAM              = 1 << 2;+        const HAS_CT_PARAM                = 1 << 2; -        const NEEDS_SUBST               = TypeFlags::HAS_TY_PARAM.bits-                                        | TypeFlags::HAS_RE_PARAM.bits-                                        | TypeFlags::HAS_CT_PARAM.bits;+        const NEEDS_SUBST                 = TypeFlags::HAS_TY_PARAM.bits+                                          | TypeFlags::HAS_RE_PARAM.bits+                                          | TypeFlags::HAS_CT_PARAM.bits;          /// Does this have [Infer]?-        const HAS_TY_INFER              = 1 << 3;+        const HAS_TY_INFER                = 1 << 3;         /// Does this have [ReVar]?-        const HAS_RE_INFER              = 1 << 4;+        const HAS_RE_INFER                = 1 << 4;         /// Does this have [ConstKind::Infer]?-        const HAS_CT_INFER              = 1 << 5;+        const HAS_CT_INFER                = 1 << 5;          /// Does this have inference variables? Used to determine whether         /// inference is required.-        const NEEDS_INFER               = TypeFlags::HAS_TY_INFER.bits-                                        | TypeFlags::HAS_RE_INFER.bits-                                        | TypeFlags::HAS_CT_INFER.bits;+        const NEEDS_INFER                 = TypeFlags::HAS_TY_INFER.bits+                                          | TypeFlags::HAS_RE_INFER.bits+                                          | TypeFlags::HAS_CT_INFER.bits;          /// Does this have [Placeholder]?-        const HAS_TY_PLACEHOLDER        = 1 << 6;+        const HAS_TY_PLACEHOLDER          = 1 << 6;         /// Does this have [RePlaceholder]?-        const HAS_RE_PLACEHOLDER        = 1 << 7;+        const HAS_RE_PLACEHOLDER          = 1 << 7;         /// Does this have [ConstKind::Placeholder]?-        const HAS_CT_PLACEHOLDER        = 1 << 8;+        const HAS_CT_PLACEHOLDER          = 1 << 8;          /// `true` if there are "names" of regions and so forth         /// that are local to a particular fn/inferctxt-        const HAS_FREE_LOCAL_REGIONS    = 1 << 9;+        const HAS_FREE_LOCAL_REGIONS      = 1 << 9;          /// `true` if there are "names" of types and regions and so forth         /// that are local to a particular fn-        const HAS_FREE_LOCAL_NAMES      = TypeFlags::HAS_TY_PARAM.bits-                                        | TypeFlags::HAS_CT_PARAM.bits-                                        | TypeFlags::HAS_TY_INFER.bits-                                        | TypeFlags::HAS_CT_INFER.bits-                                        | TypeFlags::HAS_TY_PLACEHOLDER.bits-                                        | TypeFlags::HAS_CT_PLACEHOLDER.bits-                                        | TypeFlags::HAS_FREE_LOCAL_REGIONS.bits;+        const HAS_FREE_LOCAL_NAMES        = TypeFlags::HAS_TY_PARAM.bits+                                          | TypeFlags::HAS_CT_PARAM.bits+                                          | TypeFlags::HAS_TY_INFER.bits+                                          | TypeFlags::HAS_CT_INFER.bits+                                          | TypeFlags::HAS_TY_PLACEHOLDER.bits+                                          | TypeFlags::HAS_CT_PLACEHOLDER.bits+                                          | TypeFlags::HAS_FREE_LOCAL_REGIONS.bits;          /// Does this have [Projection] or [UnnormalizedProjection]?-        const HAS_TY_PROJECTION         = 1 << 10;+        const HAS_TY_PROJECTION           = 1 << 10;         /// Does this have [Opaque]?-        const HAS_TY_OPAQUE             = 1 << 11;+        const HAS_TY_OPAQUE               = 1 << 11;         /// Does this have [ConstKind::Unevaluated]?-        const HAS_CT_PROJECTION         = 1 << 12;+        const HAS_CT_PROJECTION           = 1 << 12;          /// Could this type be normalized further?-        const HAS_PROJECTION            = TypeFlags::HAS_TY_PROJECTION.bits-                                        | TypeFlags::HAS_TY_OPAQUE.bits-                                        | TypeFlags::HAS_CT_PROJECTION.bits;+        const HAS_PROJECTION              = TypeFlags::HAS_TY_PROJECTION.bits+                                          | TypeFlags::HAS_TY_OPAQUE.bits+                                          | TypeFlags::HAS_CT_PROJECTION.bits;          /// Present if the type belongs in a local type context.         /// Set for placeholders and inference variables that are not "Fresh".-        const KEEP_IN_LOCAL_TCX         = 1 << 13;+        const KEEP_IN_LOCAL_TCX           = 1 << 13;          /// Is an error type reachable?-        const HAS_TY_ERR                = 1 << 14;+        const HAS_TY_ERR                  = 1 << 14;          /// Does this have any region that "appears free" in the type?         /// Basically anything but [ReLateBound] and [ReErased].-        const HAS_FREE_REGIONS          = 1 << 15;+        const HAS_FREE_REGIONS            = 1 << 15;          /// Does this have any [ReLateBound] regions? Used to check         /// if a global bound is safe to evaluate.-        const HAS_RE_LATE_BOUND         = 1 << 16;+        const HAS_RE_LATE_BOUND           = 1 << 16;          /// Does this have any [ReErased] regions?-        const HAS_RE_ERASED             = 1 << 17;+        const HAS_RE_ERASED               = 1 << 17;++        /// Does this have require substitution, have inference variables or have projections and+        /// thus is still further specializable? This flag ignores the contribution of parent+        /// substitutions of closures.

Oh I forgot about this doc comment. It should be synced with the method doc comment and also the closure thing needs to be removed.

davidtwco

comment created time in 5 minutes

pull request commentrust-lang/rust

Use the niche optimization if other variant are small enough

I am not sure I understand this. I believe the current implementation will only use the Niche if it reduces the size of the enum.

Perhaps, but there's no formal proof of this and it's impossible to exhausively test, so we'd have to rely on convincing ourselves, and that's the main reason I kept putting this off: the conditions were too complex and hard to reason about, and they were also very easy to invalidate by other changes.

I want to land this, but I'm not comfortable with it unless one of these two things happen:

  • the implementation gets a formal model, where we can prove things about all possible cases
  • we check instead of assuming the conditions are sufficient

I'm thinking computing the second candidate would be a waste of time.

We can measure this, it's not uncommon in rustc to check all possibilities. Bonus: it would remove the need for complex logic that tries to approximate the comparison between the two candidates, and we could focus on things like using SmallVec instead of Vec, instead.

ogoffart

comment created time in 9 minutes

issue commentrust-lang/rust

Replace submodules with subtrees

@oli-obk @RalfJung What do you think of this logic? Just thought of it, not sure where to leave it.

git subtree pull is an injection, git subtree push is a projection, hence why pulling preserves commits verbatim (hash included) while pushing rewrites them to keep only the relevant parts. They're both fully information preserving for the subtree directory, and only for that directory.

oli-obk

comment created time in 29 minutes

pull request commentrust-lang/rust

Translate the virtual `/rustc/$hash` prefix back to a real directory.

Looks like the base toolchain is clean of lib/rustlib/src:

$ rustup-toolchain-install-master 40f2b445cd1c6c4e72d663d23c6d1bef2c674ad4
$ ls ~/.rustup/toolchains/40f2b445cd1c6c4e72d663d23c6d1bef2c674ad4/lib/rustlib/
etc/  x86_64-unknown-linux-gnu/

I'm rebasing now, after that I think we're good to go?

eddyb

comment created time in 41 minutes

issue commentrust-lang/rust

Make thread local accesses an `Rvalue` in MIR

Copying my https://github.com/rust-lang/rust/issues/70684#issuecomment-607660169 here (note "the address of a #[thread_local] static", not "access", the address itself is runtime): <hr/>

As I suggested elsewhere, I believe #[thread_local] statics should have their own separate access mechanism, probably their own Rvalue (or we could start extending what Rvalue::{Ref,RawPtr} can borrow).

That's because getting the address of a #[thread_local] static is a fundamentally runtime operation, and LLVM reusing the same syntax as for regular statics, is in the wrong here.

oli-obk

comment created time in an hour

issue commentrust-lang/rust

Rustdoc doesn't show src button for many functions in the rustc docs

Something rustdoc could be doing, though, is checking which CrateNum a file is imported from, and try to use that crate's doc URLs, or at the very least use a separate doc/src dir, e.g. instead of:

target/doc/src/test_70025/home/eddy/.rustup/toolchains/40f2b445cd1c6c4e72d663d23c6d1bef2c674ad4/lib/rustlib/src/rust/src/libstd/thread/local.rs.html

it should probably have created:

target/doc/src/std/thread/local.rs.html
bjorn3

comment created time in an hour

issue commentrust-lang/rust

Rustdoc doesn't show src button for many functions in the rustc docs

@Mark-Simulacrum Uh oh I can't get anything like https://doc.rust-lang.org/nightly/nightly-rustc even for regular nightly in rustup, and none of alloc/core/proc_macro/std/test are affected.

Also, since this seems to affect the whole crate, it's easier to spot at that level:

Other affected crates, that use implement_ty_decoder! to define impls:

And that's all the affected crates! Each uses macros from other crates, which define something.

<hr/>

thread_local! stands out as being from the standard library. Sure enough:

thread_local!(pub static FOO: bool = false);
$ cargo doc
 Documenting test-70025 v0.1.0 (/home/eddy/Projects/test-70025)
warning: source code was requested to be rendered, but processing `/rustc/76b11980ad416c3ad6143504c2277757ecacf9b5/src/libstd/thread/local.rs` had an error: "/rustc/76b11980ad416c3ad6143504c2277757ecacf9b5/src/libstd/thread/local.rs": No such file or directory (os error 2)
         skipping rendering of source code
    Finished dev [unoptimized + debuginfo] target(s) in 3.53s

But with #70642, it works:

$ rustup-toolchain-install-master 40f2b445cd1c6c4e72d663d23c6d1bef2c674ad4 -c rust-src
$ cargo +40f2b445cd1c6c4e72d663d23c6d1bef2c674ad4 doc
 Documenting test-70025 v0.1.0 (/home/eddy/Projects/test-70025)
    Finished dev [unoptimized + debuginfo] target(s) in 2.21s
$ find target/doc/src/ | rg html
target/doc/src/test_70025/lib.rs.html
target/doc/src/test_70025/home/eddy/.rustup/toolchains/40f2b445cd1c6c4e72d663d23c6d1bef2c674ad4/lib/rustlib/src/rust/src/libstd/thread/local.rs.html

However, I have no way to check the CI environment itself, so we'll have to wait for #70642 to land.

bjorn3

comment created time in an hour

issue commentrust-lang/rust

The miri engine may create pointers to thread locals

As I suggested elsewhere, I believe #[thread_local] statics should have their own separate access mechanism, probably their own Rvalue (or we could start extending what Rvalue::{Ref,RawPtr} can borrow).

That's because getting the address of a #[thread_local] static is a fundamentally runtime operation, and LLVM reusing the same syntax as for regular statics, is in the wrong here.

oli-obk

comment created time in 2 hours

pull request commentrust-lang/rust

Rename AssocKind::Method to AssocKind::Fn

r=me on the implementation, r? @estebank on the changed diagnostics

Rustin-Liu

comment created time in 3 hours

Pull request review commentrust-lang/rust

Rename AssocKind::Method to AssocKind::Fn

 fn print_disambiguation_help(         span,         &format!(             "disambiguate the {} for {}",-            kind.suggestion_descr(),+            kind.as_def_kind().descr(def_id),

Why do we still need the DefId? Is this one of those things where the DefKind is too imprecise? cc @mark-i-m

(not really relevant to this PR)

Rustin-Liu

comment created time in 3 hours

pull request commentrust-lang/rust

link with "libssp" on *-sun-solaris systems

r? @nagisa

jclulow

comment created time in 3 hours

delete branch eddyb/rust

delete branch : compiletest-stdout-fix

delete time in 3 hours

pull request commentrust-lang/rust

Miri: make backtrace function names and spans match up

Why are some frames not rendering code snippets? Is miri checking is_imported by any chance?

IMO for miri specifically, a full-source backtrace, no matter the crates each frame comes from (only requirement being that we can load the sources), would be good.

RalfJung

comment created time in 11 hours

Pull request review commentrust-lang/rust

Make the necessary changes to support concurrency in Miri.

 pub trait Machine<'mir, 'tcx>: Sized {         Ok(())     } -    /// Called for *every* memory access to determine the real ID of the given allocation.-    /// This provides a way for the machine to "redirect" certain allocations as it sees fit.+    /// Called for *every* memory access to determine the real ID of the given+    /// allocation. This provides a way for the machine to "redirect" certain+    /// allocations as it sees fit.     ///-    /// This is used by Miri to redirect extern statics to real allocations.+    /// This is used by Miri for two purposes:+    /// 1.  Redirecting extern statics to real allocations.+    /// 2.  Creating unique allocation ids for thread locals.

This reminds me we still need to make borrowing a thread-local static an Rvalue of its own.

It's fundamentally a runtime operation, even if LLVM's representation of it is misleading.

vakaras

comment created time in 11 hours

pull request commentrust-lang/rust

Renamed `PerDefTables` to `Tables`

r? @oli-obk

Lezzz

comment created time in 11 hours

pull request commentrust-lang/rust

Remove duplicated code in trait selection

I think that was intentional, from when these were split? At least some things could be exported though.

r? @nikomatsakis

estebank

comment created time in 11 hours

issue commentrust-lang/rust

Rustdoc doesn't show src button for many functions in the rustc docs

@Mark-Simulacrum Is there any way to use the try build on #70642 to check if it fixes this issue? i.e. does it include any docs?

bjorn3

comment created time in 12 hours

push eventeddyb/rust

Eduard-Mihai Burtescu

commit sha e1dbc835f253be8795e948795ce04f3df011feaf

Translate the virtual `/rustc/$hash` prefix back to a real directory.

view details

Eduard-Mihai Burtescu

commit sha aba2085c320dce63d45d31257a4194ddebf1d90b

tests: remove ignore directives from tests that mention core/alloc/std spans.

view details

push time in 13 hours

pull request commentrust-lang/rust

Translate the virtual `/rustc/$hash` prefix back to a real directory.

@ehuss It only points to the standard library to note some things, like trait/type definitions, IME, most diagnostic logic check is_imported, especially suggestions and lints.

You can search the test suite for $SRC_DIR, or just look at the diff of this PR, those are all the tests where libstd shows up. You'll get far more though, if you enable -Z macro-backtrace (which most tests don't).

<hr/>

Ideally we'd have a way to check inside the compiler if the sources are user-editable, and only emit suggestions then, does rustup make rust-src and Cargo its ~/.cargo/cache, read-only? That'd be a nice way to hint to rustc to never emit suggestions for those files (i.e. we could gate this inside the diagnostic code itself, instead of in every place where they're emitted).

Kind of hard to test though, unless we made some test files read-only through git?

Bonus: if a suggestion arises while building Rust itself, then it would be fine for to point to the standard library, in some situations (we'd also get this if Cargo hinted workespaces to rustc directly).

eddyb

comment created time in 13 hours

issue commentrust-lang/rust

Should enum discriminants have generics in scope?

I've just removed the ICE label, after reorganizing the issue description to indicate that the question in the title is the important part, and the ICE is just an example (bonus: the ICE becomes a regular error if we choose option 2, it's not exactly a bug, it's just not printed as a nice user error).

eddyb

comment created time in 14 hours

issue commentrust-lang/rust

Should enum discriminants have generics in scope?

@spastorino "requires nightly" is misleading, I'm only using #![feature(const_generics)] to bypass #43408 (enum discriminant expressions are in the same boat as array lengths today). I'll adjust the labels to match reality and reduce confusion.

More to the point: if we apply the #70452 treatment to enum discriminants (as a partial #43408 fix), then #![feature(const_generics)] won't be necessary.

<hr/>

Also, I've just realized that there is an example which compiles on nightly, I'll add it to the issue description:

#![feature(const_generics, arbitrary_enum_discriminant)]

#[repr(usize)]
enum MyWeirdOption<T> {
    None = 0,
    Some(T) = std::mem::size_of::<*mut *mut T>(),
}
eddyb

comment created time in 14 hours

Pull request review commentrust-lang/rust

add `STILL_FURTHER_SPECIALIZABLE` flag

 impl RegionKind {                 flags = flags | TypeFlags::HAS_FREE_LOCAL_REGIONS;                 flags = flags | TypeFlags::HAS_RE_INFER;                 flags = flags | TypeFlags::KEEP_IN_LOCAL_TCX;+                flags = flags | TypeFlags::STILL_FURTHER_SPECIALIZABLE;

I'm not worried about the unsound cases but rather things like impl Foo for for<'a> fn(&'a ()) vs impl<'a> Foo for fn(&'a ()) which AFAIK are both sound for specialization and still allowed as non-overlapping.

davidtwco

comment created time in 16 hours

Pull request review commentrust-lang/rust

Translate the virtual `/rustc/$hash` prefix back to a real directory.

 fn build_session_(         _ => CtfeBacktrace::Disabled,     }); +    // Try to find a directory containing the Rust `src`, for more details see+    // the doc comment on the `real_rust_source_base_dir` field.+    let compute_real_rust_source_base_dir = || {+        // A file we expect to find inside the `real_rust_source_base_dir`.+        const SRC_FILE_TO_PROBE_FOR: &str = "src/libstd/lib.rs";++        // First look in the location used by the `rust-src` `rustup` component.+        let sysroot_candidate = sysroot.join("lib/rustlib/src/rust");+        if sysroot_candidate.join(SRC_FILE_TO_PROBE_FOR).is_file() {+            return Some(sysroot_candidate);+        }++        // As a fallback, check if the `sysroot` is inside a Rust build dir,+        //  i.e. it ends in `build/$CFG_COMPILER_HOST_TRIPLE/stage{0-sysroot,1,2,3}`.+        let mut sysroot_components = sysroot.components();+        let last = sysroot_components.next_back()?.as_os_str();+        if last == "stage0-sysroot" || last == "stage1" || last == "stage2" || last == "stage3" {+            if sysroot_components.next_back()?.as_os_str() == host_triple {+                if sysroot_components.next_back()?.as_os_str() == "build" {

Yeah I'll be using the rustbuild function. Also, this will only affect CI and a tiny subset of people building Rust (either using remap-debuginfo = true like CI, or testing miri, if miri removes it hack). And won't break the build if symlinking fails.

eddyb

comment created time in 16 hours

PR opened rust-lang/rust

compiletest: don't use `std::io::stdout()`, as it bypasses `set_print`.

This PR undoes a change made during #69916, which became unnecessary during review but was left in by accident, and which isn't correct due to libtest using std::io::set_print, which overwrites the println! behavior but not writeln!(std::io::stdout(), ...).

The effect of using writeln!(std::io::stdout(), ...) was that the diff output would show while running the tests, instead of at the end, when failing tests are listed.

r? @Mark-Simulacrum cc @oli-obk

+4 -8

0 comment

1 changed file

pr created time in 17 hours

create barncheddyb/rust

branch : compiletest-stdout-fix

created branch time in 17 hours

Pull request review commentrust-lang/rust

Enable blessing of mir opt tests

 impl<'test> TestCx<'test> {                 println!("normalized {}:\n{}\n", kind, actual);             } else {                 println!("diff of {}:\n", kind);-                let diff_results = make_diff(expected, actual, 3);-                for result in diff_results {-                    let mut line_number = result.line_number;-                    for line in result.lines {-                        match line {-                            DiffLine::Expected(e) => {-                                println!("-\t{}", e);

Turns out the changes here are unnecessary, there's only write_diff caller, and I've just tested a fix, will open a PR shortly.

oli-obk

comment created time in 17 hours

Pull request review commentrust-lang/rust

Translate the virtual `/rustc/$hash` prefix back to a real directory.

 fn build_session_(         _ => CtfeBacktrace::Disabled,     }); +    // Try to find a directory containing the Rust `src`, for more details see+    // the doc comment on the `real_rust_source_base_dir` field.+    let compute_real_rust_source_base_dir = || {+        // A file we expect to find inside the `real_rust_source_base_dir`.+        const SRC_FILE_TO_PROBE_FOR: &str = "src/libstd/lib.rs";++        // First look in the location used by the `rust-src` `rustup` component.+        let sysroot_candidate = sysroot.join("lib/rustlib/src/rust");+        if sysroot_candidate.join(SRC_FILE_TO_PROBE_FOR).is_file() {+            return Some(sysroot_candidate);+        }++        // As a fallback, check if the `sysroot` is inside a Rust build dir,+        //  i.e. it ends in `build/$CFG_COMPILER_HOST_TRIPLE/stage{0-sysroot,1,2,3}`.+        let mut sysroot_components = sysroot.components();+        let last = sysroot_components.next_back()?.as_os_str();+        if last == "stage0-sysroot" || last == "stage1" || last == "stage2" || last == "stage3" {+            if sysroot_components.next_back()?.as_os_str() == host_triple {+                if sysroot_components.next_back()?.as_os_str() == "build" {

@RalfJung Oh wow I wasn't aware of that hack, I wonder if other tools also do this. Yes, although I'm not sure what will happen on Windows. However, std::os::windows::fs::symlink_dir does exist, presumably it creates a NTFS "junction"?

So we might be set on all platforms we care about, barring any odd filesystems where symlinks aren't supported or banned by system policy.

eddyb

comment created time in 17 hours

Pull request review commentrust-lang/rust

Rename AssocKind::Method to AssocKind::Fn

 impl AssocItem {     pub fn def_kind(&self) -> DefKind {

This should probably be on AssocKind (and renamed to as_def_kind).

Rustin-Liu

comment created time in 17 hours

Pull request review commentrust-lang/rust

Rename AssocKind::Method to AssocKind::Fn

 pub struct AssocItem {     pub container: AssocItemContainer,      /// Whether this is a method with an explicit self-    /// as its first argument, allowing method calls.-    pub method_has_self_argument: bool,+    /// as its first parameter, allowing method calls.+    pub fn_has_self_parameter: bool, }  #[derive(Copy, Clone, PartialEq, Debug, HashStable)] pub enum AssocKind {     Const,-    Method,+    Fn,     OpaqueTy,     Type, }  impl AssocKind {     pub fn suggestion_descr(&self) -> &'static str {         match self {-            ty::AssocKind::Method => "method call",+            ty::AssocKind::Fn => "method call",             ty::AssocKind::Type | ty::AssocKind::OpaqueTy => "associated type",             ty::AssocKind::Const => "associated constant",

But that wouldn't make sense for the other variants, which is why I'm confused.

Okay I just checked and we should be able to change this to "associated function". Which means suggestion_descr users could instead use .as_def_kind().descr().

Rustin-Liu

comment created time in 17 hours

pull request commentrust-lang/rust

Remove unused discriminant reads from MIR bodies

@bors r- I still want the change for checking p.local == local.

wesleywiser

comment created time in 17 hours

Pull request review commentrust-lang/rust

Remove unused discriminant reads from MIR bodies

 impl<'a, 'tcx> Visitor<'tcx> for DeclMarker<'a, 'tcx> {                             }                         }                     }+                } else if let StatementKind::Assign(box (p, Rvalue::Discriminant(d))) = &stmt.kind {+                    if !p.is_indirect() {+                        trace!("skipping store of discriminant value {:?} to {:?}", d, p);

I'm struggling to think of a case where that would happen. Do you have an example in mind?

The point is to check instead of assuming, especially in this case where it's basically free. If nothing else it serves as self-documenting code.

wesleywiser

comment created time in 17 hours

Pull request review commentrust-lang/rust

Translate the virtual `/rustc/$hash` prefix back to a real directory.

 fn build_session_(         _ => CtfeBacktrace::Disabled,     }); +    // Try to find a directory containing the Rust `src`, for more details see+    // the doc comment on the `real_rust_source_base_dir` field.+    let compute_real_rust_source_base_dir = || {+        // A file we expect to find inside the `real_rust_source_base_dir`.+        const SRC_FILE_TO_PROBE_FOR: &str = "src/libstd/lib.rs";++        // First look in the location used by the `rust-src` `rustup` component.+        let sysroot_candidate = sysroot.join("lib/rustlib/src/rust");+        if sysroot_candidate.join(SRC_FILE_TO_PROBE_FOR).is_file() {+            return Some(sysroot_candidate);+        }++        // As a fallback, check if the `sysroot` is inside a Rust build dir,+        //  i.e. it ends in `build/$CFG_COMPILER_HOST_TRIPLE/stage{0-sysroot,1,2,3}`.+        let mut sysroot_components = sysroot.components();+        let last = sysroot_components.next_back()?.as_os_str();+        if last == "stage0-sysroot" || last == "stage1" || last == "stage2" || last == "stage3" {+            if sysroot_components.next_back()?.as_os_str() == host_triple {+                if sysroot_components.next_back()?.as_os_str() == "build" {

Hm, why would we want the symlink approach over an environment variable read or something (at runtime, I guess, set during our tests?)

Because rustup places rust-src in a certain directory, and presumably distros can too, so we'd want to use that, and using a symlink would transparently let that work for local build sysroots, without adding an insta-stable env var.

and we can make it optional I think, in the sense that you need it for tests to pass but if you don't have it things won't fail to build entirely.

Ah, good point, do we have a way for src/bootstrap to emit a warning if it tried something and that failed? I'm thinking I would try to create the symlink, then do the same check rustc does (look for src/libstd/lib.rs inside there), and if either fails, warn instead of failing the build.

eddyb

comment created time in 18 hours

Pull request review commentrust-lang/rust

Explain how to work with subtree

 with one another are rolled up. Speaking of tests, Rust has a comprehensive test suite. More information about it can be found [here][rctd]. -### External Dependencies+### External Dependencies (subtree)++As a developer to this repository, you don't have to treat the following external projects+differently from other crates that are directly in this repo:++* none so far, see https://github.com/rust-lang/rust/issues/70651 for more info++They are just regular files and directories. This is in contrast to `submodule` dependencies+(see below for those). Only tool authors will actually use any operations here.++#### Synchronizing a subtree++There are two synchronization directions: `subtree push` and `subtree pull`.++`git subtree push -P src/tools/clippy https://github.com/rust-lang/rust-clippy.git`++takes all the changes that+happened to the copy in this repo and creates commits on the remote repo that match the local

AFAICT, each commit is copied to the other side verbatim (even the hash is the same, at least for pull, not sure about push), then a single "subtree merge commit" is added which places the changes at the right prefix (when pulling) or removes the prefix (when pushing).

oli-obk

comment created time in 18 hours

pull request commentrust-lang/rust

add `STILL_FURTHER_SPECIALIZABLE` flag

@bors r+

davidtwco

comment created time in 18 hours

Pull request review commentrust-lang/rust

add `STILL_FURTHER_SPECIALIZABLE` flag

 pub trait TypeFoldable<'tcx>: fmt::Debug + Clone {         self.has_type_flags(TypeFlags::HAS_RE_LATE_BOUND)     } +    /// Indicates whether this value is further_specializable.

"whether this value still has parameters/placeholders/inference variables which could be replaced later, in a way that would change the results of impl specialization"

davidtwco

comment created time in 18 hours

Pull request review commentrust-lang/rust

add `STILL_FURTHER_SPECIALIZABLE` flag

 impl RegionKind {                 flags = flags | TypeFlags::HAS_FREE_LOCAL_REGIONS;                 flags = flags | TypeFlags::HAS_RE_INFER;                 flags = flags | TypeFlags::KEEP_IN_LOCAL_TCX;+                flags = flags | TypeFlags::STILL_FURTHER_SPECIALIZABLE;

Hmm, I'm not sure on lifetimes affecting specialization, but it's probably good to keep this in, just in case there are edge cases around higher-ranked fn pointer types.

davidtwco

comment created time in 18 hours

Pull request review commentrust-lang/rust

add `STILL_FURTHER_SPECIALIZABLE` flag

 impl<'tcx> ClosureSubsts<'tcx> {         self.substs.len() >= 3 && matches!(self.split().tupled_upvars_ty.expect_ty().kind, Tuple(_))     } +    /// Returns the substitutions of the closure's parent.+    pub fn parent_substs(self) -> &'tcx [GenericArg<'tcx>] {

All of these changes as well, can be kept in the PR that uses them.

davidtwco

comment created time in 18 hours

Pull request review commentrust-lang/rust

add `STILL_FURTHER_SPECIALIZABLE` flag

 impl FlagComputation {              &ty::Param(_) => {                 self.add_flags(TypeFlags::HAS_TY_PARAM);+                self.add_flags(TypeFlags::STILL_FURTHER_SPECIALIZABLE);             }              &ty::Generator(_, ref substs, _) => {-                self.add_substs(substs);

Can you undo these changes here, to minimize the diff?

davidtwco

comment created time in 18 hours

Pull request review commentrust-lang/rust

add `STILL_FURTHER_SPECIALIZABLE` flag

 impl FlagComputation {             }              &ty::Closure(_, ref substs) => {-                self.add_substs(substs);

Same here.

davidtwco

comment created time in 18 hours

issue commentrust-lang/rust

Replace calls to has_local_value with needs_infer.

Okay I've looked at all needs_infer uses, these are the interesting ones:

  1. this one is super weird, I think it refers to something that doesn't exist anymore? https://github.com/rust-lang/rust/blob/99009bf31992fb9257b84550dbf7cb509f987952/src/librustc_infer/infer/resolve.rs#L184-L228

  2. the specialization check I mentioned, which @davidtwco will open a PR to replace: https://github.com/rust-lang/rust/blob/99009bf31992fb9257b84550dbf7cb509f987952/src/librustc_trait_selection/traits/project.rs#L1053-L1057

  3. select, which I believe likely wants to know about fresh variables too? https://github.com/rust-lang/rust/blob/99009bf31992fb9257b84550dbf7cb509f987952/src/librustc_trait_selection/traits/select.rs#L1110-L1122 used here: https://github.com/rust-lang/rust/blob/99009bf31992fb9257b84550dbf7cb509f987952/src/librustc_trait_selection/traits/select.rs#L2032-L2071

eddyb

comment created time in 19 hours

Pull request review commentrust-lang/rust

Translate the virtual `/rustc/$hash` prefix back to a real directory.

 fn build_session_(         _ => CtfeBacktrace::Disabled,     }); +    // Try to find a directory containing the Rust `src`, for more details see+    // the doc comment on the `real_rust_source_base_dir` field.+    let compute_real_rust_source_base_dir = || {+        // A file we expect to find inside the `real_rust_source_base_dir`.+        const SRC_FILE_TO_PROBE_FOR: &str = "src/libstd/lib.rs";++        // First look in the location used by the `rust-src` `rustup` component.+        let sysroot_candidate = sysroot.join("lib/rustlib/src/rust");+        if sysroot_candidate.join(SRC_FILE_TO_PROBE_FOR).is_file() {+            return Some(sysroot_candidate);+        }++        // As a fallback, check if the `sysroot` is inside a Rust build dir,+        //  i.e. it ends in `build/$CFG_COMPILER_HOST_TRIPLE/stage{0-sysroot,1,2,3}`.+        let mut sysroot_components = sysroot.components();+        let last = sysroot_components.next_back()?.as_os_str();+        if last == "stage0-sysroot" || last == "stage1" || last == "stage2" || last == "stage3" {+            if sysroot_components.next_back()?.as_os_str() == host_triple {+                if sysroot_components.next_back()?.as_os_str() == "build" {

Bonus: it would make cargo's -Z build-std and presumably RLS, able to find the Rust sources, for locally built rustup toolchains.

eddyb

comment created time in 19 hours

Pull request review commentrust-lang/rust

Translate the virtual `/rustc/$hash` prefix back to a real directory.

 fn build_session_(         _ => CtfeBacktrace::Disabled,     }); +    // Try to find a directory containing the Rust `src`, for more details see+    // the doc comment on the `real_rust_source_base_dir` field.+    let compute_real_rust_source_base_dir = || {+        // A file we expect to find inside the `real_rust_source_base_dir`.+        const SRC_FILE_TO_PROBE_FOR: &str = "src/libstd/lib.rs";++        // First look in the location used by the `rust-src` `rustup` component.+        let sysroot_candidate = sysroot.join("lib/rustlib/src/rust");+        if sysroot_candidate.join(SRC_FILE_TO_PROBE_FOR).is_file() {+            return Some(sysroot_candidate);+        }++        // As a fallback, check if the `sysroot` is inside a Rust build dir,+        //  i.e. it ends in `build/$CFG_COMPILER_HOST_TRIPLE/stage{0-sysroot,1,2,3}`.+        let mut sysroot_components = sysroot.components();+        let last = sysroot_components.next_back()?.as_os_str();+        if last == "stage0-sysroot" || last == "stage1" || last == "stage2" || last == "stage3" {+            if sysroot_components.next_back()?.as_os_str() == host_triple {+                if sysroot_components.next_back()?.as_os_str() == "build" {

We might want to do the symlink approach instead then, where src/bootstrap symlinks the checkout to build/$triple/stage{0-sysroot,1,2,3}/lib/rustlib/src/rust.

I just don't know what we'll have to do on platforms where that's not directly an option.

eddyb

comment created time in 19 hours

issue commentrust-lang/rust

Replace calls to has_local_value with needs_infer.

@nikomatsakis What would you prefer we do to "fresh variables"? Does anything rely on needs_infer returning true for them?

I guess there's at least one place where we want to check if any types or consts could be later replaced ("is further specializable" type checks), but @davidtwco is adding a special flag for that. I think right now the check omits ty::Bound and ty::Placeholder (because it checks needs_infer() || needs_substs()), which seems wrong.

I'll have to do an audit of all uses of needs_infer, I think. @lcnr let's coordinate on Zulip.

eddyb

comment created time in 19 hours

Pull request review commentrust-lang/rust

Rename AssocKind::Method to AssocKind::Fn

 impl<'a, 'tcx> LinkCollector<'a, 'tcx> {                     .filter_by_name_unhygienic(item_name)                     .next()                     .and_then(|item| match item.kind {-                        ty::AssocKind::Method => Some("method"),+                        ty::AssocKind::Fn => Some("fn"),

Same here, keep "method".

Rustin-Liu

comment created time in 19 hours

Pull request review commentrust-lang/rust

Rename AssocKind::Method to AssocKind::Fn

 impl<'a, 'tcx> LinkCollector<'a, 'tcx> {                         .map(|item| cx.tcx.associated_item(*item))                         .find(|item| item.ident.name == item_name);                     if let Some(item) = item {-                        let kind = match item.kind {-                            ty::AssocKind::Const if ns == ValueNS => "associatedconstant",-                            ty::AssocKind::Type if ns == TypeNS => "associatedtype",-                            ty::AssocKind::Method if ns == ValueNS => {-                                if item.defaultness.has_value() { "method" } else { "tymethod" }-                            }-                            _ => return self.variant_field(path_str, current_item, module_id),-                        };+                        let kind =+                            match item.kind {+                                ty::AssocKind::Const if ns == ValueNS => "associatedconstant",+                                ty::AssocKind::Type if ns == TypeNS => "associatedtype",+                                ty::AssocKind::Fn if ns == ValueNS => {+                                    if item.defaultness.has_value() { "fn" } else { "tyfn" }

(these show up in Rust docs URLs)

Rustin-Liu

comment created time in 19 hours

Pull request review commentrust-lang/rust

Rename AssocKind::Method to AssocKind::Fn

 impl<'a, 'tcx> LinkCollector<'a, 'tcx> {                         .map(|item| cx.tcx.associated_item(*item))                         .find(|item| item.ident.name == item_name);                     if let Some(item) = item {-                        let kind = match item.kind {-                            ty::AssocKind::Const if ns == ValueNS => "associatedconstant",-                            ty::AssocKind::Type if ns == TypeNS => "associatedtype",-                            ty::AssocKind::Method if ns == ValueNS => {-                                if item.defaultness.has_value() { "method" } else { "tymethod" }-                            }-                            _ => return self.variant_field(path_str, current_item, module_id),-                        };+                        let kind =+                            match item.kind {+                                ty::AssocKind::Const if ns == ValueNS => "associatedconstant",+                                ty::AssocKind::Type if ns == TypeNS => "associatedtype",+                                ty::AssocKind::Fn if ns == ValueNS => {+                                    if item.defaultness.has_value() { "fn" } else { "tyfn" }

Can you keep the old names here? We've tried not to fix this in the past even though we could have.

Rustin-Liu

comment created time in 19 hours

Pull request review commentrust-lang/rust

Rename AssocKind::Method to AssocKind::Fn

 pub struct AssocItem {     pub container: AssocItemContainer,      /// Whether this is a method with an explicit self-    /// as its first argument, allowing method calls.-    pub method_has_self_argument: bool,+    /// as its first parameter, allowing method calls.+    pub fn_has_self_parameter: bool, }  #[derive(Copy, Clone, PartialEq, Debug, HashStable)] pub enum AssocKind {     Const,-    Method,+    Fn,     OpaqueTy,     Type, }  impl AssocKind {     pub fn suggestion_descr(&self) -> &'static str {         match self {-            ty::AssocKind::Method => "method call",+            ty::AssocKind::Fn => "method call",             ty::AssocKind::Type | ty::AssocKind::OpaqueTy => "associated type",             ty::AssocKind::Const => "associated constant",

I have no idea why it says "call", or why that makes sense.

Rustin-Liu

comment created time in 19 hours

issue commentrust-lang/rust

Replace submodules with subtrees

git subtree is upstream, which is nice, and it also supports preserving the commits better. I believe the "rebase failures" that git subrepo talks about are actually an anti-pattern: rebasing a merge commit, it's not meant to work at all.

git subrepo seems to want to just throw all the changes into single commits so you "don't have to deal with it", whereas git subtree is more history-preserving-oriented, which I prefer.

oli-obk

comment created time in 19 hours

Pull request review commentrust-lang/rust

Remove unused discriminant reads from MIR bodies

 impl<'a, 'tcx> Visitor<'tcx> for DeclMarker<'a, 'tcx> {                             }                         }                     }+                } else if let StatementKind::Assign(box (p, Rvalue::Discriminant(d))) = &stmt.kind {+                    if !p.is_indirect() {+                        trace!("skipping store of discriminant value {:?} to {:?}", d, p);

This confused me at first, but basically this is treating certain initializers as not keeping the destination alive, right? Something very important in these checks though: you need to make sure p.local is local otherwise it may be somewhere else in the statement (you shouldn't trust ctx to let you know where it is, IMO).

Also, it would be nice if if let StatementKind::Assign(box (p, was only once, and then the only check for the Rvalue was whether we consider it to have side-effects.

Also, does this pass re-run itself to fixpoint? Because if you remove an assignment to a dead local, you remove uses of other locals also mentioned in that assignment, which may be their last.

You can't do this in one pass because e.g. in x = y, y might be unused only if x is unused, and you can't know that ahead of time.

wesleywiser

comment created time in 20 hours

pull request commentrust-lang/rust

Make clippy a git subtree instead of a git submodule

r? @Mark-Simulacrum for the src/bootstrap changes

oli-obk

comment created time in 20 hours

issue commentrust-lang/rust

Replace submodules with subtrees

In case it gets lost on the PR, I said: https://github.com/rust-lang/rust/pull/70655#issuecomment-607240782

Whoa, clippy commit hashes were kept intact, this makes me really happy!11

oli-obk

comment created time in 20 hours

pull request commentrust-lang/rust

Make clippy a git subtree instead of a git submodule

Whoa, clippy commit hashes were kept intact, this makes me really happy!11

oli-obk

comment created time in 20 hours

issue commentrust-lang/rust

Replace submodules with subrepos

Hmm, I was led to believe that git subrepo was nesting git repositories, in a way which git natively handles. But it turns out it's just a monorepo sync tool, same as manually making large commits. I don't think losing commit history is acceptable.

At a glance, git subtree looks like it might do the right thing, i.e. keep the repository nesting of a submodule, but I haven't tried it yet to see how it actually behaves in practice.

oli-obk

comment created time in 21 hours

Pull request review commentrust-lang/rust

Rename AssocKind::Method to AssocKind::Fn

 impl<'a, 'tcx> FnCtxt<'a, 'tcx> {     // This function checks if the method isn't static and takes other arguments than `self`.

The doc comment suggests to me this function is misused, because it doesn't actually check that. It doesn't check fn_has_self_parameter at all.

Rustin-Liu

comment created time in 21 hours

Pull request review commentrust-lang/rust

Rename AssocKind::Method to AssocKind::Fn

 fn compare_type_predicate_entailment( fn assoc_item_kind_str(impl_item: &ty::AssocItem) -> &'static str {     match impl_item.kind {         ty::AssocKind::Const => "const",-        ty::AssocKind::Method => "method",+        ty::AssocKind::Fn => "method",

Another mention of "method", although this entire module might need a thorough de-method-izing.

Rustin-Liu

comment created time in 21 hours

Pull request review commentrust-lang/rust

Rename AssocKind::Method to AssocKind::Fn

 fn associated_item_from_trait_item_ref(     let def_id = tcx.hir().local_def_id(trait_item_ref.id.hir_id);     let (kind, has_self) = match trait_item_ref.kind {         hir::AssocItemKind::Const => (ty::AssocKind::Const, false),-        hir::AssocItemKind::Method { has_self } => (ty::AssocKind::Method, has_self),+        hir::AssocItemKind::Method { has_self } => (ty::AssocKind::Fn, has_self),

hir::AssocItemKind also seems to still be using Method.

Rustin-Liu

comment created time in 21 hours

Pull request review commentrust-lang/rust

Rename AssocKind::Method to AssocKind::Fn

 pub struct AssocItem {     pub container: AssocItemContainer,      /// Whether this is a method with an explicit self-    /// as its first argument, allowing method calls.-    pub method_has_self_argument: bool,+    /// as its first parameter, allowing method calls.+    pub fn_has_self_parameter: bool, }  #[derive(Copy, Clone, PartialEq, Debug, HashStable)] pub enum AssocKind {     Const,-    Method,+    Fn,     OpaqueTy,     Type, }  impl AssocKind {     pub fn suggestion_descr(&self) -> &'static str {         match self {-            ty::AssocKind::Method => "method call",+            ty::AssocKind::Fn => "method call",             ty::AssocKind::Type | ty::AssocKind::OpaqueTy => "associated type",             ty::AssocKind::Const => "associated constant",

These don't seem consistent, where would "method call" and "associated constant" both work?.

Rustin-Liu

comment created time in 21 hours

pull request commentrust-lang/rust

Translate the virtual `/rustc/$hash` prefix back to a real directory.

@RalfJung 57 files mention $SRC_DIR, out of which 56 are the tests that were failing before this PR and the last one is the implementation in src/tools/compiletest/src/runtest.rs.

eddyb

comment created time in a day

Pull request review commentrust-lang/rust

Translate the virtual `/rustc/$hash` prefix back to a real directory.

 impl Build {         self.config.jobs.unwrap_or_else(|| num_cpus::get() as u32)     } -    fn debuginfo_map(&self, which: GitRepo) -> Option<String> {+    fn debuginfo_map_to(&self, which: GitRepo) -> Option<String> {         if !self.config.rust_remap_debuginfo {             return None;         } -        let path = match which {+        match which {             GitRepo::Rustc => {                 let sha = self.rust_sha().unwrap_or(channel::CFG_RELEASE_NUM);-                format!("/rustc/{}", sha)+                Some(format!("/rustc/{}", sha))             }-            GitRepo::Llvm => String::from("/rustc/llvm"),-        };-        Some(format!("{}={}", self.src.display(), path))+            GitRepo::Llvm => Some(String::from("/rustc/llvm")),+        }

I tend to do that for my own code, wasn't sure if it would be proper inside the Rust codebase.

eddyb

comment created time in a day

pull request commentrust-lang/rust

Translate the virtual `/rustc/$hash` prefix back to a real directory.

@bors try @rust-timer queue (this might need further optimization)

eddyb

comment created time in a day

pull request commentrust-lang/rust

Add `can_unwind` field to `FnAbi`

@bors r+

wesleywiser

comment created time in a day

PR opened rust-lang/rust

Translate the virtual `/rustc/$hash` prefix back to a real directory.

Closes #53486 and fixes #53081, by undoing the remapping to /rustc/$hash on the fly, when appropriate (e.g. our testsuites, or user crates that depend on libstd), but not during the Rust build itself (as that could leak the absolute build directory into the artifacts, breaking deterministic builds).

Tested locally by setting remap-debuginfo = true in config.toml, which without these changes, was causing 56 tests to fail (see https://github.com/rust-lang/rust/issues/53081#issuecomment-606703215 for more details).

cc @Mark-Simulacrum @alexcrichton @ehuss

+338 -602

0 comment

169 changed files

pr created time in a day

create barncheddyb/rust

branch : remap-sysroot-src

created branch time in a day

Pull request review commentrust-lang/rust

Enable blessing of mir opt tests

 impl<'test> TestCx<'test> {                 println!("normalized {}:\n{}\n", kind, actual);             } else {                 println!("diff of {}:\n", kind);-                let diff_results = make_diff(expected, actual, 3);-                for result in diff_results {-                    let mut line_number = result.line_number;-                    for line in result.lines {-                        match line {-                            DiffLine::Expected(e) => {-                                println!("-\t{}", e);

Ahh, compiletest is getting that behavior from libtest, that's what I was missing, thanks! Yeah so worst case we can buffer into a String and println! that instead of using std::io::stdout.

oli-obk

comment created time in a day

Pull request review commentrust-lang/rust

Got rid of repetitions (such as rustc_ast::ast::) in librustc_ast.

 impl<'a, 'tcx> FnCtxt<'a, 'tcx> {                 // from the directly following item.                 let additional_newline = if found_use { "" } else { "\n" };                 format!(-                    "use {};\n{}",+                    "use rustc_ast::{};\n{}",

Ah, heh, found the reason for the failures.

Lezzz

comment created time in a day

pull request commentrust-lang/rust

Got rid of repetitions (such as rustc_ast::ast::) in librustc_ast.

Uhh why would the reexport cause suggestions to be affected?!

7	   = help: items from traits can only be used if the trait is in scope
8	help: the following trait is implemented but not in scope; perhaps add a `use` for it:
9	   |
-	LL | use std::os::unix::process::CommandExt;
+	LL | use rustc_ast::std::os::unix::process::CommandExt;
Lezzz

comment created time in a day

Pull request review commentrust-lang/rust

Enable blessing of mir opt tests

 impl<'test> TestCx<'test> {                 println!("normalized {}:\n{}\n", kind, actual);             } else {                 println!("diff of {}:\n", kind);-                let diff_results = make_diff(expected, actual, 3);-                for result in diff_results {-                    let mut line_number = result.line_number;-                    for line in result.lines {-                        match line {-                            DiffLine::Expected(e) => {-                                println!("-\t{}", e);

Okay this is weird, but apparently println! in compiletest is not equivalent to writing to std::io::stdout(), what's happening now is that the diff is printed while the tests run, and then the output after the tests run looks like this:

diff of stderr:


The actual stderr differed from the expected stderr.
oli-obk

comment created time in a day

issue commentdavidbarsky/tracing-tree

feature: Draw lines

Sure, but also note that you shouldn't combine box-drawing characters with regular pipes (|) or dashes (-) since they won't connect, you need to use the appropriate box-drawing character that looks like what you want.

hawkw

comment created time in 2 days

issue commentdavidbarsky/tracing-tree

feature: Draw lines

@hawkw pointed me to the tree output, so I've come up with two variations based on it:

hawkw

comment created time in 2 days

issue commentdavidbarsky/tracing-tree

feature: Draw lines

Tried something slightly different: example-4 and then spent too much staring at https://en.wikipedia.org/wiki/Box_Drawing_(Unicode_block), resulting in example-5.

hawkw

comment created time in 2 days

pull request commentrust-lang/rust

Add hash of source files in debug info

@bors r+ (assuming @nikomatsakis' "intent to merge" applies)

arlosi

comment created time in 2 days

issue commentdavidbarsky/tracing-tree

feature: Draw lines

Brought back the two-space indentation, now that it's clearer where it should go: example-3.

hawkw

comment created time in 2 days

issue commentdavidbarsky/tracing-tree

feature: Draw lines

This is what the example in the README would look like with the approach I had back in the day, in some C++ codebase: example-1 (GitHub's treatment of monospace still doesn't correctly handle unicode box-drawing, so I had to improvize)

Looking at it, this is probably slightly more readable: example-2.

hawkw

comment created time in 2 days

Pull request review commentrust-lang/rust

Remove -Z no-landing-pads flag

 impl Session {     }      pub fn no_landing_pads(&self) -> bool {-        self.opts.debugging_opts.no_landing_pads || self.panic_strategy() == PanicStrategy::Abort+        self.panic_strategy() == PanicStrategy::Abort     }

I don't mean in terms of performance, only code organization. The reason these methods exist is because the conditions they check are non-trivial, otherwise options should be checked directly.

Amanieu

comment created time in 2 days

Pull request review commentrust-lang/rust

Got rid of repetitions (such as rustc_ast::ast::) in librustc_ast.

-//! The Rust parser and macro expander.+//! The Rust abstract syntax tree module.

Eugh, we were hoping it would show up as a rename from ast.rs to lib.rs, this git failure mode is annoying.

Also, there's no "everything else", AFAIK there's just data types and sub modules.

Lezzz

comment created time in 2 days

Pull request review commentrust-lang/rust

Remove -Z no-landing-pads flag

 impl Session {     }      pub fn no_landing_pads(&self) -> bool {-        self.opts.debugging_opts.no_landing_pads || self.panic_strategy() == PanicStrategy::Abort+        self.panic_strategy() == PanicStrategy::Abort     }

I wonder if this should be inlined or not.

Amanieu

comment created time in 2 days

issue commentrust-lang/rust

build.rs "rerun-if-env-changed" goes out of sync with the actual use site of the env var.

@Mark-Simulacrum hmm I wonder if abusing the .d file format (from --emit=dep-info) or encoding this extra info in a comment, would be a good idea.

eddyb

comment created time in 2 days

issue commentrust-lang/rust

sysroot spans are not printed on some targets (affected: Debian, rust-lang's own i586; unaffected: Fedora)

I took a deeper look at this, and the simplest approach for fixing #53486 won't directly fix this. Or rather, won't fix running tests with remap-debuginfo = true in config.toml.

That's because there's no equivalent to the rust-src rustup component, for the stage{1,2} sysroots that exist while building/testing Rust. We could use a symlink to the real src directory, but I don't think that's supported on all platforms we build on (Windows and/or certain filesystems, AFAIK).

I'll work around that by removing a build/$CFG_COMPILER_HOST_TRIPLE/stage{0-sysroot,1,2} suffix from the sysroot, instead of adding lib/rustlib/src/rust (but only if the latter fails).

I'm also worried this might leak into codegen and cause non-deterministic builds, so we might have to do it only for loading the contents and diagnostics, or probably just gate the rewriting on --remap-path-prefix not being set to rewrite to the same /rustc/$HASH/ that rustc is rewriting to.

<hr/>

For the longest time I was confused and thought this needed "distcheck" to reproduce, but it's really just remap-debuginfo = true, which causes 56 tests to fail for ./x.py test --stage 1 src/test/ui, all of which mention this issue.

The remaining (non-failing) 26 tests that mention the issue are all src/test/ui/derives/derives-span-*.rs (except the Hash ones, since those are part of the failing 56), because src/etc/generate-deriving-span-tests.py generates the // ignores for all of them, even the ones that don't need it.

infinity0

comment created time in 2 days

pull request commentrust-lang/rust

rustc_target::abi: rename FieldPlacement to FieldsShape.

r? @oli-obk cc @RalfJung

anyska

comment created time in 2 days

Pull request review commentrust-lang/rust

Add `can_unwind` field to `FnAbi`

 impl<'tcx> FnAbiLlvmExt<'tcx> for FnAbi<'tcx, Ty<'tcx>> {         if cconv != llvm::CCallConv {             llvm::SetInstructionCallConv(callsite, cconv);         }++        // FIXME(wesleywiser, eddyb): We should apply `nounwind` as appropriate to this callsite.

Could also mention noreturn since I believe they're in a similar situation.

wesleywiser

comment created time in 2 days

Pull request review commentrust-lang/rust

Add `can_unwind` field to `FnAbi`

 impl<'tcx> FnAbiLlvmExt<'tcx> for FnAbi<'tcx, Ty<'tcx>> {             llvm::Attribute::NoReturn.apply_llfn(llvm::AttributePlace::Function, llfn);         } +        unwind(llfn, self.can_unwind);

You don't need a separate function, IMO it's more readable if it looks like the noreturn code.

wesleywiser

comment created time in 2 days

Pull request review commentrust-lang/rust

Add `can_unwind` field to `FnAbi`

 impl<'tcx> FnAbiLlvmExt<'tcx> for FnAbi<'tcx, Ty<'tcx>> {             llvm::Attribute::NoReturn.apply_llfn(llvm::AttributePlace::Function, llfn);         } +        unwind(llfn, self.can_unwind);

You can also add a comment like NoReturn has.

wesleywiser

comment created time in 2 days

Pull request review commentrust-lang/rust

Add `can_unwind` field to `FnAbi`

 impl<'tcx> FnAbiLlvmExt<'tcx> for FnAbi<'tcx, Ty<'tcx>> {         if cconv != llvm::CCallConv {             llvm::SetInstructionCallConv(callsite, cconv);         }++        // FIXME(wesleywiser, eddyb): We should apply `nounwind` as appropriate to this callsite.

Can you move this to the top of the function? That's where it is in the other one.

wesleywiser

comment created time in 2 days

Pull request review commentrust-lang/rust

Renamed `PerDefTables` to `Tables`

 impl<'tcx> EncodeContext<'tcx> {             println!("  def-path table bytes: {}", def_path_table_bytes);

Harder to do without splitting DefPathTable into several tables, though.

Lezzz

comment created time in 2 days

Pull request review commentrust-lang/rust

Renamed `PerDefTables` to `Tables`

 impl<'tcx> EncodeContext<'tcx> {             println!("  def-path table bytes: {}", def_path_table_bytes);

Not relevant to this PR necessarily but we should probably encode the DefPathTable as an actual Table.

Lezzz

comment created time in 2 days

Pull request review commentrust-lang/rust

Renamed `PerDefTables` to `Tables`

 impl<'tcx> EncodeContext<'tcx> {             println!("  def-path table bytes: {}", def_path_table_bytes);             println!(" proc-macro-data-bytes: {}", proc_macro_data_bytes);             println!("            item bytes: {}", item_bytes);-            println!("   per-def table bytes: {}", per_def_bytes);+            println!("   per-def table bytes: {}", tables_bytes);

"per-def table bytes" could probably just say "table bytes".

Lezzz

comment created time in 2 days

issue commentrust-lang/rust

build.rs "rerun-if-env-changed" goes out of sync with the actual use site of the env var.

Found another one: CFG_COMPILER_HOST_TRIPLE is used in src/librustc_session/config.rs but it's still mentioned by src/librustc_middle/build.rs.

cc @Mark-Simulacrum Could we automate ensuring this? e.g. by searching for env! in tidy.

eddyb

comment created time in 2 days

issue commentrust-lang/rust

Rustdoc doesn't show src button for many functions in the rustc docs

Oh, that's just bad UX and should be fixed independently on not being able to load some file.

bjorn3

comment created time in 2 days

issue commentrust-lang/rust

Rustdoc doesn't show src button for many functions in the rustc docs

Hang on, but there should be no macros involved in the impl @bjorn3 posted, how is #66364 relevant?

bjorn3

comment created time in 2 days

Pull request review commentrust-lang/rust

infer array len from pattern

 impl<'a, 'tcx> FnCtxt<'a, 'tcx> {     ) -> Ty<'tcx> {         let err = self.tcx.types.err;         let expected = self.structurally_resolved_type(span, expected);-        let (inner_ty, slice_ty, expected) = match expected.kind {+        let (element_ty, slice_ty, inferred) = match expected.kind {             // An array, so we might have something like `let [a, b, c] = [0, 1, 2];`.-            ty::Array(inner_ty, len) => {+            ty::Array(element_ty, len) => {                 let min = before.len() as u64 + after.len() as u64;-                let slice_ty = self-                    .check_array_pat_len(span, slice, len, min)-                    .map_or(err, |len| self.tcx.mk_array(inner_ty, len));-                (inner_ty, slice_ty, expected)+                let (slice_ty, expected) =+                    self.check_array_pat_len(span, element_ty, expected, slice, len, min);

Is this the only caller? It feels like a bunch of stuff is muddled by the fact that it's a separate function.

lcnr

comment created time in 2 days

Pull request review commentrust-lang/rust

infer array len from pattern

 impl<'a, 'tcx> FnCtxt<'a, 'tcx> {                 if min_len != len {                     self.error_scrutinee_inconsistent_length(span, min_len, len);                 }-            } else if let r @ Some(_) = len.checked_sub(min_len) {+            } else if let Some(pat_len) = len.checked_sub(min_len) {                 // The variable-length pattern was there,                 // so it has an array type with the remaining elements left as its size...-                return r;+                return Some(PatLenOrArray::Pat(pat_len));             } else {                 // ...however, in this case, there were no remaining elements.                 // That is, the slice pattern requires more than the array type offers.                 self.error_scrutinee_with_rest_inconsistent_length(span, min_len, len);             }+        } else if slice.is_none() {+            // We have a pattern with a fixed length,+            // which we can use to infer the length of the array.+            // of the array.+            let updated_arr = self.tcx.mk_array(inner_ty, min_len);+            self.demand_eqtype(span, updated_arr, arr_ty);+            return Some(PatLenOrArray::Array(updated_arr));

@lcnr That's mostly because there aren't specific functions, it's all done through traits.

demand_eqtype, for example, passes actual and expected to a function that can take just about anything.

lcnr

comment created time in 2 days

pull request commentrust-lang/rust

Move LLVM bitcode destination

Or, you could default to None and then the code that looks at the flag would have to treat None and Some(true) the same.

This is the standard (Option<T> plus a method that returns T, using a default for None) although we should probably make CLI arg parsing less obnoxious, so this isn't needed anymore.

nnethercote

comment created time in 2 days

Pull request review commentrust-lang/rust

Add `can_unwind` field to `FnAbi`

 pub fn from_fn_attrs(     }     sanitize(cx, codegen_fn_attrs.flags, llfn); -    unwind(-        llfn,-        if cx.tcx.sess.panic_strategy() != PanicStrategy::Unwind {-            // In panic=abort mode we assume nothing can unwind anywhere, so-            // optimize based on this!-            false-        } else if codegen_fn_attrs.flags.contains(CodegenFnAttrFlags::UNWIND) {-            // If a specific #[unwind] attribute is present, use that.-            true-        } else if codegen_fn_attrs.flags.contains(CodegenFnAttrFlags::RUSTC_ALLOCATOR_NOUNWIND) {-            // Special attribute for allocator functions, which can't unwind.-            false-        } else {-            if fn_abi.conv == Conv::Rust {-                // Any Rust method (or `extern "Rust" fn` or `extern-                // "rust-call" fn`) is explicitly allowed to unwind-                // (unless it has no-unwind attribute, handled above).-                true-            } else {-                // Anything else is either:-                //-                //  1. A foreign item using a non-Rust ABI (like `extern "C" { fn foo(); }`), or-                //-                //  2. A Rust item using a non-Rust ABI (like `extern "C" fn foo() { ... }`).-                //-                // Foreign items (case 1) are assumed to not unwind; it is-                // UB otherwise. (At least for now; see also-                // rust-lang/rust#63909 and Rust RFC 2753.)-                //-                // Items defined in Rust with non-Rust ABIs (case 2) are also-                // not supposed to unwind. Whether this should be enforced-                // (versus stating it is UB) and *how* it would be enforced-                // is currently under discussion; see rust-lang/rust#58794.-                //-                // In either case, we mark item as explicitly nounwind.-                false-            }-        },-    );+    unwind(llfn, fn_abi.can_unwind);

Wouldn't it be better to apply these to apply_attrs_llfn on FnAbi? And you can add a FIXME comment to apply_attrs_callsite?

Heh, I checked and there's already an attribute we only apply to definitions and not callsites: noreturn. Maybe we should fix that.

wesleywiser

comment created time in 2 days

pull request commentrust-lang/rust

Add `can_unwind` field to `FnAbi`

@bors r- Just thought of something.

wesleywiser

comment created time in 2 days

pull request commentrust-lang/rust

Add `can_unwind` field to `FnAbi`

@bors r+

wesleywiser

comment created time in 2 days

pull request commentrust-lang/rust

ty/walk: iterate `GenericArg`s instead of `Ty`s.

@nikomatsakis It looks fine now, despite me only doing a rebase. I wonder if #70213 actually ended up being a regression in some cases. Anyway, feel free to review.

eddyb

comment created time in 2 days

pull request commentrust-lang/rust

ty/walk: iterate `GenericArg`s instead of `Ty`s.

@bors try @rust-timer queue

eddyb

comment created time in 3 days

push eventeddyb/rust

Lukas Lueg

commit sha becebf3106407b892f25807473e23d6e8f116a1e

Ammend Rc/Arc::from_raw() docs regarding unsafety Constructing an Rc/Arc is unsafe even if the wrapped `T` is never dereferenced.

view details

Lukas Lueg

commit sha b4c96a9199f13c5c1c2afa6258d2b9206c151d9f

Refine [Arc/Rc]::from_raw() docs

view details

Waffle

commit sha a8340413fe8aa29864ce05875cc63f29af305e31

Remove `finished` flag from `MapWhile`

view details

Lukas Lueg

commit sha 586c7e3907738938db7a6730fd70d7125f5925fa

Make rc::RcBox and sync::ArcInner repr(C) Future-proof these types in case rustc reorders the inner fields. As per discussion in PR #68099.

view details

Waffle

commit sha 605bc1b19b45534b0860fad4b1d44678bc8b34e9

adjuste doc of `map_while` Fix doc of `Iterator::map_while` so it would be clearer that it isn't fused.

view details

Guillaume Gomez

commit sha c57de34e8feca218c0c696b621de87c078a2a0e0

Stabilize --crate-version option in rustdoc

view details

Ralf Jung

commit sha 22ee27b266814485fe9ab7da4b539348cb994045

update backtrace crate

view details

Markus Westerlind

commit sha c6f1215d925561021eec296d9e88aa0305d0a18d

perf(dep_graph): Avoid allocating a set on when the number reads are small `reserve_and_rehash` takes up 1.4% of the runtime on the `packed-simd` benchmark which I believe is due to the number of reads are very low in many cases (see https://github.com/rust-lang/rust/pull/50565 for instance). This avoids allocating the set until we start allocating the `reads` `SmallVec` but it is possible that a lower limit might be better (not tested since the improvement will be hard to spot either way).

view details

Arkadiusz Piekarz

commit sha b90edfcc9e1c4ff547b012c41ba2d55974794a7e

Fix sequence of Type and Trait in optin-builtin-traits in Unstable Book

view details

Markus Westerlind

commit sha 4168c25b0f8aadcfe38c8bdae7cc51c22c2f45d1

refactor: Add an alias for the SmallVec in dep_graph

view details

Matt Cooper

commit sha ec7010a1a8ae59a7538e649218665497306eb8b1

establish immutable source for RUST_CONFIGURE_ARGS

view details

Matt Cooper

commit sha a942b3946521db46ba653693f5d6e477e39bbb3b

fix how we detect an unset variable

view details

Ralf Jung

commit sha 9552d2e4ab84611e4dd354631cceb9555c956c08

bump backtrace-sys

view details

Joshua Nelson

commit sha 62722735fb62c2f93656a012c29310155de35467

impl From<[T; N]> for Vec<T>

view details

Joshua Nelson

commit sha daeb8ece8c930174baa874aa3f2f278fbec9637d

fix error compiling stage2 Co-Authored-By: lzutao <taolzu@gmail.com>

view details

Joshua Nelson

commit sha f267d9dc191debfef74cc211dbca3d286b51f761

limit From impl to LengthAtMost32 Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>

view details

Joshua Nelson

commit sha e3d5eaf2bba89db8359393ac7656db19cb421fb5

add ui-tests

view details

Joshua Nelson

commit sha ba46b61bbcd0d2860105c429cf73254c388e9118

bless UI tests

view details

Joshua Nelson

commit sha 96794d86f127dd409760765a64a36c07d9ed585f

fix test failure

view details

Joshua Nelson

commit sha 1ac4a461425b7a2e29aeb3c2b2cae944f8cbcc77

make the impl a little prettier

view details

push time in 3 days

Pull request review commentrust-lang/rust

Track the finalizing node in the specialization graph

 fn resolve_associated_item<'tcx>(     // the actual function:     match vtbl {         traits::VtableImpl(impl_data) => {-            let (def_id, substs) =-                traits::find_associated_item(tcx, param_env, trait_item, rcvr_substs, &impl_data);--            let resolved_item = tcx.associated_item(def_id);+            debug!(+                "resolving VtableImpl: {:?}, {:?}, {:?}, {:?}",+                param_env, trait_item, rcvr_substs, impl_data+            );+            assert!(!rcvr_substs.needs_infer());++            let trait_def_id = tcx.trait_id_of_impl(impl_data.impl_def_id).unwrap();+            let trait_def = tcx.trait_def(trait_def_id);+            let leaf_def = trait_def+                .ancestors(tcx, impl_data.impl_def_id)+                .ok()?+                .leaf_def(tcx, trait_item.ident, trait_item.kind)+                .unwrap_or_else(|| {+                    bug!("{:?} not found in {:?}", trait_item, impl_data.impl_def_id);+                });+            let def_id = leaf_def.item.def_id;++            let substs = tcx.infer_ctxt().enter(|infcx| {+                let param_env = param_env.with_reveal_all();+                let substs = rcvr_substs.rebase_onto(tcx, trait_def_id, impl_data.substs);+                let substs = translate_substs(+                    &infcx,+                    param_env,+                    impl_data.impl_def_id,+                    substs,+                    leaf_def.defining_node,+                );+                infcx.tcx.erase_regions(&substs)+            });

Seems fair, it's easier to infer everything through unification. I suppose the only thing that could be done ahead of time is to get the Substs for a less specialized impl, in terms of types from a more specialized impl.

That is, impl<T, U> Foo<U> for Vec<T> and impl<'a, X> Foo<() for Vec<&'a X> would give you Substs [&'a X, ()], and I guess if you had these on every edge in the specialization graph, you could walk "up" it (i.e. in the "less specialized" direction) by successive substitution.

Actually, is that what's necessary? Because it doesn't seem that hard to compute, you'd use translate_subst or w/e ahead of time and keep the result. But it can be done in a separate PR.

jonas-schievink

comment created time in 3 days

more