rust/tests/incremental/krate-inherent.rs

//@ revisions: cfail1 cfail2
//@ compile-flags: -Z query-dep-graph
//@ build-pass (FIXME(62277): could be check-pass?)

#![allow(warnings)]
#![feature(rustc_attrs)]
#![rustc_partition_reused(module = "krate_inherent-x", cfg = "cfail2")]
#![crate_type = "rlib"]

pub mod x {
    pub struct Foo;
    impl Foo {
        pub fn foo(&self) {}
    }

    pub fn method() {
        let x: Foo = Foo;
        x.foo(); // inherent methods used to add an edge from hir_crate
    }
}

#[cfg(cfail1)]
pub fn bar() {} // remove this unrelated fn in cfail2, which should not affect `x::method`
Fix incremental tests after change to instantiation strategy. 2017-10-27 11:57:15 -05:00			`//@ revisions: cfail1 cfail2`
write to inherent_impls during the visitor The goal here is to avoid writing to the `inherent_impls` map from within the general `Coherence` task, and instead write to it as we visit. Writing to it from the Coherence task is actually an information leak; it happened to be safe because Coherence read from `DepNode::Krate`, but that was very coarse. I removed the `Rc` here because, upon manual inspection, nobody clones the data in this table, and it meant that we can accumulate the data in place. That said, the pattern that is used for the inherent impls map is generally an anti-pattern (that is, holding the borrow lock for the duration of using the contents), so it'd probably be better to clone (and I doubt that would be expensive -- how many inherent impls does a typical type have?). 2016-08-24 05:49:44 -05:00			`//@ compile-flags: -Z query-dep-graph`
Migrate compile-pass annotations to build-pass 2019-07-02 16:30:28 -05:00			`//@ build-pass (FIXME(62277): could be check-pass?)`
write to inherent_impls during the visitor The goal here is to avoid writing to the `inherent_impls` map from within the general `Coherence` task, and instead write to it as we visit. Writing to it from the Coherence task is actually an information leak; it happened to be safe because Coherence read from `DepNode::Krate`, but that was very coarse. I removed the `Rc` here because, upon manual inspection, nobody clones the data in this table, and it meant that we can accumulate the data in place. That said, the pattern that is used for the inherent impls map is generally an anti-pattern (that is, holding the borrow lock for the duration of using the contents), so it'd probably be better to clone (and I doubt that would be expensive -- how many inherent impls does a typical type have?). 2016-08-24 05:49:44 -05:00
			`#![allow(warnings)]`
			`#![feature(rustc_attrs)]`
Move the `krate` method to Hir and remove the Krate dep node 2020-02-06 05:46:26 -06:00			`#![rustc_partition_reused(module = "krate_inherent-x", cfg = "cfail2")]`
Fix incremental tests after change to instantiation strategy. 2017-10-27 11:57:15 -05:00			`#![crate_type = "rlib"]`
write to inherent_impls during the visitor The goal here is to avoid writing to the `inherent_impls` map from within the general `Coherence` task, and instead write to it as we visit. Writing to it from the Coherence task is actually an information leak; it happened to be safe because Coherence read from `DepNode::Krate`, but that was very coarse. I removed the `Rc` here because, upon manual inspection, nobody clones the data in this table, and it meant that we can accumulate the data in place. That said, the pattern that is used for the inherent impls map is generally an anti-pattern (that is, holding the borrow lock for the duration of using the contents), so it'd probably be better to clone (and I doubt that would be expensive -- how many inherent impls does a typical type have?). 2016-08-24 05:49:44 -05:00
Fix incremental tests after change to instantiation strategy. 2017-10-27 11:57:15 -05:00			`pub mod x {`
			`pub struct Foo;`
write to inherent_impls during the visitor The goal here is to avoid writing to the `inherent_impls` map from within the general `Coherence` task, and instead write to it as we visit. Writing to it from the Coherence task is actually an information leak; it happened to be safe because Coherence read from `DepNode::Krate`, but that was very coarse. I removed the `Rc` here because, upon manual inspection, nobody clones the data in this table, and it meant that we can accumulate the data in place. That said, the pattern that is used for the inherent impls map is generally an anti-pattern (that is, holding the borrow lock for the duration of using the contents), so it'd probably be better to clone (and I doubt that would be expensive -- how many inherent impls does a typical type have?). 2016-08-24 05:49:44 -05:00			`impl Foo {`
Move the `krate` method to Hir and remove the Krate dep node 2020-02-06 05:46:26 -06:00			`pub fn foo(&self) {}`
write to inherent_impls during the visitor The goal here is to avoid writing to the `inherent_impls` map from within the general `Coherence` task, and instead write to it as we visit. Writing to it from the Coherence task is actually an information leak; it happened to be safe because Coherence read from `DepNode::Krate`, but that was very coarse. I removed the `Rc` here because, upon manual inspection, nobody clones the data in this table, and it meant that we can accumulate the data in place. That said, the pattern that is used for the inherent impls map is generally an anti-pattern (that is, holding the borrow lock for the duration of using the contents), so it'd probably be better to clone (and I doubt that would be expensive -- how many inherent impls does a typical type have?). 2016-08-24 05:49:44 -05:00			`}`

Fix incremental tests after change to instantiation strategy. 2017-10-27 11:57:15 -05:00			`pub fn method() {`
write to inherent_impls during the visitor The goal here is to avoid writing to the `inherent_impls` map from within the general `Coherence` task, and instead write to it as we visit. Writing to it from the Coherence task is actually an information leak; it happened to be safe because Coherence read from `DepNode::Krate`, but that was very coarse. I removed the `Rc` here because, upon manual inspection, nobody clones the data in this table, and it meant that we can accumulate the data in place. That said, the pattern that is used for the inherent impls map is generally an anti-pattern (that is, holding the borrow lock for the duration of using the contents), so it'd probably be better to clone (and I doubt that would be expensive -- how many inherent impls does a typical type have?). 2016-08-24 05:49:44 -05:00			`let x: Foo = Foo;`
Move the `krate` method to Hir and remove the Krate dep node 2020-02-06 05:46:26 -06:00			`x.foo(); // inherent methods used to add an edge from hir_crate`
write to inherent_impls during the visitor The goal here is to avoid writing to the `inherent_impls` map from within the general `Coherence` task, and instead write to it as we visit. Writing to it from the Coherence task is actually an information leak; it happened to be safe because Coherence read from `DepNode::Krate`, but that was very coarse. I removed the `Rc` here because, upon manual inspection, nobody clones the data in this table, and it meant that we can accumulate the data in place. That said, the pattern that is used for the inherent impls map is generally an anti-pattern (that is, holding the borrow lock for the duration of using the contents), so it'd probably be better to clone (and I doubt that would be expensive -- how many inherent impls does a typical type have?). 2016-08-24 05:49:44 -05:00			`}`
			`}`

Fix incremental tests after change to instantiation strategy. 2017-10-27 11:57:15 -05:00			`#[cfg(cfail1)]`
Move the `krate` method to Hir and remove the Krate dep node 2020-02-06 05:46:26 -06:00			pub fn bar() {} // remove this unrelated fn in cfail2, which should not affect `x::method`