profile
viewpoint

dtolnay/cargo-expand 764

Subcommand to show result of macro expansion

alexcrichton/toml-rs 698

A TOML encoding/decoding library for Rust

ehuss/cargo-prefetch 20

Cargo subcommand to download popular crates.

ehuss/cargo-index 10

Cargo subcommand to manage a registry index.

dqsully/atom-column-select 9

Atom package to enhance column selection.

ehuss/cargo-clone-crate 4

Cargo subcommand to clone a repo from the registry.

ehuss/anno-2205-layouts 2

Tool for Anno 2205 layouts.

ehuss/atom-wrap-plus 2

Enhanced word wrapping for the Atom editor.

ehuss/atom 0

The hackable editor

issue commentrust-lang/rustfix

Rustfix discards comments

I'm not sure there's anything rustfix can do here. It only works with the suggested spans from rustc, it has no knowledge of Rust syntax (it works on simple byte replacements as instructed by the compiler).

I'm not sure what a reasonable output for the first example would be. I think it would be wrong for suggestions to somehow retain arbitrary comments within a span.

The second example also looks like it would be quite difficult to translate properly. One option is that Clippy could emit a multi-part suggestion, with each part containing a minimal span to translate. For example:

  • match kind {matches!(kind,
  • => true,empty
  • _ => false,empty
  • })

However, I think that would be a significant decrease in the readable quality of the diagnostic, and would probably be more difficult to implement and error-prone.

jyn514

comment created time in a few seconds

pull request commentrust-lang/cargo

Remove redundant "For example, "

Thanks! @bors r+

sean-hut

comment created time in 26 minutes

pull request commentrust-lang/cargo

Document platform-specific build-dependencies

Thanks! This has been sitting in my todo list for a long time.

@bors r+

roblabla

comment created time in 30 minutes

Pull request review commentrust-lang/cargo

List available packages if providing `--package` with an empty value

 fn print_available(     let mut output = String::new();     writeln!(output, "\"{}\" takes one argument.", option_name)?; -    if targets.is_empty() {+    print_availables(output, &targets, plural_name)+}++fn print_availables(output: String, availables: &[&str], plural_name: &str) -> CargoResult<()> {+    let mut output = output;+    if availables.is_empty() {         writeln!(output, "No {} available.", plural_name)?;     } else {         writeln!(output, "Available {}:", plural_name)?;-        for target in targets {-            writeln!(output, "    {}", target.name())?;+        for available in availables {+            writeln!(output, "    {}", available)?;         }     }     bail!("{}", output) } +pub fn print_available_packages(ws: &Workspace<'_>) -> CargoResult<()> {+    let packages = ws+        .members()+        .map(|pkg| pkg.name().as_str())+        .collect::<Vec<_>>();++    let mut output = String::new();+    writeln!(+        output,+        "\"--package <SPEC>\" requires a SPEC format value.\n\+        Run `cargo help pkgid` for more infomation about SPEC format."+    )?;
    let output = "\"--package <SPEC>\" requires a SPEC format value.\n\
        Run `cargo help pkgid` for more infomation about SPEC format.\n"
        .to_string();
weihanglo

comment created time in an hour

Pull request review commentrust-lang/cargo

List available packages if providing `--package` with an empty value

 fn print_available(     let mut output = String::new();     writeln!(output, "\"{}\" takes one argument.", option_name)?; -    if targets.is_empty() {+    print_availables(output, &targets, plural_name)+}++fn print_availables(output: String, availables: &[&str], plural_name: &str) -> CargoResult<()> {+    let mut output = output;
fn print_availables(mut output: String, availables: &[&str], plural_name: &str) -> CargoResult<()> {
weihanglo

comment created time in an hour

PullRequestReviewEvent
PullRequestReviewEvent

create barnchehuss/cargo

branch : token-process

created branch time in 5 hours

issue closedrust-lang/reference

List of permitting structures in const functions is out of date

The list here of things permitted in const functions is out of date, and has been since at least 1.33.0 when let bindings, assignments, and other constructs were allowed.

closed time in a day

alercah

issue commentrust-lang/reference

List of permitting structures in const functions is out of date

Closing, as I believe the list is now up-to-date via #842, #867, and #883. If there is anything still missing, feel free to reopen or open a new issue.

alercah

comment created time in a day

issue closedrust-lang/reference

Inconsistency in use of "supertrait" between Rust By Example and Rust Reference

In Rust By Example, in the section on supertraits (https://doc.rust-lang.org/stable/rust-by-example/trait/supertraits.html), the example says, "Student is a supertrait of Person." But the chapter in the Rust Reference on supertraits it refers to (https://doc.rust-lang.org/book/ch19-03-advanced-traits.html#using-supertraits-to-require-one-traits-functionality-within-another-trait) says, "The trait you rely on is a supertrait of the trait you are implementing." I think the latter is correct, but in any case, the usage should be consistent.

closed time in a day

vluchangco

issue commentrust-lang/reference

Inconsistency in use of "supertrait" between Rust By Example and Rust Reference

Closing for the related issue https://github.com/rust-lang/rust-by-example/issues/1373.

vluchangco

comment created time in a day

PR opened rust-lang/reference

Add `unsafe` for `mod` and `extern`.

New syntax added in https://github.com/rust-lang/rust/pull/75857/.

+13 -3

0 comment

2 changed files

pr created time in a day

create barnchehuss/reference

branch : add-unsafe-mod-extern

created branch time in a day

create barnchehuss/cargo

branch : weak-dep-features

created branch time in a day

pull request commentrust-lang/cargo

New namespaced features implementation.

I'm moved by the argument from @est31 that crate: is dangerously close in syntax to crate:: in Rust, and they mean significantly different things. I'm concerned that crate: would perpetuate more misunderstanding about what the term "crate" means. I think it is an uphill battle that cannot be won, but I don't want to push things in the direction of more confusion. I can revert this if people don't agree.

I have pushed a commit that renames it to dep:. I decided on dep: instead of pkg: because the name is not necessarily the package name (it is the "name in toml"), and I think it more clearly emphasizes that it is referring to a dependency.

ehuss

comment created time in a day

push eventehuss/cargo

Eric Huss

commit sha f4ac82a0f5b03eed60b7363bfe15ff1a41ec22e6

Rename crate: to dep:

view details

push time in a day

PR opened rust-lang/cargo

Remove some unused code.

This was accidentally left behind during some earlier reworks.

+0 -3

0 comment

1 changed file

pr created time in a day

create barnchehuss/cargo

branch : remove-unused-package-features

created branch time in a day

issue commentrust-lang/cargo

When cargo can't run because it doesn't have permissions to a file, error messages should mention which file is causing the problem

@seanvikoren Can you run with the RUST_BACKTRACE=1 and CARGO_LOG=trace environment variables set and copy the output?

rask

comment created time in a day

issue commentrust-lang/cargo

cargo fix failed to apply changes suggested by linter

Thanks for the report!

In this particular case, the lint is marked as MaybeIncorrect, and cargo fix does not apply those automatically. I think in this case that is intentional, though I am uncertain of the exact reason. I'm guessing that it is because applying that fix would end up breaking all uses of that variant, and rustc is not built for doing refactoring of entire codebases. There are other tools that are better suited for that (I think rust-analyzer can maybe do that).

There is an issue for forcing cargo fix to apply non-MachineApplicable lints at https://github.com/rust-lang/rustfix/issues/163, although in this case this would result in a lot of broken code, and probably not what you want.

Perhaps cargo fix should include a message explaining why certain fixes were not applied?

tklebanoff

comment created time in 2 days

create barnchehuss/cargo

branch : warn-feature-syntax

created branch time in 2 days

issue commentrust-lang/rustup

error: toolchain 'stable-x86_64-unknown-linux-gnu' does not contain component 'rust-std' for target 'x86_unknown-linux-musl'

It looks like you have a typo, though it's not clear which target you actually want to install. For the 64-bit target, it is x86_64-unknown-linux-musl, for 32-bit it is i686-unknown-linux-musl. The list of available target names is published at https://doc.rust-lang.org/nightly/rustc/platform-support.html.

jonee

comment created time in 2 days

Pull request review commentrust-lang/cargo

New namespaced features implementation.

+//! Tests for namespaced features.++use cargo_test_support::project;+use cargo_test_support::registry::{Dependency, Package};++#[cargo_test]+fn gated() {+    // Need namespaced-features to use `crate:` syntax.+    Package::new("bar", "1.0.0").publish();+    let p = project()+        .file(+            "Cargo.toml",+            r#"+                [package]+                name = "foo"+                version = "0.1.0"++                [dependencies]+                bar = { version = "1.0", optional = true }++                [features]+                foo = ["crate:bar"]+            "#,+        )+        .file("src/lib.rs", "")+        .build();++    p.cargo("check")+        .with_status(101)+        .with_stderr(+            "\+[ERROR] failed to parse manifest at `[..]/foo/Cargo.toml`++Caused by:+  namespaced features with the `crate:` prefix are only allowed on the nightly channel \+  and requires the `-Z namespaced-features` flag on the command-line+",+        )+        .run();+}++#[cargo_test]+fn dependency_gate_ignored() {+    // Dependencies with `crate:` features are ignored in the registry if not on nightly.+    Package::new("baz", "1.0.0").publish();+    Package::new("bar", "1.0.0")+        .add_dep(Dependency::new("baz", "1.0").optional(true))+        .feature("feat", &["crate:baz"])+        .publish();+    let p = project()+        .file(+            "Cargo.toml",+            r#"+                [package]+                name = "foo"+                version = "0.1.0"++                [dependencies]+                bar = "1.0"+            "#,+        )+        .file("src/lib.rs", "")+        .build();++    p.cargo("check")+        .masquerade_as_nightly_cargo()+        .with_status(101)+        .with_stderr(+            "\+[UPDATING] [..]+[ERROR] no matching package named `bar` found+location searched: registry `https://github.com/rust-lang/crates.io-index`+required by package `foo v0.1.0 ([..]/foo)`+",+        )+        .run();++    // Publish a version without namespaced features, it should ignore 1.0.0+    // an use this instead.+    Package::new("bar", "1.0.1")+        .add_dep(Dependency::new("baz", "1.0").optional(true))+        .feature("feat", &["baz"])+        .publish();+    p.cargo("check")+        .masquerade_as_nightly_cargo()+        .with_stderr(+            "\+[UPDATING] [..]+[DOWNLOADING] crates ...+[DOWNLOADED] bar [..]+[CHECKING] bar v1.0.1+[CHECKING] foo v0.1.0 [..]+[FINISHED] [..]+",+        )+        .run();+}++#[cargo_test]+fn dependency_with_crate_syntax() {+    // Registry dependency uses crate: syntax.+    Package::new("baz", "1.0.0").publish();+    Package::new("bar", "1.0.0")+        .add_dep(Dependency::new("baz", "1.0").optional(true))+        .feature("feat", &["crate:baz"])

Yep. I'm actually not sure how to roll this out, since we'll need to be pretty confident on the design since it affects the index. At what point do we decide to turn it on?

ehuss

comment created time in 3 days

PullRequestReviewEvent

Pull request review commentrust-lang/cargo

New namespaced features implementation.

 where             .push(dep);     } -    let mut map = BTreeMap::new();-    for (feature, list) in features.iter() {-        // If namespaced features is active and the key is the same as that of an-        // optional dependency, that dependency must be included in the values.-        // Thus, if a `feature` is found that has the same name as a dependency, we-        // (a) bail out if the dependency is non-optional, and (b) we track if the-        // feature requirements include the dependency `crate:feature` in the list.-        // This is done with the `dependency_found` variable, which can only be-        // false if features are namespaced and the current feature key is the same-        // as the name of an optional dependency. If so, it gets set to true during-        // iteration over the list if the dependency is found in the list.-        let mut dependency_found = if namespaced {-            match dep_map.get(feature.borrow()) {-                Some(dep_data) => {-                    if !dep_data.iter().any(|d| d.is_optional()) {-                        anyhow::bail!(-                            "Feature `{}` includes the dependency of the same name, but this is \-                             left implicit in the features included by this feature.\n\-                             Additionally, the dependency must be marked as optional to be \-                             included in the feature definition.\n\-                             Consider adding `crate:{}` to this feature's requirements \-                             and marking the dependency as `optional = true`",-                            feature,-                            feature-                        )-                    } else {-                        false-                    }-                }-                None => true,-            }-        } else {-            true+    let mut map: FeatureMap = features+        .iter()+        .map(|(feature, list)| {+            let fvs: Vec<_> = list+                .iter()+                .map(|feat_value| FeatureValue::new(*feat_value))+                .collect();+            (*feature, fvs)+        })+        .collect();+    let has_namespaced_features = map.values().flatten().any(|fv| fv.is_explicit_crate());++    // Add implicit features for optional dependencies if they weren't+    // explicitly listed anywhere.+    let explicitly_listed: HashSet<_> = map+        .values()+        .flatten()+        .filter_map(|fv| match fv {+            Crate { dep_name }+            | CrateFeature {+                dep_name,+                explicit: true,+                ..+            } => Some(*dep_name),+            _ => None,+        })+        .collect();+    for dep in dependencies {+        if !dep.is_optional() {+            continue;+        }+        let dep_name_in_toml = dep.name_in_toml();+        if features.contains_key(&dep_name_in_toml) || explicitly_listed.contains(&dep_name_in_toml)+        {+            continue;+        }+        let fv = Crate {+            dep_name: dep_name_in_toml,         };+        map.insert(dep_name_in_toml, vec![fv]);+    } -        let mut values = vec![];-        for dep in list {-            let val = FeatureValue::build(-                InternedString::new(dep.as_ref()),-                |fs| features.contains_key(fs.as_str()),-                namespaced,+    // Validate features are listed properly.+    for (feature, fvs) in &map {+        if feature.starts_with("crate:") {+            bail!(+                "feature named `{}` is not allowed to start with `crate:`",+                feature             );-+        }+        for fv in fvs {             // Find data for the referenced dependency...             let dep_data = {-                match val {-                    Feature(ref dep_name) | Crate(ref dep_name) | CrateFeature(ref dep_name, _) => {-                        dep_map.get(dep_name.as_str())+                match fv {+                    Feature(dep_name) | Crate { dep_name, .. } | CrateFeature { dep_name, .. } => {+                        dep_map.get(dep_name)                     }                 }             };             let is_optional_dep = dep_data                 .iter()                 .flat_map(|d| d.iter())                 .any(|d| d.is_optional());-            if let FeatureValue::Crate(ref dep_name) = val {-                // If we have a dependency value, check if this is the dependency named-                // the same as the feature that we were looking for.-                if !dependency_found && feature.borrow() == dep_name.as_str() {-                    dependency_found = true;-                }-            }--            match (&val, dep_data.is_some(), is_optional_dep) {-                // The value is a feature. If features are namespaced, this just means-                // it's not prefixed with `crate:`, so we have to check whether the-                // feature actually exist. If the feature is not defined *and* an optional-                // dependency of the same name exists, the feature is defined implicitly-                // here by adding it to the feature map, pointing to the dependency.-                // If features are not namespaced, it's been validated as a feature already-                // while instantiating the `FeatureValue` in `FeatureValue::build()`, so-                // we don't have to do so here.-                (&Feature(feat), _, true) => {-                    if namespaced && !features.contains_key(&*feat) {-                        map.insert(feat, vec![FeatureValue::Crate(feat)]);-                    }-                }-                // If features are namespaced and the value is not defined as a feature-                // and there is no optional dependency of the same name, error out.-                // If features are not namespaced, there must be an existing feature-                // here (checked by `FeatureValue::build()`), so it will always be defined.-                (&Feature(feat), dep_exists, false) => {-                    if namespaced && !features.contains_key(&*feat) {-                        if dep_exists {-                            anyhow::bail!(-                                "Feature `{}` includes `{}` which is not defined as a feature.\n\-                                 A non-optional dependency of the same name is defined; consider \-                                 adding `optional = true` to its definition",+            let is_any_dep = dep_data.is_some();+            match fv {+                Feature(f) => {+                    if !features.contains_key(f) {+                        if !is_any_dep {+                            bail!(+                                "feature `{}` includes `{}` which is neither a dependency \+                                 nor another feature",                                 feature,-                                feat-                            )+                                fv+                            );+                        }+                        if is_optional_dep {+                            if !map.contains_key(f) {+                                bail!(+                                    "feature `{}` includes `{}`, but `{}` is an \+                                     optional dependency without an implicit feature\n\+                                     Use `crate:{}` to enable the dependency.",+                                    feature,+                                    fv,+                                    f,+                                    f+                                );+                            }                         } else {-                            anyhow::bail!(-                                "Feature `{}` includes `{}` which is not defined as a feature",-                                feature,-                                feat-                            )+                            bail!("feature `{}` includes `{}`, but `{}` is not an optional dependency\n\+                                A non-optional dependency of the same name is defined; \+                                consider adding `optional = true` to its definition.",+                                feature, fv, f);                         }                     }                 }-                // The value is a dependency. If features are namespaced, it is explicitly-                // tagged as such (`crate:value`). If features are not namespaced, any value-                // not recognized as a feature is pegged as a `Crate`. Here we handle the case-                // where the dependency exists but is non-optional. It branches on namespaced-                // just to provide the correct string for the crate dependency in the error.-                (&Crate(ref dep), true, false) => {-                    if namespaced {-                        anyhow::bail!(-                            "Feature `{}` includes `crate:{}` which is not an \-                             optional dependency.\nConsider adding \-                             `optional = true` to the dependency",+                Crate { dep_name } => {+                    if !is_any_dep {+                        bail!(+                            "feature `{}` includes `{}`, but `{}` is not listed as a dependency",                             feature,-                            dep-                        )-                    } else {-                        anyhow::bail!(-                            "Feature `{}` depends on `{}` which is not an \-                             optional dependency.\nConsider adding \-                             `optional = true` to the dependency",+                            fv,+                            dep_name+                        );+                    }+                    if !is_optional_dep {+                        bail!(+                            "feature `{}` includes `{}`, but `{}` is not an optional dependency\n\+                             A non-optional dependency of the same name is defined; \+                             consider adding `optional = true` to its definition.",                             feature,-                            dep-                        )+                            fv,+                            dep_name+                        );                     }                 }-                // If namespaced, the value was tagged as a dependency; if not namespaced,-                // this could be anything not defined as a feature. This handles the case-                // where no such dependency is actually defined; again, the branch on-                // namespaced here is just to provide the correct string in the error.-                (&Crate(ref dep), false, _) => {-                    if namespaced {-                        anyhow::bail!(-                            "Feature `{}` includes `crate:{}` which is not a known \-                             dependency",-                            feature,-                            dep-                        )-                    } else {-                        anyhow::bail!(-                            "Feature `{}` includes `{}` which is neither a dependency nor \-                             another feature",+                CrateFeature { dep_name, .. } => {+                    // Validation of the feature name will be performed in the resolver.+                    if !is_any_dep {+                        bail!(+                            "feature `{}` includes `{}`, but `{}` is not a dependency",                             feature,-                            dep-                        )+                            fv,+                            dep_name+                        );                     }                 }-                (&Crate(_), true, true) => {}-                // If the value is a feature for one of the dependencies, bail out if no such-                // dependency is actually defined in the manifest.-                (&CrateFeature(ref dep, _), false, _) => anyhow::bail!(-                    "Feature `{}` requires a feature of `{}` which is not a \-                     dependency",-                    feature,-                    dep-                ),-                (&CrateFeature(_, _), true, _) => {}             }-            values.push(val);-        }--        if !dependency_found {-            // If we have not found the dependency of the same-named feature, we should-            // bail here.-            anyhow::bail!(-                "Feature `{}` includes the optional dependency of the \-                 same name, but this is left implicit in the features \-                 included by this feature.\nConsider adding \-                 `crate:{}` to this feature's requirements.",-                feature,-                feature-            )         }+    } -        map.insert(InternedString::new(feature.borrow()), values);+    // Make sure every optional dep is mentioned at least once.+    let used: HashSet<_> = map+        .values()+        .flatten()+        .filter_map(|fv| match fv {+            Crate { dep_name } | CrateFeature { dep_name, .. } => Some(dep_name),+            _ => None,+        })+        .collect();+    if let Some(dep) = dependencies+        .iter()+        .find(|dep| dep.is_optional() && !used.contains(&dep.name_in_toml()))+    {+        bail!(+            "optional dependency `{}` is not included in any feature\n\+            Make sure that `crate:{}` is included in one of features in the [features] table.",+            dep.name_in_toml(),+            dep.name_in_toml(),+        );     }-    Ok(map)++    Ok((map, has_namespaced_features)) } -/// FeatureValue represents the types of dependencies a feature can have:-///-/// * Another feature-/// * An optional dependency-/// * A feature in a dependency-///-/// The selection between these 3 things happens as part of the construction of the FeatureValue.+/// FeatureValue represents the types of dependencies a feature can have. #[derive(Clone, Debug)] pub enum FeatureValue {+    /// A feature enabling another feature.     Feature(InternedString),-    Crate(InternedString),-    CrateFeature(InternedString, InternedString),+    /// A feature enabling a dependency with `crate:dep_name` syntax.+    Crate { dep_name: InternedString },+    /// A feature enabling a feature on a dependency with `crate_name/feat_name` syntax.+    CrateFeature {+        dep_name: InternedString,+        dep_feature: InternedString,+        /// If this is true, then the feature used the `crate:` prefix, which+        /// prevents enabling the feature named `dep_name`.+        explicit: bool,

Sounds better, thanks!

ehuss

comment created time in 3 days

PullRequestReviewEvent

push eventehuss/cargo

Eric Huss

commit sha a133f25c7a92b0dee2b384316af4ec7257c5c6e3

Update TOML website links.

view details

bors

commit sha 6a38927551df9bbe2dea340bf92d3e53abccf890

Auto merge of #8803 - ehuss:toml-links, r=alexcrichton Update TOML website links. Update the links to the new, fancy TOML website. Also added a few more links. Closes #8800

view details

Eric Huss

commit sha d5541331cf8ca9b6f5c22740438bbe2f24af059a

Some minor clippy fixes.

view details

bors

commit sha 2f115a76e5a1e5eb11cd29e95f972ed107267847

Auto merge of #8804 - ehuss:clippy-fixes, r=alexcrichton Some minor clippy fixes.

view details

Eric Huss

commit sha 2611f5c73c84030086bb429304ae468753693e24

Move namespaced features tests to a separate file.

view details

Eric Huss

commit sha 36c69a18fe8af5c07c9ecf6234f0c560bcc415a2

Rename features() to unstable_features(). To avoid confusion with the...other thing called "features".

view details

Eric Huss

commit sha dca0b1156651a94a2ffd93d9c12c670727309a94

Slightly rewrite how conflicting activation errors are processed. I'm not sure why the original code partitioned the errors in the way that it did. I think it is better to exhaustively match all the reasons, so that when new reasons are added, it will be clear that this code needs to be updated. I also think it simplifies the code a little.

view details

Eric Huss

commit sha bcfdf9fbad78cf0e9ec52e84ce68f7b2a5aa19da

New namespaced features implementation.

view details

Eric Huss

commit sha b2cceaf76e754fdad82c77005fc79248058c253a

Expose implicit features in `cargo metadata`.

view details

Eric Huss

commit sha 1149f68026c3e292eb8d0cacf12466c7c5682c2d

Some minor cleanup.

view details

Eric Huss

commit sha c8a3db8e8f25f8b9626b760c172dba7abee46a7a

Minor cleanup.

view details

Eric Huss

commit sha 8ff130bb289d8dfc2fb384ed81df6d0abe638b09

Rename "explicit" to "crate_prefix".

view details

push time in 3 days

issue commentrust-lang/cargo

Inconsistent data in `cargo metadata`

I'm inclined to close this. After further inspection, it looks like the issue is related to specifying both a branch and a revision at the same time. Cargo specifically warns about this:

warning: dependency (diesel) specification is ambiguous. Only one of `branch`, `tag` or `rev` is allowed. This will be considered an error in future versions
warning: dependency (diesel_derives) specification is ambiguous. Only one of `branch`, `tag` or `rev` is allowed. This will be considered an error in future versions

Of course it's probably best for Cargo not to stumble on it, but since it isn't supported to start with, I'm not sure it is worth putting time into. We could change the warning to an error, since it has been around for a few years.

Does that sounds reasonable?

matklad

comment created time in 3 days

PR opened rust-lang/edition-guide

A few small updates.

Just a few updates/fixes that I've run across.

+57 -41

0 comment

5 changed files

pr created time in 3 days

issue commentrust-lang/cargo

beta: cargo metadata uses inconsistent encodings of ids with `branch = master` dependencies

I think cargo metadata is the only place where this surfaces, but I am not certain. I think it only matters for JSON interfaces, and JSON artifact messages use the Package variant of PackageId. It only matters if you want to compare the IDs between the resolver and Packages, and I think that only happens in cargo metadata. Does that sound right?

Nemo157

comment created time in 3 days

push eventrust-lang/edition-guide

davidOSUL

commit sha 3647f8d61b0c9ba1716d9ea041f4606aab35dcf9

Update question-mark-in-main-and-tests.md

view details

davidOSUL

commit sha 90077f2b0a579ee915841abc707d0c0853c7e0fc

Update question-mark-in-main-and-tests.md

view details

Eric Huss

commit sha 23077a50ed417050c5e3e0fb057ed9ff93506550

Merge pull request #219 from davidOSUL/master Clarify the limitation of ? in main and tests

view details

push time in 3 days

PR merged rust-lang/edition-guide

Clarify the limitation of ? in main and tests

I was trying to figure out why my error messages were not printing how I wanted them to (using Display). This page in the edition book is one of the first links that pops up when I googled it, but it wasn't till I saw this post on the rust forum that I realized there was no way to do this "automatically", so I thought it might be helpful for others to clarify in these docs as well.

+3 -1

0 comment

1 changed file

davidOSUL

pr closed time in 3 days

PullRequestReviewEvent

push eventehuss/edition-guide

Eric Huss

commit sha 957c82d8714adf5ca5082674f15576503d432e74

Update situations when `extern crate` is needed.

view details

Eric Huss

commit sha 36e8884e5bea9f3645e3449e279027d2d34988cd

Update that tyvar_behind_raw_pointer is now a hard error.

view details

push time in 3 days

create barnchehuss/edition-guide

branch : small-updates

created branch time in 3 days

issue commentrust-lang/mdBook

Running mdbook build does not create "theme" subdirectory

v0.1.0 is almost 3 years old. Can you maybe try with the latest version?

output.html.theme is defined in the book.toml file. It might look something like this:

[output.html]
theme = "src/theme"

That tells mdbook where the custom theme is located.

Ciro-Fusco

comment created time in 3 days

Pull request review commentrust-lang/cargo

New namespaced features implementation.

 lto = true * Original issue: [#1286](https://github.com/rust-lang/cargo/issues/1286) * Tracking Issue: [#5565](https://github.com/rust-lang/cargo/issues/5565) -Currently, it is not possible to have a feature and a dependency with the same-name in the manifest. If you set `namespaced-features` to `true`, the namespaces-for features and dependencies are separated. The effect of this is that, in the-feature requirements, dependencies have to be prefixed with `crate:`. Like this:+The `namespaced-features` option makes two changes to how features can be+specified:++* Features may now be defined with the same name as a dependency.+* Optional dependencies can be explicitly enabled in the `[features]` table+  with the `crate:` prefix, which enables the dependency without enabling a+  feature of the same name.++By default, an optional dependency `foo` will define a feature `foo =+["crate:foo"]` *unless* `crate:foo` is mentioned in any other feature, or the+`foo` feature is already defined. This helps prevent unnecessary boilerplate+of listing every optional dependency, but still allows you to override the+implicit feature.++This allows two use cases that were previously not possible:++* You can "hide" an optional dependency, so that external users cannot+  explicitly enable that optional dependency.+* There is no longer a need to create "funky" feature names to work around the+  restriction that features cannot shadow dependency names.++To enable namespaced-features, use the `-Z namespaced-features` command-line+flag.++An example of hiding an optional dependency:  ```toml-[package]-namespaced-features = true+[dependencies]+regex = { version = "1.4.1", optional = true }+lazy_static = { version = "1.4.0", optional = true }  [features]-bar = ["crate:baz", "foo"]-foo = []+regex = ["crate:regex", "crate:lazy_static"]+```++In this example, the "regex" feature enables both `regex` and `lazy_static`.+The `lazy_static` feature does not exist, and a user cannot explicitly enable+it. This helps hide internal details of how your package is implemented. +An example of avoiding "funky" names:++```toml [dependencies]-baz = { version = "0.1", optional = true }-```+bigdecimal = "0.1"+chrono = "0.4"+num-bigint = "0.2"+serde = {version = "1.0", optional = true } -To prevent unnecessary boilerplate from having to explicitly declare features-for each optional dependency, implicit features get created for any optional-dependencies where a feature of the same name is not defined. However, if-a feature of the same name as a dependency is defined, that feature must-include the dependency as a requirement, as `foo = ["crate:foo"]`.+[features]+serde = ["crate:serde", "bigdecimal/serde", "chrono/serde", "num-bigint/serde"]

I'm not entirely clear about what is ambiguous. bigdecimal = [] defines a feature named bigdecimal. If you specify bigdecimal/serde, it enables the bigdecimal crate (if it is optional), enables the serde feature on bigdecimal, and enables the bigdecimal feature. I don't think we can disallow that since that is the current behavior.

ehuss

comment created time in 3 days

PullRequestReviewEvent

issue commentrust-lang/mdBook

Add error for when there are items in the SUMMARY that don't have pages

This is intentional, as a way to quickly set up the scaffolding of a project. Adding an info level message sounds reasonable, though.

camelid

comment created time in 3 days

issue closedrust-lang/mdBook

Code block copy button overlaps with code

Not sure what the best way to resolve this is, but thought I would open an issue so there can be discussion. This image is from this page in the Reference:

image

closed time in 3 days

camelid

issue commentrust-lang/mdBook

Code block copy button overlaps with code

Thanks, this is a duplicate of #1322.

camelid

comment created time in 3 days

issue closedrust-lang/rust

RUST_BACKTRACE=1 panic output still includes functions called by panic!

RUST_BACKTRACE=1 panic output still includes the functions called by the panic! macro. This was previously reported in #37783 but, in the merged fix, only the functions before main were removed. This makes it harder to determine which function the panic occurred in.

In filter_frames, skipped_before is always 0.

closed time in 4 days

programmerjake

issue commentrust-lang/rust

RUST_BACKTRACE=1 panic output still includes functions called by panic!

I'm going to close this as fixed. A backtrace from main now looks like this:

thread 'main' panicked at 'explicit panic', src/main.rs:2:5
stack backtrace:
   0: std::panicking::begin_panic
             at /home/eric/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:505:12
   1: z25::main
             at ./src/main.rs:2:5
   2: core::ops::function::FnOnce::call_once
             at /home/eric/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:227:5
programmerjake

comment created time in 4 days

issue commentrust-lang/cargo

beta: cargo metadata uses inconsistent encodings of ids with `branch = master` dependencies

Just an update on my investigation:

New lock files include ?branch=master Starting in 1.47, if you have an explicit branch = "master" in Cargo.toml, and you generate a new lock file, the lock file will end up with ?branch=master in the source field. I'm uncertain if this was intentional. There is code to explicitly avoid that, but that code is only used for dependencies, and not for the package.source field. I feel like that seems wrong, and that should also apply to all sources.

Mixed lock/toml settings cause inconsistencies If you have a Cargo.toml with branch = "master", and an old lock file (pre 1.47), the lock file will not have ?branch=master. This inconsistency is exposed whenever SourceIds are displayed (such as in cargo metadata). In this case, the "resolve" field will not contain ?branch=master in the URLs, but the "packages" array will. This happens because the SourceId for Packages is generated from the dependency declaration (which has branch = "master"), but the Cargo.lock file doesn't have them.

Conversely, if you have a (new) Cargo.lock that contains ?branch=master, and you decide to remove branch = "master" from Cargo.toml, you end up in the opposite situation. The resolve entries will have ?branch=master, and the packages will not.

I've been trying to think of a way to handle this, but haven't gotten too far, and it is getting late. My best idea is that cargo metadata should normalize the "resolve" entries to match whatever is in "packages". That might solve the cargo metadata situation, but I'm still concerned that resolve PackageIds might get exposed in other situations. I think all other scenarios (like JSON messages) come from Package, but there is some risk that a resolve-based SourceId might be exposed somehow.

An alternative, similar to what Alex alluded to in https://github.com/rust-lang/cargo/issues/8101#issuecomment-614091955, is to somehow "sync" the SourceIds in the Resolve after it has been loaded to match what is in the Package objects. That sounds like it would be more reliable, but I'm uncertain how feasible it is.

Nemo157

comment created time in 4 days

issue commentrust-lang/mdBook

Running mdbook build does not create "them" subdirectory

Can you copy the exact error message that is displayed? Also, which version of mdbook are you using? I assume you are using a custom theme? Does the output.html.theme configuration value match where the theme is located?

Ciro-Fusco

comment created time in 4 days

issue commentrust-lang/rustup

rustup.rs website is out of date compared to master

Unfortunately the website updates are tied to releases, so the fix has to wait for the next release (as discussed in #2512).

HoLLy-HaCKeR

comment created time in 4 days

issue commentrust-lang/cargo

`cargo metadata` does not take CARGO_BUILD_TARGET into account

cargo metadata is mostly intended for querying the workspace and resolve configuration. It's actually a bug that it looks at the target at all (#8462).

Where could I learn more about this?

https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#multitarget and #7004 and #6784

jyn514

comment created time in 4 days

push eventehuss/cargo

bors

commit sha acf88cc26ab935a9f652612c4c5739a8e94c6686

Auto merge of #7860 - ehuss:fix-std-collision, r=alexcrichton Fix build-std collisions. `build-std` unit filenames can collide with user dependencies in some situations. In particular, `cc` as a build-dependency is likely to be exactly the same as a user's dep. This would result in the `cc` crate being built twice, but with the same filename, causing a collision. Other dependencies typically never collide because they have the `rustc-dep-of-std` feature, but build-dependencies do not. The solution here is to include `is_std` in the metadata hash. Fixes #7859.

view details

Eric Huss

commit sha da8d17429f21b524411c1e57ddac08826c8d6809

Fix rebuild_sub_package_then_while_package on HFS.

view details

bors

commit sha 06834dcaf2d53175ccf4801a6b6212b5fb56a519

Auto merge of #7855 - ehuss:fix-required-features-renamed, r=alexcrichton Fix required-features using renamed dependencies. The dep_name/feat_name syntax in required-features should use the "name in toml" for dep_name, not the actual package name. Otherwise, it is impossible to actually enable the feature (because the `--features` flag expects a "name in toml").

view details

bors

commit sha 19d38e557536eba1b977ba07a490a22fb78da8cb

Auto merge of #7865 - ehuss:fix-rebuild_sub_package_then_while_package, r=alexcrichton Fix rebuild_sub_package_then_while_package on HFS. This test was flaky on HFS ([azure failure](https://dev.azure.com/rust-lang/cargo/_build/results?buildId=20144&view=logs&j=a5e52b91-c83f-5429-4a68-c246fc63a4f7&t=d4864165-4be3-5e34-b483-a6b05303aa68&l=2018)), resulting in this error: ``` Compiling foo v0.0.1 (/Users/runner/runners/2.164.7/work/1/s/target/cit/t750/foo) error[E0460]: found possibly newer version of crate `b` which `a` depends on --> src/lib.rs:1:1 | 1 | extern crate a; extern crate b; pub fn toplevel() {} | ^^^^^^^^^^^^^^^ | = note: perhaps that crate needs to be recompiled? = note: the following crate versions were found: crate `b`: /Users/runner/runners/2.164.7/work/1/s/target/cit/t750/foo/target/debug/deps/libb-98160c67a5811c37.rlib crate `b`: /Users/runner/runners/2.164.7/work/1/s/target/cit/t750/foo/target/debug/deps/libb-98160c67a5811c37.rmeta crate `a`: /Users/runner/runners/2.164.7/work/1/s/target/cit/t750/foo/target/debug/deps/liba-7d2b9ccd932a36e9.rmeta ``` There are two race-condition bugs here. Race 1: The second cargo build command (`cargo build -pb`) would sometimes not build, because it thought `b` is fresh. This can happen when the first build finishes and changing `b/src/lib.rs` happen within the same second. (#5918) The test silently ignored this failure, this is not the cause of the CI failure, though. Race 2: The first and second build commands work as expected. The third build command fails because it thinks both `a` and `b` are "fresh". However, `b` was just rebuilt, and `a` depends on it, so `a` should have been rebuilt. It thinks `a` is fresh because `a`'s mtime is equal to `b` when `b` finishes compiling within the same second that the first build finished. The solution here is to make sure the second step happens well after the first. The underlying problem is #5918.

view details

Kinrany

commit sha bc4c65c5d3974a8bccb21a468d1b73fa5df3cc38

Do not run `formats_source` if `rustfmt` is not available Generalized `clippy_is_available` and renamed as `command_is_available`. No checks in `ignores_failure_to_format_source`, it's not supposed to use `rustfmt` even if it's available

view details

bors

commit sha db0dac507e399e051a7af3cdf60635f24e1a22e8

Auto merge of #7827 - Kinrany:7656-format-placeholder-code-when-generating-a-crate, r=ehuss Format placeholder code when generating a crate When generating source files in `cargo new` and `cargo init`, try to run `rustfmt` CLI on them. If it fails, log the error and proceed. Tests: * Works for `cargo init --lib` * No changes in behavior if `rustfmt` is missing Closes #7656

view details

Eric Huss

commit sha 3489428921671b274b08ebbabd00128d56ebaa00

Set an environment variable for tests to find executables.

view details

Eric Huss

commit sha 499f917c03f4a4956b83bb497f247e75311528ee

Switch to case-sensitive environment variable.

view details

Eric Huss

commit sha 2061e8661271fd3d1a8935a9f104114c6b3c6904

Emit report on error with Ztimings.

view details

bors

commit sha c55d3636c845c6c798e4af53d278a8a061cd46bf

Auto merge of #7872 - ehuss:timings-error, r=Eh2406 Emit report on error with Ztimings. Previously the report was not saved on error. I'm not actually sure this is all that useful. I was using it to gather a picture of what was being built (I wasn't actually interested in the timing data). There might be better ways to accomplish what I wanted, but it's a small change, so probably doesn't hurt. Fixes #7413.

view details

Eric Huss

commit sha 635c423031d4062386106d9c32a76f2325d3b4e2

Update tar.

view details

Eric Huss

commit sha 8f09ac0c0bcbefcf87df48727768d73642305317

Update jobserver.

view details

bors

commit sha 23ce747f932edbf705e2b2ad329b5d114d1ae459

Auto merge of #7874 - ehuss:update-tar, r=Eh2406 Update tar. Updates to the latest tar. rust-lang/rust is currently on 0.4.20. The change I'm most interested in is fixing the TarError cause/source, so that Cargo reports a better error message. Compare: ``` Caused by: failed to unpack `/…/registry/src/github.com-1ecc6299db9ec823/curl-sys-0.4.25/curl/docs/libcurl/libcurl-multi.3` ``` to the new version: ``` Caused by: failed to unpack `curl-sys-0.4.25/curl/docs/libcurl/libcurl-multi.3` into `/…/registry/src/github.com-1ecc6299db9ec823/curl-sys-0.4.25/curl/docs/libcurl/libcurl-multi.3` Caused by: No space left on device (os error 28) ```

view details

bors

commit sha 1bc7f53139fb06ad58db2a35518415095c3d6684

Auto merge of #7875 - ehuss:update-jobserver, r=alexcrichton Update jobserver. Keep in sync with rust-lang/rust (https://github.com/rust-lang/rust/pull/68663), so that local users and lib users get the same version.

view details

Eric Huss

commit sha 4cf531f5a6939fb92c095dd76e252bf778815b01

Add more docs on CARGO_BIN_EXE_.

view details

bors

commit sha 3c53211c3d7fee4f430f170115af5baad17a3da9

Auto merge of #7857 - ehuss:fix-build-script-dupe, r=alexcrichton Fix BuildScriptOutput when a build script is run multiple times. When I implemented profile build overrides, I created a scenario where a build script could run more than once for different scenarios. See the test for an example. However, the `BuildScriptOutputs` map did not take this into consideration. This caused multiple build script runs to stomp on the output of previous runs. This is further exacerbated by the new feature resolver in #7820 where build scripts can run with different features enabled. The solution is to make the map key unique for the Unit it is running for. Since this map must be updated on different threads, `Unit` cannot be used as a key, so I chose just using the metadata hash which is hopefully unique. Most of this patch is involved with the fussiness of getting the correct metadata hash (we want the RunCustomBuild unit's hash). I also added some checks to avoid collisions and assert assumptions.

view details

Josh Triplett

commit sha e84a4ed6d02293034380761461b09241488070fe

Keep environment variables in a BTreeMap to preserve sort order This prevents verbose output from varying between runs due to HashMap (non-)ordering.

view details

bors

commit sha c31bd9d8aceab993939c9c579c78d30db2371523

Auto merge of #7877 - joshtriplett:env-order, r=ehuss Keep environment variables in a BTreeMap to preserve sort order This prevents verbose output from varying between runs due to HashMap (non-)ordering.

view details

Esteban Küber

commit sha e0787ec2b3feba19e1537265ef398d6f300a3431

Modify test to make `rustc` PR mergeable Modify a test to be less succeptible to failure for wording changes.

view details

bors

commit sha a491aa7179bbcab817d937af33e1b91bf214c316

Auto merge of #7883 - estebank:change-test, r=ehuss Modify test to make `rustc` PR mergeable Modify a test to be less succeptible to failure for wording changes.

view details

push time in 4 days

PR opened rust-lang/cargo

Some minor clippy fixes.
+20 -27

0 comment

12 changed files

pr created time in 4 days

pull request commentrust-lang/rust-clippy

Add --no-deps option to avoid running on path dependencies in workspaces

Thanks for moving this forward!

One more thing, I think when running cargo clippy --fix it should also probably imply --no-deps as well, since it can cause problems with how fix works. I'm not sure how easy that would be to wire in, or if it would have any problems, though.

ebroto

comment created time in 4 days

pull request commentrust-lang/cargo

Add `member` table to cargo config

Thanks for the PR! Almost all major changes to Cargo typically go through the RFC process, though sometimes we allow nightly-only changes if the design is well understood.

I think in this case there is a bit of design space to explore. Generally we haven't allowed workspace-specific settings in config files. Config files are intended more for local-system settings (although admittedly that doesn't always follow in practice). I think for specifying things like this, it would probably want to lean more towards placing settings in Cargo.toml, such as in the [package] table, maybe as a default-target key (or default-targets now that Cargo supports multiple targets?). Additionally, there's some uncertainty about how more sophisticated target settings might be expressed. For example, there is a desire to be able to specify the supported targets of a package or cargo-target (#6179).

These may or may not have some interaction, but I'm not clear on how they might.

Richard-W

comment created time in 4 days

push eventehuss/cargo

Eric Huss

commit sha e8bc4427bf022022391f08ca163ab34d40daa2fb

Expose implicit features in `cargo metadata`.

view details

Eric Huss

commit sha f999a5e5a328bfd18c34b32614757187d5cd5bcb

Some minor cleanup.

view details

push time in 4 days

issue commentrust-lang/cargo

`cargo metadata` does not take CARGO_BUILD_TARGET into account

We are a little reluctant to add the default target to cargo metadata because Cargo is moving towards supporting multiple targets during the same build, so it is not really clear how that would be exposed. Additionally, cargo metadata is geared for pre-build information, and we don't want to go further down the road towards including things like artifact outputs.

Would it work to have something like cargo config build.target which would fetch and display the confg value if it is defined?

jyn514

comment created time in 4 days

issue commentrust-lang/rust

SIGSEGV from rustc while building crate `legion`

The simplification listed above fails on some versions, but not all. It seems to be really sensitive and will pass where the original legion still fails. For example, nightly-2020-10-03 fails where nightly-2020-10-04 passes. However, legion still fails for me on nightly-2020-10-04.

I did fair bit of investigation, but did not find anything terribly useful. It is very sensitive to the exact code layout and optimization settings of rustc. For example, compiling rustc_resolve with -O2 causes the problem to go away. Adding #[inline(always)] to resolve_pattern_top also makes the problem go away.

I cannot rule out that it is AMD-specific because I don't have easy access to a fast Intel system. I was unable to repro in a virtual machine on an Intel machine. I was also unable to repro on macOS (Intel) or Windows (AMD).

If someone can reproduce on an Intel Linux system, that would help rule out anything CPU-specific. If they can get it to fail, then running rr could be really helpful, since I can't seem to get it to work correctly on my AMD system.

The script I use to run is:

#!/bin/bash

# Run with RUSTUP_TOOLCHAIN=<toolchain name> to test different toolchains.

ulimit -c unlimited

set -e

rustc -V

for i in {1..1000}
do
    echo $i
    rustc --crate-type rlib foo.rs --emit=metadata
    # Change to this if testing a cargo project:
    # touch src/lib.rs
    # cargo check
done
tput bel
alex5nader

comment created time in 5 days

create barnchehuss/rust-77869

branch : master

created branch time in 5 days

created repositoryehuss/rust-77869

created time in 5 days

issue commentrust-lang/cargo

beta: cargo metadata uses inconsistent encodings of ids with `branch = master` dependencies

@alexcrichton I think this is related to #7841 and #8101. There are some oddities with how SourceMap works. In this case, the SourceId in SourceMap is initialized from the Dependency which is SourceKind::Git(GitReference::DefaultBranch). This SourceId is the id that ends up in the PackageId for packages in the PackageSet which gets displayed in the "packages" array.

However, PackageIds in the resolver have a SourceId of SourceKind::Git(GitReference::Branch("master")) because it was deserialized with that specific branch name.

I'll try to investigate some more and think if all these issues can be untangled somehow. The fact that multiple SourceId's map to the same SourceId in SourceMap seems to be the root of all of these, though I'm uncertain on the path to fix them. If you have any ideas, let me know, otherwise I'll keep digging. Is there maybe some way the SourceId can be "upgraded" to the more specific variant inside the Package struct?

Nemo157

comment created time in 5 days

issue commentrust-lang/cargo

Cargo ingores branch in .gitmodules when fetching submodules of dependencies

I'm also a bit confused what exactly the issue here is.

AFAIK, the branch field in .gitmodules is only used when running git submodule update. It doesn't indicate which branch the submodule is actually pointing to. The submodule points to an OID which is what cargo checks out.

The following example checks out the submodule for the given branch foo.

mkdir tmp
cd tmp
mkdir sub
cd sub
git init
git checkout -b foo
touch foo
git add foo
git commit -m test
cd ..
cargo new --lib test-dep
cd test-dep
git submodule add -b foo file://$(realpath $(pwd)/../sub) sub
git add Cargo.toml src
git commit -m test
cd ..
cargo new test-leaf
cd test-leaf
echo "test-dep = {git=\"file://$(realpath $(pwd)/../test-dep)\"}" >> Cargo.toml
cargo update
turbocool3r

comment created time in 5 days

issue commentrust-lang/mdBook

CMD (Windows batch script) syntax highlighting and compatibility with the latest highlight.js

cmd is not in the default language set. When you built highlight.js, did you enable it? I believe the language is called dos.

noarchwastaken

comment created time in 5 days

PR opened rust-lang/cargo

Update TOML website links.

Update the links to the new, fancy TOML website. Also added a few more links.

Closes #8800

+10 -6

0 comment

5 changed files

pr created time in 5 days

create barnchehuss/cargo

branch : toml-links

created branch time in 5 days

issue commentrust-lang/cargo

cargo-tree: A flag to get parent crates of a package id

Why does cargo tree -i -p openssl-sys work when there is no spec after -i ?

Backwards compatibility with the original cargo tree.

lzutao

comment created time in 5 days

issue commentrust-lang/cargo

Output filename collision with dylib on windows release mode

I'm kind of surprised build deps are automatically normal deps, is there a way to disable that?

When you run cargo build in the root of a virtual workspace, it builds all members as normal packages. You can set default-members to change that behavior.

khyperia

comment created time in 5 days

push eventehuss/cargo

Eric Huss

commit sha 1fc0a168ded6e560edd9f813a17e4a40c992332d

New namespaced features implementation.

view details

push time in 6 days

push eventehuss/cargo

Eric Huss

commit sha babc25ff546736b8e7c02b9d6ef758f0503a56ff

New namespaced features implementation.

view details

push time in 6 days

pull request commentrust-lang/rust

Update cargo

@bors r+

ehuss

comment created time in 6 days

PR opened rust-lang/rust

Update cargo

3 commits in 79b397d72c557eb6444a2ba0dc00a211a226a35a..dd83ae55c871d94f060524656abab62ec40b4c40 2020-10-15 14:41:21 +0000 to 2020-10-20 19:31:26 +0000

  • Support glob patterns for package/target selection (rust-lang/cargo#8752)
  • Update env_logger requirement from 0.7.0 to 0.8.1 (rust-lang/cargo#8795)
  • Fix man page links inside option blocks. (rust-lang/cargo#8793)
+15 -2

0 comment

2 changed files

pr created time in 6 days

push eventehuss/rust

Mark Rousskov

commit sha e023158145ece18176a2e93420600ccda0d0bc58

Permit uninhabited enums to cast into ints This essentially reverts part of #6204.

view details

Mark Rousskov

commit sha 990a39596cf3b33e550f2045f78a62970f8d78f8

Prevent ICE on uninhabited MIR interpretation

view details

Nathan West

commit sha a02014280586b53997622c501db00398376967a8

Refactor io/buffered.rs into submodules

view details

Nathan West

commit sha 96229f02402e82914ec6100b28ad2cbdd273a0d4

move buffered.rs to mod.rs

view details

Nathan West

commit sha 6d75cdfc9ed9e6987bd23add6cf3954d2499dce2

Added updated compiler diagnostic

view details

Amjad Alsharafi

commit sha da700cba08a2b194d19e63d3c51ebadce96fe46b

Stabilize move_ref_pattern

view details

Amjad Alsharafi

commit sha afb9eeb1b9ea16ca65e38673a0ef3e7be81d7252

Disabled error `E0007` from rustc_error_codes

view details

Mark Rousskov

commit sha 05c9c0ee5dcd935f518db151bee2dc88380fb92f

Modify executable checking to be more universal This uses a dummy file to check if the filesystem being used supports the executable bit in general.

view details

Nathan West

commit sha c4280af8285c61b367a87c8f6eef9876011a8150

Retry fix error reporting suggestions

view details

dylni

commit sha 1ff7da6551a7cdf6ace2a9d00e92bbab550334ee

Move `slice::check_range` to `RangeBounds`

view details

dylni

commit sha 1095dcab96d524e700b11edf366d45a0fd173fa0

Fix links

view details

dylni

commit sha eb63168e007058dad4af758faf1dca449c049777

Fix doctests

view details

dylni

commit sha f055b0bb0847ecf08fe452a270faae8324b55b05

Rename method to `assert_len`

view details

Bastian Kauschke

commit sha fd22e87afc9082522bc7b52e32d25d43c64594e6

fix flag computation for `ExistentialPredicate::Projection`

view details

Bastian Kauschke

commit sha 7652b4b1d9cec0ad22f529a4335d05f7d7792521

guard against `skip_binder` errors during FlagComputation

view details

Camelid

commit sha 549f861f7d53811521cf929cf58fb6828a2a88d9

Use correct article in help message for conversion or cast Before it always used `an`; now it uses the correct article for the type.

view details

Camelid

commit sha 094f14c554c3a1f103a5d6778d4b4e131c297f11

Add article after "to" Also added missing backtick in "you can cast" message.

view details

Camelid

commit sha 8a6831a7fd3fc624643b50f494212e0ceaad3c28

Say "doesn't" instead of "wouldn't" in convert message

view details

Temirkhan Myrzamadi

commit sha 13dfbb64d313137b7d3c33067910e90f27bc6345

Suggest imports of unresolved macros

view details

Temirkhan Myrzamadi

commit sha 479298e05e8177b171c6d6bcd35fc7553b424bee

Re-run tests with --bless

view details

push time in 6 days

issue commentrust-lang/cargo

Tracking issue for namespaced-features

I have posted a PR at #8799 to propose the new behavior which I described above which should make it backwards compatible (avoiding the opt-in) and fix all the known issues.

djc

comment created time in 6 days

PR opened rust-lang/cargo

New namespaced features implementation.

This is a new implementation for namespaced features (#5565). See the unstable.md docs for a description of the new behavior. This is intended to fix several issues with the existing design, and to make it backwards compatible so that it does not require an opt-in flag.

This also includes tangentially-related changes to the new feature resolver. The changes are:

  • crate_name/feat_name syntax will now always enable the feature crate_name, even if it is an inactive optional dependency (such as a dependency for another platform). The intent here is to have a certain amount of consistency whereby "features" are always activated, but individual crates will still not be activated.
  • --all-features will now enable features for inactive optional dependencies. This is more consistent with --features foo enabling the foo feature, even when the foo dep is not activated.

I'm still very conflicted on how that should work, but I think it is better from a simplicity/consistency perspective. I still think it may be confusing if someone has a cfg(some_dep) in their code, and some_dep isn't built, it will error. The intent is that cfg(accessible(some_dep)) will be the preferred method in the future, or using platform cfg expression like cfg(windows) to match whatever is in Cargo.toml.

Closes #8044 Closes #8046 Closes #8047 Closes #8316

Questions

  • For various reasons, I changed the way dependency conflict errors are collected. One slightly negative consequence is that it will raise an error for the first problem it detects (like a "missing feature"). Previously it would collect a list of all missing features and display all of them in the error message. Let me know if I should retain the old behavior. I think it will make the code more complicated and brittle, but it shouldn't be too hard (essentially Requirements will need to collect a list of errors, and then resolve_features would need to check if the list is non-empty, and then aggregate the errors).

  • Should cargo metadata show the implicit features in the "features" table? Currently it does not, and I think that is probably best (it mirrors what is in Cargo.toml), but I could potentially see an argument to show how cargo sees the implicit features.

+1796 -848

0 comment

29 changed files

pr created time in 6 days

push eventehuss/cargo

roblabla

commit sha 58bc357f36ec7bdd1ecc01885e03a169fec655d7

Add homepage and documentation to package in cargo metadata

view details

roblabla

commit sha 72694e801505ff6a90c8fa328254a25edb1db073

Fix tests

view details

roblabla

commit sha 435117a821a9c5b4f12f68b0d076fbab20f18c1b

Test that homepage/documentation values are properly propagated

view details

roblabla

commit sha 26d1a25d93113f210b6fd8563b589da50157cf51

Add homepage/documentation to cargo-metadata docs

view details

bors

commit sha 1f6c6bd5e7bbdf596f7e88e6db347af5268ab113

Auto merge of #8744 - roblabla:homepage-doc-cargo-metadata, r=alexcrichton Homepage doc cargo metadata Adds two new field to cargo-metadata: `homepage` and `documentation`, lifted directly from the Cargo.toml. This additionally makes those fields available through `cargo read-manifest`.

view details

Weihang Lo

commit sha be31989a43ecee8904a8ff1448580695b13d1645

test: minimal shell quote supoort for cargo-test-support

view details

Weihang Lo

commit sha 42696ae234dfb7b23c9638ad118373826c784c60

feat: glob support for target selection

view details

Weihang Lo

commit sha 633e5f004889f46055b563a1f45854410222c8c2

test: glob support for target selection

view details

Weihang Lo

commit sha 2361fb0f6a8759bab9a6b241e2ef7f75ef98688a

feat: glob support for package selection

view details

Weihang Lo

commit sha ab88c48480e41794b4ee3b6ec465aba4eff5991f

test(tree): glob support for package selection

view details

Weihang Lo

commit sha db313e54a2d7e719b609826ff2b090e761453c9d

test(rustc): glob support for package selection

view details

Weihang Lo

commit sha 570aea75ead37d58908d906cb5afa21e186944db

test(rustdoc): glob support for package selection

view details

Weihang Lo

commit sha f1de239450f1829dbf86eb9e9f71c5dc0cbeb3ce

test(doc): glob support for package selection

view details

Weihang Lo

commit sha a06ec889f4ce2d12bbb52d50a13653afa5f35ab2

test(bench): glob support for package selection

view details

Weihang Lo

commit sha 33d883c425644392c8d3214311558a1d71714dbb

test(run): glob support for package selection

view details

Weihang Lo

commit sha 667a5aedfba3e7eca76cc70cc04b3c446e218f90

test(build): glob support for package selection

view details

Weihang Lo

commit sha 8d5e11a52078b62306cca7dd608e484d0a679d7d

test(check): glob support for package selection

view details

Weihang Lo

commit sha 6fb6b94a33a0152d3b77d6033ac3b666dff272dd

test(test): glob support for package selection

view details

Weihang Lo

commit sha b3441f9b9154d6beb101349ff4faafc479a1b10a

doc: glob pattern support for package/target selection

view details

Weihang Lo

commit sha 4a61d8a41266f3a6366c666d86d09ebfcc789770

doc: build-man.sh for glob pattern support

view details

push time in 6 days

issue commentrust-lang/cargo

cargo vendor: build plan wrong when the dependency is a git dependency

The .cargo/config in your sample repository doesn't look like it is complete. After running cargo vendor, it should have printed:

To use vendored sources, add this to your .cargo/config for this project:

[source.crates-io]
replace-with = "vendored-sources"

[source."https://github.com/danburkert/prost.git"]
git = "https://github.com/danburkert/prost.git"
rev = "6113789f70b69709820becba4242824b4fb3ffec"
replace-with = "vendored-sources"

[source.vendored-sources]
directory = "vendor"

which includes the additional source replacement for the git repository.

benma

comment created time in 6 days

issue commentrust-lang/cargo

Output filename collision with dylib on windows release mode

Thanks for the report! Can you say more about why you are using a dylib with a build dependency?

The reason for the collision is that thedylib is being built twice, once as a normal dependency, and once as a build dependency, because build dependencies are built without optimization. In the dev profile, the profile settings are the same so it is only built once, but with --release they get split.

A workaround is to use the --target flag. This causes the output of build dependencies to be stored in a separate directory.

The error message could definitely be better in this case. And ideally it wouldn't happen at all, but there are constraints for naming DLLs on windows that make it difficult. I think something like #6668 would probably be a lead towards fixing this (or maybe making it much worse, I forget!). In general, shared library naming causes a fair bit of trouble, so it is difficult to manage.

khyperia

comment created time in 6 days

issue commentrust-lang/cargo

`cargo metadata` does not take CARGO_BUILD_TARGET into account

I think the specific layout rules are stable and not something we will likely change. That is:

  • $CARGO_TARGET_DIR/doc is the doc output if --target is not specified.
  • $CARGO_TARGET_DIR/$TARGET/doc is the doc output if --target is specified.

It doesn't look like cargo metadata gives you $TARGET, so that is a little awkward if you are using config files. If possible, you can also use JSON messages from cargo which will tell you the output path from rustdoc.

jyn514

comment created time in 6 days

issue commentrust-lang/cargo

`cargo clean -p` does not clean documentation

I think part of the problem is that the search index would be broken since it would contain references to the now missing package.

jyn514

comment created time in 6 days

issue commentrust-lang/cargo

Cargo new fails with side effect when $USER env variable is not set

I would also suggest that it could maybe query the operating system for the username. Or, it could just not fill out the authors field and print a warning or something.

nixphix

comment created time in 6 days

issue commentrust-lang/cargo

cargo-tree: A flag to get parent crates of a package id

Do you have suggestions on where else it could be documented? https://doc.rust-lang.org/cargo/commands/cargo-tree.html mentions --invert as the first option, and the "Examples" section shows how it can be used for a similar situation.

lzutao

comment created time in 6 days

issue closedrust-lang/cargo

Add filter to only run integration tests.

<!-- Thanks for filing a 🙋 feature request 😄! -->

Describe the problem you are trying to solve <!-- A clear and concise description of the problem this feature request is trying to solve. --> Currently cargo test --tests runs both unit and integration tests. Using cargo test --lib runs only the unit-tests of the library, however there is no way to only let the integration tests run, apart from maybe using a naming scheme for the integration tests, which I would like to avoid. It's also possible to write a script which calls cargo test --test <name> for each .rs file in the tests folder, but again, this is something I would like to avoid.

Describe the solution you'd like <!-- A clear and concise description of what you want to happen. --> I would like to run only the integration tests with e.g. cargo test --integration_tests.

Notes <!-- Any additional context or information you feel may be relevant to the issue. --> Looking into libtest the enum TestType seems to already provide the necessary information.

closed time in 6 days

jschwe

issue commentrust-lang/cargo

Add filter to only run integration tests.

I'm going to close this as fixed by #8752. It now adds the syntax --test '*' which will select all integration tests. It should land on nightly within a few days.

jschwe

comment created time in 6 days

issue closedrust-lang/cargo

Conditional RUSTFLAGS in .cargo/config?

<!-- Thanks for filing a 🙋 feature request 😄! -->

Describe the problem you are trying to solve <!-- A clear and concise description of the problem this feature request is trying to solve. --> I know that there is a [build] section in .cargo/config file that accepts rustflags, but the problem is, it is effective all the time.

I would like to use some rustflags ONLY under several profiles separately. For example, it would be best if there exists something equivalent to:

[build.dev]
rustflags = [
    "-Ctarget-cpu=native",
    # some other flags
]

Note that I only want those flags under RELEASE builds, and they shall have no effect under DEV builds.

Describe the solution you'd like <!-- A clear and concise description of what you want to happen. --> Probably a [build.dev] section?

Notes <!-- Any additional context or information you feel may be relevant to the issue. -->

closed time in 6 days

jerryc05

issue commentrust-lang/cargo

Conditional RUSTFLAGS in .cargo/config?

Closing as a duplicate of #7878.

jerryc05

comment created time in 6 days

issue closedrust-lang/cargo

LLVM pass with cargo

Hi, would like to check how to do custom llvm passes in cargo, I am using the following command: RUSTFLAGS="-C passes=my-custom-pass" cargo build

As expected, I got: warning: unknown pass my-custom-pass, ignoring

How do i load my customPass.so? TIA

closed time in 6 days

gladys95a

issue commentrust-lang/cargo

LLVM pass with cargo

Cargo just passes flags to rustc, so I don't think this is really a cargo issue. I'm not familiar with custom LLVM passes, but if it requires a custom LLVM, then you'll probably need to rebuild rustc with your custom LLVM.

Questions like these would probably be better to ask on one of the user forums like https://users.rust-lang.org/.

gladys95a

comment created time in 6 days

issue commentrust-lang/cargo

Enable build-std on a per target basis

Is there any particular reason you don't want it for built-in targets?

MarnixKuijs

comment created time in 6 days

issue commentrust-lang/cargo

Check Cargo.lock in version control for libraries

I think it would be fine to add some more details to the documentation. There's a tradeoff, if Cargo.lock is included in source control, you'll likely be testing out-of-date dependencies. That's good for reproducibility as you say, but is bad because you won't quickly catch problems with new dependencies. If you have the CI budget, you can of course test both with Cargo.lock, and with the latest versions (by calling cargo update && cargo test).

tiziano88

comment created time in 6 days

issue commentrust-lang/cargo

Support for vendoring on a single platform

@Eh2406 wrote some details about this at https://github.com/rust-lang/cargo/issues/8723#issuecomment-696314612.

nipunn1313

comment created time in 6 days

issue closedrust-lang/cargo

cargo vendor should support OS support restrictions

<!-- Thanks for filing a 🙋 feature request 😄! -->

Describe the problem you are trying to solve I need to vendor dependencies to ensure that the source repo is the only thing required to build to meet , and only target linux amd64 and linux arm64. However, cargo vendor includes dependencies for targets I don't care about, which ultimately ends up with fat dlls in my git repo.

Describe the solution you'd like I would like to have a Cargo.toml setting that tells cargo vendor and the rest of the toolchain we only care about certain operating systems or operating system families, and reduces the crates vendored accordingly.

Notes <!-- Any additional context or information you feel may be relevant to the issue. -->

closed time in 6 days

wbl

issue commentrust-lang/cargo

cargo vendor should support OS support restrictions

I'm going to close this as a duplicate of #7058.

wbl

comment created time in 6 days

pull request commentrust-lang/cargo

Support glob patterns for package/target selection

Nah, the fcp is just whether or not to approve, merge conflicts don't reset the timer.

I think this is good to go, so I'll go ahead and approve. @bors r+

weihanglo

comment created time in 6 days

push eventehuss/cargo

Eric Huss

commit sha 32559b3b6fa5b1ba1d5ffee3e2dccc0c289072dc

New namespaced features implementation.

view details

push time in 6 days

create barnchehuss/cargo

branch : new-namespaced

created branch time in 6 days

issue commentrust-lang/mdBook

no use to set "output.html.print.enable = false"

That feature hadn't been released, yet. I just released 0.4.4, can you try to upgrade and check it out?

2372281891

comment created time in 6 days

created tagrust-lang/mdBook

tagv0.4.4

Create book from markdown files. Like Gitbook but implemented in Rust

created time in 6 days

release rust-lang/mdBook

v0.4.4

released time in 6 days

push eventrust-lang/mdBook

Eric Huss

commit sha a76557a678aeded8344acba2f929edb5b5ac8f3e

Release 0.4.4

view details

Eric Huss

commit sha eaa69142059c04ca14aa23ffeb1fe1469663403f

Merge pull request #1360 from ehuss/release-next Release 0.4.4

view details

push time in 6 days

PR merged rust-lang/mdBook

Release 0.4.4
+17 -2

0 comment

3 changed files

ehuss

pr closed time in 6 days

PR opened rust-lang/mdBook

Release 0.4.4
+17 -2

0 comment

3 changed files

pr created time in 6 days

push eventehuss/mdBook

Eric Huss

commit sha cf7663f80052662a73fbded54711063764d50a84

Merge pull request #1317 from ehuss/release-next Release 0.4.3

view details

ifeanyi

commit sha e225586953ae244736b3dbd0e12b2a9ffa927abb

Resolve full file paths when copying files Currently, the `copy_files` function doesn't support symlink files due to its use of `DirEntry::metadata` - To avoid this issue, this patch resolves the file path first before checking for metadata. Fixes #1157

view details

ifeanyi

commit sha b349e8abc91263d91c93c5e8804a18b38d4e3295

Fix windows typo

view details

Eric Huss

commit sha 5ebd2c0527f08bd6b607b31904c9b15888221f0b

Fix macOS CI deploy.

view details

Eric Huss

commit sha daf402e1dc30c1324d92889071876d6d4686ac26

Merge pull request #1324 from ehuss/purge Fix macOS CI deploy.

view details

Eric Huss

commit sha a94a940ff750b5a7fffb2d8182f1285baf598191

Fix macOS CI deploy take 2.

view details

Camelid

commit sha d1682d27fbf21c7e1e122f8f51f307e4f305ad26

Improve README wording

view details

Camelid

commit sha 2eccb457d2c36cfe91f9519a1736c1be71f708c6

gitignore: Ignore Vim temporary and swap files (#1328)

view details

Eric Huss

commit sha 39d713001987c95b27bf96e1d6d5f8ce79e8f9b4

Merge pull request #1325 from camelid/patch-2 Improve README wording

view details

Eric Huss

commit sha db8a2821eac4ee8ce1b6b93885372d4df9a32f24

Merge pull request #1323 from iffyio/copy-symlinks Resolve full file paths when copying files

view details

Ross MacArthur

commit sha e0b247e9d6ec16c66d9eb630c992b4a9a49108d9

Add config option to disable print html, css, and icon

view details

Eric Huss

commit sha d1f5ecc103b9020fab2fa63d9a9a040961261695

Merge pull request #1169 from rossmacarthur/ft/no-print Add config option to disable print html, css, and icon

view details

Eric Huss

commit sha e6ac8ecdd98a7eb52f1113282fe0be14adf99ac8

Fix print icon.

view details

Eric Huss

commit sha d0deee90b04068ed949f524bb682a47fa26f2218

Merge pull request #1335 from ehuss/fix-print Fix print icon.

view details

Camelid

commit sha b77942d3c8e2d62648536b317e426b5ef404d9bf

Rename `book-example` to `guide` (#1336) `book-example` is a bit of a strange name given that it's not just an example.

view details

Camelid

commit sha 4c951d530d7cf225fcca18d6e9146b28bf8dcf10

List supported Highlight.js languages in guide (#1345) * List supported Highlight.js languages in guide Generated using the technique described in https://github.com/rust-lang/mdBook/issues/1275#issuecomment-655903967. * Improve wording in guide

view details

Eric Huss

commit sha f7c9180d8034f605a18b8d2cee0ad76946c94875

Fix typo in changelog

view details

Eric Huss

commit sha 46ce077de621cea2f532d591e0c6b1c61cec3f0b

Update deprecated GitHub Actions commands.

view details

Eric Huss

commit sha 01836ba5d4101d077d9b75ae2ce13ffb6c3d2e24

Merge pull request #1348 from ehuss/github-deprecated-action-commands Update deprecated GitHub Actions commands.

view details

Eric Huss

commit sha a76557a678aeded8344acba2f929edb5b5ac8f3e

Release 0.4.4

view details

push time in 6 days

push eventrust-lang/mdBook

Eric Huss

commit sha 46ce077de621cea2f532d591e0c6b1c61cec3f0b

Update deprecated GitHub Actions commands.

view details

Eric Huss

commit sha 01836ba5d4101d077d9b75ae2ce13ffb6c3d2e24

Merge pull request #1348 from ehuss/github-deprecated-action-commands Update deprecated GitHub Actions commands.

view details

push time in 6 days

more