text:
Incorrect inference of match expression result

commit 5aba5a756a19a54d5c4edd51d8055db36182688b
Merge: a4431e830 56e3fbe58
Author: bors[bot] <26634292+bors[bot]@users.noreply.github.com>
Date:   Thu Feb 6 23:00:07 2020 +0000

    Merge #3042

The following snippet from wasmtime repo is mistakenly inferred as ! instead of FrameUnwindKind:

The following works:
enum E {
    A,
    B,
}

fn foo(e: E) -> E {
    let x = match e {
        E::A => 1,
        _ => {
            return E::B;
        }
    };
    E::A
}

Does "go to definition" work for CallConv and FrameUnwindKind?

Update: if I move corresponding use imports to the topmost scope it all starts working as expected:

Does "go to definition" work for CallConv and FrameUnwindKind?

Nope, it wasn't working before the import change. As you may see, on the first screenshot CallConv and FrameUnwindKind are not highlighted as types.

Yeah, use in local scopes doesn't work too great: #1165.

Yeah, use in local scopes doesn't work too great: #1165.

Oh, indeed. And @matklad's reply there states that probably this will not be resolved anytime soon. That's unfortunate :(

Still, you could argue that the inference should work better. I think the issue is that FrameUnwindKind can't be resolved. The type of match should probably be {unknown}, not !.
It's probably a bug in #1945, but I don't really understand the code :cat:.

The type of match should probably be {unknown}, not !.

Agree. It's very strange that type is inferred that way given that analyzer clearly does not have enough information.

let x = match 0 {
    _ => y,
};

x gets inferred as !.

Maybe you can update the first post with my example above, since it's simpler?

#3114 fixes the reduced case where there are no match arms that diverge, but if there's a diverging match arm (like in the original case), we'll still fall back to !. Interestingly, rustc seems to fall back to () in at least some of these cases. This will require some further thought :thinking:

@flodiebold, as for the () issue recent reddit post discusses similar behavior.

Type inference works fine now for:
enum E {
    A,
    B,
}

fn foo(e: E) -> E {
    let x = match e {
        E::A => 1,
        _ => {
            return E::B;
        }
    };
    E::A
}

I think this can be closed.

authors: 0x7CFE flodiebold lnicola

repo: rust-analyzer/rust-analyzer


text:
Make fill_match_arm work with trivial arm

Addresses this issue https://github.com/rust-analyzer/rust-analyzer/issues/1399
One minor issue I noticed is that complete_postfix creates an arm like this
                match E::X {
                    <|>_ => {},
                }

but fill_match_arms creates arms like this
                     E::X => (),

bors r+
Thanks!

source: gharchive/pull-request

authors: ironyman matklad

license_type: permissive

license_source: github-api


text:
implement binary operator overloading type inference

Extend type inference of binary operator expression, by adding support for operator overloads.
Before this merge request, the type inference of binary expressions could only resolve operations done on built-in primitive types. This merge requests adds a code path, which is executed in case the built-in inference could not get any results. It resolves the proper operator overload trait in core::ops via lang items, and then resolves the associated Output type.
struct V2([f32; 2]);

#[lang = "add"]
pub trait Add<Rhs = Self> {
    /// The resulting type after applying the `+` operator.
    type Output;

    /// Performs the `+` operation.
    #[must_use]
    fn add(self, rhs: Rhs) -> Self::Output;
}

impl Add<V2> for V2 {
    type Output = V2;

    fn add(self, rhs: V2) -> V2 {
        let x = self.0[0] + rhs.0[0];
        let y = self.0[1] + rhs.0[1];
        V2([x, y])
    }
}

fn test() {
    let va = V2([0.0, 1.0]);
    let vb = V2([0.0, 1.0]);

    let r = va + vb; // This infers to V2 now
}

There is a problem with operator overloads, which do not explicitly set the Rhs type parameter in the respective impl block.
Example:
impl Add for V2 {
    type Output = V2;

    fn add(self, rhs: V2) -> V2 {
        let x = self.0[0] + rhs.0[0];
        let y = self.0[1] + rhs.0[1];
        V2([x, y])
    }
}

In this case, the trait solver does not realize, that the Rhs type parameter is actually self in the context of the impl block. This stops type inference in its tracks, and it can not resolve the associated Output type.
I guess we can still merge this back, because it increases the amount of resolved types, and does not regress anything (in the tests).
Somewhat blocked by https://github.com/rust-analyzer/rust-analyzer/issues/5685
Resolves  https://github.com/rust-analyzer/rust-analyzer/issues/5544

It should be possible to replace the builtin inference rules, but that may need default type parameters to be implemented first to prevent a regression.

It should be possible to replace the builtin inference rules, but that may need default type parameters to be implemented first to prevent a regression.

Yes, but @flodiebold mentioned we should keep around the built-in for performance.

LGTM!

LGTM, r=me with the test mark matklad mentioned.
bors delegate+

Seems like there is another issue. The current code can not handle primitive float / integer types at the Rhs of an expression:
#[derive(Copy, Clone)]
struct V2([f32; 2]);

#[lang = "mul"]
pub trait Mul<Rhs = Self> {
    type Output;

    #[must_use]
    fn mul(self, rhs; Rhs) -> Self::Output;
}

impl Mul<f32> for V2 {
    type Output = V2;

    fn mul(self, rhs: f32) -> V2 {
        let x = self.0[0] * rhs;
        let y = self.0[1] * rhs;
        V2([x, y])
}

fn test() {
    let va = V2([0.0, 1.0]);

    let r = va * 1.5f32;
}

r is inferred as f32.
binary_op_return_ty() just looks at the Rhs for add,mul,... and just returns this type as the expression result type, if the type is a primitive int/float.
If I change that, there are multiple regressions in the type inference.

Hm, by regressions you mean tests failing?

Hm, by regressions you mean tests failing?

Yes. I fixed it by checking if the left side of the expression is int / float -> take the cheap path, and for everything else the path with the trait solver.
Sometimes the left side can not be resolved, but the right side can. E.g. in closure_1() test the x.map(|v| v + 1); and some others.
Not sure if this problem can be solved locally...

Hm. The left side in that expression should be able to be resolved though. In general I think checking the left side should be a good approach.
This PR looks good right now though, so let's merge it and do further fixes in a follow-up.
bors r+

authors: bjorn3 flodiebold kjeremy ruabmbua


text:
Make address encoding more modular / flexible

Would be possible to put the bech32 hrp, base58 version, etc. into the Network directly?
E.g. pub struct Network { pub bech32_hrp: &'static str, ... }.
Then the data would not be scattered around like here, aiding readability.
The predefined networks (Bitcoin, Testnet, etc). could then be constants to choose from.
It would look something like this: https://github.com/digitalbitbox/bitbox02-firmware/blob/5003a78801faca996cc4d027ef36818e9f711bf7/src/rust/bitbox02-rust/src/hww/api/bitcoin/params.rs#L22
This would make it easy for clients use network parameters for other chains without needing to make PRs by simply defining their own network instances.
Imho this would be much better than adding all network params that users requests to this repo. Adding to the Network enum would be a breaking change every time.
Context: I am looking into using this crate in the BitBox02 firmware. It seems promising that we could start using this crate, but is missing e.g. Litecoin params.
Let me know if this would be good change, then I could attempt a PR.

This change looks quite invasive. A better solution might to add the p2pkh, p2sh, p2wpkh, p2shwpkh etc. functions also to Payload, making it usable without tying it to a network like the Address does. It would be some additional functions and no breaking change.

Please check this PR as a proposal, following my 2nd comment to introduce this function in a backwards compatible way:
https://github.com/rust-bitcoin/rust-bitcoin/pull/643

Seems to be closed by #643. @benma please feel free to re-open this issue if I missed something

source: gharchive/issue

authors: benma dr-orlovsky

repo: rust-bitcoin/rust-bitcoin


text:
make heapless optional

Makes heapless an optional dep
Feature gate heapless uses throughout the code
Enable heapless feature by default for backwards compat

My rational is that I only ever use the {to,from}_slice methods in this crate, pulling in a heapless dep for no reason.

Done :)

repo: rust-embedded-community/serde-json-core


text:
reduce the size of default handlers

this commit replaces the two default handler (DefaultDefaultHandler and
DefaultUserHardFault) by a single handler named EndlessLoop. This results in
one less symbol being generated.
Also this new handler uses compiler_fence to avoid the "infinite loops w/o
side effects are undef values" bug in LLVM. compiler_fence is guaranteed to
generate no code so this reduces the size of the handler (when compiler in
release).

As far as I could test this new handler doesn't generate abort instructions when
optimized so it seems like a safe replacement. If we are feeling paranoid then
once #95 we could implement EndlessLoop in assembly.
r? @rust-embedded/cortex-m (anyone)

Couple of comments

Does this mean you can no longer tell the difference between a HardFault and any other unhandled exception, without defining your own handlers? Not the biggest deal since most debuggers will catch HardFault before it triggers the exception handler anyway, but worth considering. Worth the small reduction in binary size IMO.

EndlessLoop vs InfiniteLoop / InfiniteLoopDefaultHandler?

Does this mean you can no longer tell the difference between a HardFault and any other unhandled exception, without defining your own handlers?

With or without this change you can put your breakpoint on the HardFault symbol and that will halt your program before it jumps into the user hard fault handler. (So no ExceptionFrame info at that point). Being able to break after that trampoline requires knowing whether the default user hard fault handler has been overridden or not. If it's the default then break on EndlessLoop; if it has been overridden break on UserHardFault.
But in any case once you are in EndlessLoop (or in DefaultUserHardFault) you can't inspect the exception frame using print *ef because ef is missing from the function arguments. That is a disadvantage. To preserve the ef argument we would need two default handler with different signatures.

EndlessLoop vs InfiniteLoop / InfiniteLoopDefaultHandler?

InfiniteLoopDefaultHandler seems too long
I'll try with two handlers and the compiler_fence.

OK, I have changed to two separate default handlers. This still saves 18 bytes (before it was 20 bytes) and one now can inspect ExceptionFrame from the default user hard fault handler -- without this commit that was not possible because DefaultUserHardFault had the wrong signature.
I have named the default handlers DefaultHandler_ and UserHardFault_ so they show when autocompleting for b Default... and b User....

Thanks! I guess the only question is if the extra two bytes is worth the marginally easier debugging hard faults when using the default handlers. On balance I think it's probably worth it. The new names seem good.
0800069a <UserHardFault_>:
 800069a:	e7fe      	b.n	800069a <UserHardFault_>

0800069c <DefaultHandler_>:
 800069c:	e7fe      	b.n	800069c <DefaultHandler_>

(I'm holding off on bors to check you're happy that this is done and ready, feel free to r= me if so).

bors r=adamgreig

authors: adamgreig japaric

repo: rust-embedded/cortex-m-rt


text:
Allow calling interrupt::free with zero-arity closures. (0.7.x)

0.8 will only accept zero-arity closures, this will make the transition a bit easier by being able to update calls before it is released.

This is unsound, it allows any value for the 'cs lifetime. This code should be rejected:
    interrupt::free(|cs| {
        let cs: &'static CriticalSection = cs;
    });

The sound way of writiing it would be this:

impl<F, R> InterruptFreeFn<CriticalSection, R> for F
where
    F: for<'cs> FnOnce(&'cs CriticalSection) -> R,
{
    #[inline]
    unsafe fn call(self) -> R {
        self(&CriticalSection::new())
    }
}

However this fails to correctly infer the closure type:
interrupt::free(|cs| {})

Interestingly, these work.
interrupt::free(|cs: &CriticalSection| {})
interrupt::free(|cs: &_| {})

Closure type inference through "wrapper" traits like these is known to be flaky, see this issue for example https://github.com/rust-lang/rust/issues/70263 .  I'm not sure if what you're trying to do is possible in today's stable Rust.

This is unsound

Thanks, good catch.

I'm not sure if what you're trying to do is possible in today's stable Rust.

Yeah, seems like it.

authors: Dirbaio reitermarkus

repo: rust-embedded/cortex-m


text:
bump svd v0.7, rm ref

bump svd-parser to v0.7, rm ref in match patterns without changing functionality

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Emilgardis (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see the contribution instructions for more information.

Thanks for the pr!
This is a duplicate of #256, if you did a pr to register-derived-from fixing merge conflicts I would be happy to approve that :)

authors: Emilgardis burrbull rust-highfive


text:
Newsletter 008: For The Quest

Part of #89
Covers For The Quest engine updates in March 2020

(cleaned up unrelated changes to avoid merge conflicts)

Merged, thanks for the PR!

authors: ozkriff seratonik


text:
no rules expected this token in macro call

Hello! I have this example code:
use error_chain::error_chain;

error_chain! {
    errors {
        ParseMail

        // An error appeared, when it tried to parse the body of the mail!
        ParseBody() {
            description("Couldn't get the body of the parsed mail."),
            display(""),
        }
    }
}

fn main() {
}

If I run cargo check then I'm getting the following error message:
error: no rules expected the token `=>`
  --> src/main.rs:3:1
   |
3  | / error_chain! {
4  | |     errors {
5  | |         ParseMail
6  | |
...  |
12 | |     }
13 | | }
   | |_^ no rules expected this token in macro call
   |
   = note: this error originates in the macro `impl_error_chain_kind` (in Nightly builds, run
with -Z macro-backtrace for more info)

What am I doing wrong?

I've also tried this as shown in the quickstart.rs:
#[macro_use]
extern crate error_chain;

error_chain! {
    errors {
        ParseMail

        ParseBody() {
            description("Couldn't get the body of the parsed mail."),
            display(""),
        }
    }
}

fn main() {
}

but I'm getting the same error message.

Ok, it was due to the empty brackets (()). Removing them like this:
error_chain! {
    errors {
        ParseMail

        // An error appeared, when it tried to parse the body of the mail!
        ParseBody {
            description("Couldn't get the body of the parsed mail."),
            display(""),
        }

        /// An error appeared, when it tried to parse/get an attachment!
        ParseAttachment

        ParseFetch

        ForgotHeader(missing_header: String) {
            description(
                concat![
                "Couldn't parse the mail to a sendable mail ",
                "because a header is missing."
            ]),
            display("Missing header: '{}'", missing_header),
        }
    }
}

works.

repo: rust-lang-nursery/error-chain


text:
bors-servo doesn't seem to be working anymore

eg https://github.com/rust-lang-nursery/rust-bindgen/pull/850#issuecomment-317905209

Seems not to have accepted the invite yet.

@larsbergstrom do you have to login as @bors-servo in order to accept the invitation?

such accept. many test. merge merge merge merge

Seems to still not be working: https://github.com/rust-lang-nursery/rust-bindgen/pull/855#issuecomment-318124297

https://github.com/rust-lang-nursery/rust-bindgen/pull/858#issuecomment-318214314

authors: KiChjang bors-servo fitzgen

repo: rust-lang-nursery/rust-bindgen


text:
web/clients/download/basic doesnt handle binary files

https://github.com/rust-lang-nursery/rust-cookbook/blob/master/src/web/clients/download/basic.md doesnt work if trying to download a binary file (such as an image). Might want to either point this out or modify the example to handle all data.
Doesn't work:
    use std::io::copy;
    // ...
    let content =  response.text().await?;
    copy(&mut content.as_bytes(), &mut dest)?;

Does work:
    use std::io::Write;
    // ...
    let content = response.bytes().await()?;
    dest.write_all(&content)?;

Looks good to me. Asking to @barrowsys to make a merge request. For the fame of being in the git commit log.

git is painful but its done

authors: barrowsys stappersg

repo: rust-lang-nursery/rust-cookbook


text:
Inappropriate handling of environment variable LD_LIBRARY_PATH in README.

I'm sorry, this is a very trivial thing.
README.md said

If you get an error like error while loading shared libraries while starting up rustfmt you should try the following:
On Linux:
export LD_LIBRARY_PATH=$(rustc --print sysroot)/lib:$LD_LIBRARY_PATH

In this case, if LD_LIBRARY_PATH is empty, the current directory will be included in LD_LIBRARY_PATH and causes potential security problems.
I think that it is good to do as following.
export LD_LIBRARY_PATH=$(rustc --print sysroot)/lib${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}

Thanks! I think we can totally remove this part from README as now rustfmt does not depend on libsyntax directly anymore.

Closed via #2974.

authors: taro-yamada topecongiro

repo: rust-lang-nursery/rustfmt


text:
Don't print config file by default

Supress Using rusftmt config file... messages unless the --verbose flag is given.
If a user has a config file, then every time rusftfmt runs it will print the Using rustfmt config file...
I think it is a good practice that if nothing has gone wrong, by default, nothing is printed. This will mean that users with config files will be more likely to notice actual error/warning messages.

Thank you!

You are most welcome ^__^

authors: casey nrc


text:
CI: move crater as test with allow failure

Refs: https://github.com/rust-lang-nursery/crater/issues/358
Signed-off-by: Otavio Salvador otavio@ossystems.com.br

It's probably better to test Crater without running the integration tests (just the unit tests): they require a full Crater environment, which means building and running Docker images.

It's probably better to test Crater without running the integration tests (just the unit tests): they require a full Crater environment, which means building and running Docker images.

In this case, it seems Crater is not a good option to test rustfmt. If @nrc agrees, I'd better remove it from integration test list.

What do you think @nrc? Should we remove it from integration test list?

The best thing to do would be to run with cargo build instead of cargo test, but I think that would mean writing a new integration test script. Failing that, just removing crater seems fine.

r? @nrc @topecongiro

You need to use cargo test --lib, not cargo test.

Thanks!

authors: nrc otavio pietroalbini


text:
Support wildcard version spec that matches any version

I have private crates in tree that carry various tests and depend on the parent crate.
I would like all the private (never published to crates.io) crates to be able to use parent = { version = "*", path = ".." }.
This works fine, until the parent crate uses a prerelease version for any duration of time, then the wildcards suddenly don't match. This is very inconvenient.

cc @steveklabnik, do you know if there's any standard semver tool for this?

@bluss won't parent = { path = ".." } work for you? That is, just omitting the version key?

@matklad Indeed, that's great, it seems to work just like it was needed.

authors: alexcrichton bluss matklad

repo: rust-lang/cargo


text:
Functionality to glob all crates in workspace

We added glob support originally with #3911
However, if we add to Cargo.toml
[workspace]
members = ["**/*"]

Then we get an error like this.
error: failed to read `/Users/nipunn/src/client/rust/.cargo/Cargo.toml`

Here, the */ matches over aggressively to directories/files that aren't Crates. It would be nice to have a way to glob all crates. For now, we have to autogenerate the workspace Cargo.toml with a script.

Good point, @nipunn1313! I'm working on workspace.members and workspace.exclude right now (https://github.com/rust-lang/cargo/issues/4089) and this is another issue we need to fix.
Labels: A-workspace, C-bug

Some possible ways I brainstormed

Limit glob matches directories with Cargo.toml
Have a special way to specify members which automatically matches everything (rather than glob)
Eliminate members from root manifest and assume all crates with Cargo.toml are eligible
Force users to list all crates in the root manifest (redundant to the Cargo.toml)

It does feel like the members array in a virtual manifest at the root of a workspace is somewhat redundant to the directory structure. Adding a crate to a workspace involves writing a new Cargo.toml + adding that directory to a members list. We want to avoid this redundancy.
What is the supported workflow which would require anything more nuanced than a full glob?

Oh, for simple cases, you can just leave out workspace.members and all packages under the workspace root dir will be included automatically.
BUT, that method has a limit that if you want to add a member from a non-children directory, then you also have to add all the children packages to the list. Supporting **/* glob (or just * for the gitignore-like interpretation), we can resolve this issue.
At the moment, though, looks like the behavior is kind of expected: If you're setting workspace.members config, then it includes paths matching packages, and it's (almost) an error otherwise.
I think we need a bit more brainstorming on what workspace.members is expected to mean in general before we can answer this issue specifically.

For most cases (including ours), the members of a workspace are all under the workspace root, so simply leaving out workspace.members works fine as @behnam suggested, so the main concern I had is taken care of.
Question is still open as to whether we want better support for **/* in workspace.members, but it does not seem to me high priority to cover the case of globbing items outside of workspace child directories.

[This is yet resolved]
I am going to close this. Further discussion could happen in #11405. If you think this is wrong please leave a comment. We could reopen it.

authors: behnam nipunn1313 weihanglo


text:
fix(toml): Provide a way to show unused manifest keys for dependencies

Dependencies have not been able to show unused manifest keys for some time, this problem partially resulted in #11329.
This problem is caused by having an enum when deserializing.  To get around this you can use:
#[serde(flatten)]
other: BTreeMap<String, toml::Value>,

This collects any unused keys into other that can later be used to show warnings. This idea was suggested in a thread I cannot find but is mentioned in serde#941.

I'm a bit confused as to the full details of the situation. Some of these ignored messages work on stable or nightly, and I'd like to dig into the details of what is going on.
Starting with #11565, none of the ignored messages seem to be working. Can you explain why serde_ignored isn't handling them starting with that PR, but was working before? Which situations worked and which ones didn't? Is there something about untagged enums that doesn't work? Would it be possible to have a custom deserialize impl that avoids needing special handling here?

Before #11565, the two tests added in this PR pass with only minor changes (location of a few messages). I believe this is due to IntermediateDependency. IntermediateDependency made it so anything that wasn't defined within it would throw an unused manifest key warning. This is expected behavior, but it wouldn't throw those warnings if what it would be turned into didn't have one of those fields. This is ultimately the root cause of #11329.

Test showing it misses `git` when using workspace inheritance
#[cargo_test]
fn warn_inherit_unused_manifest() {
    Package::new("dep", "0.1.0").publish();

    let p = project()
        .file(
            "Cargo.toml",
            r#"
            [workspace]
            members = []
            [workspace.dependencies]
            dep = { version = "0.1", wxz = "wxz" }
            [package]
            name = "bar"
            version = "0.2.0"
            authors = []
            [dependencies]
            dep = { workspace = true, git = "wxz" }
        "#,
        )
        .file("src/main.rs", "fn main() {}")
        .build();

    p.cargo("check")
        .with_stderr(
            "\
[WARNING] [CWD]/Cargo.toml: unused manifest key: workspace.dependencies.dep.wxz
[WARNING] [CWD]/Cargo.toml: unused manifest key: dependencies.dep.git
[UPDATING] `[..]` index
[DOWNLOADING] crates ...
[DOWNLOADED] dep v0.1.0 ([..])
[CHECKING] [..]
[CHECKING] bar v0.2.0 ([CWD])
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]
",
        )
        .run();
}

#11565 mostly addresses #11523 by making it so TomlDependency is just a normal TomlDependency and TomlWorkspaceDependency is opt-in. The other thing #11565 does is make things easier to read and understand, making things more unified and easier to split out in the future. The end goal with work similar to #11565 is to make toml/mod.rs easier to understand and make changes to.
As for why #11565 caused this regression/why IntermediateDependency partially worked, it is due to how serde_ignored works. Fields inside of an untagged enum are known to have problems with serde_ignored since serde must try to deserialize it into all possible formats. Since it must try all formats, things that should throw an unused manifest key warning don't.
This PR tries to fix that by using #[serde(other)], which can collect everything that would be "unused". We can then output those later. I am unsure if a custom deserialize impl would solve this issue. I would have to dig much deeper into that area to know if it is a viable solution compared to what I have already come up with.

Hm, that's unfortunate. It seems like this affects everything that uses MaybeWorkspace. Would it be possible to fix that, too?
I'd be reluctant to add a bunch of manual checks for ignored fields. Would it be possible to add custom deserializers for the different MaybeWorkspace kinds?  For example, the string kinds can be something like:
type MaybeString = MaybeWorkspace<String, TomlWorkspaceField>;

impl<'de> de::Deserialize<'de> for MaybeString {
    fn deserialize<D>(d: D) -> Result<Self, D::Error>
    where
        D: de::Deserializer<'de>,
    {
        struct Visitor;

        impl<'de> de::Visitor<'de> for Visitor {
            type Value = MaybeString;

            fn expecting(&self, f: &mut std::fmt::Formatter<'_>) -> Result<(), std::fmt::Error> {
                f.write_str("a string or workspace")
            }

            fn visit_string<E>(self, value: String) -> Result<Self::Value, E>
            where
                E: de::Error,
            {
                Ok(MaybeString::Defined(value))
            }

            fn visit_str<E>(self, value: &str) -> Result<Self::Value, E>
            where
                E: de::Error,
            {
                Ok(MaybeString::Defined(value.to_string()))
            }

            fn visit_map<V>(self, map: V) -> Result<Self::Value, V::Error>
            where
                V: de::MapAccess<'de>,
            {
                let mvd = de::value::MapAccessDeserializer::new(map);
                TomlWorkspaceField::deserialize(mvd).map(MaybeWorkspace::Workspace)
            }
        }

        d.deserialize_any(Visitor)
    }
}

Then serde_ignored should work for those kinds of fields.
(I just hacked that together, it may need some work.)
The only things that will have problems are those that are maps. From what I can tell, that is just dependencies and badges. Badges might be a little complicated since they will likely need an other field, too, so they couldn't reuse TomlWorkspaceField.
That may result in more total lines of code, so I'm not 100% sure it is worth it, but it might help ensure that any fields added in the future don't forget to manually check for unused keys.

@Muscraft Just checking if you had any questions here. I'm a little concerned about the regression in diagnostics in 1.69. If a more general solution for the inherited definitions looks to be a lot of work, I'd be happy to move forward with a fix for the primary issue of ignored fields in dependency declarations, and address other cases in future PRs.

I have to rebase onto master it looks like. The changes between my first commit and the one I force pushed are here

This looks great, thanks!
We discussed the unfortunate increase in lines of code here with all the serde impls. @Muscraft indicated interest in organizing things into more submodules, which sounds great to me, but they will follow up on that later.
@bors r+

:pushpin: Commit a32af2fff1cb48317408cab94f5fc3e9bff4038b has been approved by ehuss
It is now in the queue for this repository.

:hourglass: Testing commit a32af2fff1cb48317408cab94f5fc3e9bff4038b with merge 0942fc72d684026064722a28c822f83f75f61504...

:sunny: Test successful - checks-actions
Approved by: ehuss
Pushing 0942fc72d684026064722a28c822f83f75f61504 to master...

Nominated beta backport to 1.69.

authors: Muscraft bors ehuss weihanglo


text:
Add test for whitespace behavior in env flags.

This is a regression test to ensure that RUSTFLAGS/RUSTDOCFLAGS are split on just the space (0x20) character, and not any other whitespace. Requested at https://github.com/rust-lang/rust/pull/75539/files#r470923329

r? @alexcrichton
(rust_highfive has picked a reviewer for you, use r? to override)

@bors: r+

:pushpin: Commit 157ed9f79a55212ac9c39b0c3aa3534c6411b45e has been approved by alexcrichton

:hourglass: Testing commit 157ed9f79a55212ac9c39b0c3aa3534c6411b45e with merge e4b65bdc80f2a293447f2f6a808fa7c84bf9a357...

:sunny: Test successful - checks-actions
Approved by: alexcrichton
Pushing e4b65bdc80f2a293447f2f6a808fa7c84bf9a357 to master...

authors: alexcrichton bors ehuss rust-highfive


text:
delete crates from database if they're deleted from crates.io

There have been a couple incidents recently where hundreds of crates were procedurally published to squat their names, and crates.io decided to delete the squatted crates after the spam attack was stopped. However, their records still exist on docs.rs, which may cause issues later on if someone else tries to register the same crate and publish the same version number. We should track crate deletions from the crates.io index and scrub the crate from our database when that happens.
This will likely need work in the crates-index-diff crate, since IIRC it doesn't currently check for crate deletions, just new publishes and yanks.

Closing as duplicate of https://github.com/rust-lang/docs.rs/issues/368

license: MIT


text:
(draft) set default target to linux for tests so we can run the tests on non-linux machines

I found out that df489659d0de9baa5f23896dbc9260a00206f633 broke the tests in web/rustdoc for me, since it changes from a hard-coded linux default-target to using docsrs_metadata::HOST_TARGET, which is x86_64-apple-darwin on my machine.
I cannot run the whole test-suite anyway on my mac, and was fine until now only running the subset I changed. So for starters I only created this PR to let github run CI.
I'm not sure yet if this is the better solution, or adapting the tests to use the same HOST_TARGET constant for their assertions. Or overriding docsrs_metadata::HOST_TARGET using an environment variable and adding that to .env.sample.

I think the "default target" should be specified in Config, probably loading from an environment-variable and defaulting to HOST_TARGET if unspecified, then the tests would be able to override that to always be x86_64-linux-unknown-gnu in the TestEnvironment.

I think the "default target" should be specified in Config, probably loading from an environment-variable and defaulting to HOST_TARGET if unspecified, then the tests would be able to override that to always be x86_64-linux-unknown-gnu in the TestEnvironment.


text:
os: Fix race condition of atomics

Fixes an issue described in rust-lang/rust#21538.

r? @alexcrichton
(rust_highfive has picked a reviewer for you, use r? to override)

(see also rust-lang/rust#24526 for std::rand::os fix)

Thanks!

authors: alexcrichton klutzy rust-highfive

repo: rust-lang/rand

license_source: bigquery


text:
Updates package version in docs

Hi,
Thanks for your hard work on this library ! :smiley:
Just updated the version number in the docs.
Best regards,
Conrad

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @huonw (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see the contribution instructions for more information.

Thanks!

repo: rust-lang/regex


text:
min_by requires Ord not PartialOrd

 Issue by neunenak
Tuesday Sep 30, 2014 at 06:15 GMT
For earlier discussion, see https://github.com/rust-lang/rust/issues/17648
This issue was labelled with: A-iterators, A-libs, B-RFC in the Rust repository

It would be handy if Iterator::min_by required PartialOrd instead of Ord. This requirement makes it impossible to use with among other common types f32 and f64, which is annoying. I don't know if the best solution is to simply change the required trait to PartialOrd or to provide some other method min_by_partial_ord or something along those lines. The same reasoning should apply to Iterator::max_by

Possible revisions to max_by and min_by that would make this problem go away are being discussed in rust-lang/rust/issues#15311. Summary: "scoring" functions like the one expected by max_by have disadvantages; expecting a function that does the comparison and returns a bool or Ordering might work better.

I believe this is non-actionable now; and there's https://doc.rust-lang.org/nightly/std/iter/trait.Iterator.html#method.min_by which doesn't require any T: Ord.

authors: Centril jimblandy steveklabnik

repo: rust-lang/rfcs


text:
RFC: Rename Iterator::size_hint to Iterator::len_hint

This change is originally brought up in this discuss thread.
Rendered View

There was some issue with #1032 that new commits were not showing up there. Thus here is a new PR. Sorry for the confusion.
This PR promotes the "rename size_hint during the 1.0 beta cycle" alternative to be the main candidate.
cc @Gankro.

:+1: Seems more consistent to me.

Still :+1:

I'm on board with this; would've been nice to land before beta, but it slipped through the cracks.
We can carry out a deprecation + removal process before 1.0, to make this not-too-painful.

rfc: rename len() to size()
:(

@ben0x539, I could not find the relevent discussions, but vaguely remember that one of the reasons for preferring len is that size can mean the size of a value, not the number of elements in a container. In a "low level" language like Rust, sizes of values are important, and the semantics of size_of and len is not the same.
C++ reuses the name size for different things, and Rust can do some improvements here. Of course whether len is an improvement is a bit subjective, considering that non-linear collections don't technically have lengths. But then again, there is Python. ;)

Yeah size vs len was debated plenty several months ago. It's not an important bikeshed. All that matters is that we're consistent.
votes for num

It seems that I am in the minority here but...

The beta and stable releases, on the other hand, will only include features and APIs deemed stable, which represents a commitment to avoid breaking code that uses those features or APIs.

Beta is out, please don't make any more changes unless there have been critical issues discovered. I believe that it was stated that the bar to make a breaking change once beta lands was high. A naming bike shed is not that.

I agree with @carllerche . We're going to have to start being okay with Rust having little warts like this.

:+1:
Rust will eventually have to live with some regret... But this is simple enough, let's not let it be one of them.

I agree with @carllerche as well. We should stick to our guns on stability unless we have an extremely good reason.

@carllerche @steveklabnik @wycats, would deprecating size_hint (the first alternative) be acceptable? (Note: per #1030, deprecations may happen "soon", anyway.)

As @aturon mentioned, this was an oversight. It should be fixed, together with whatever else gets noticed between now and 1.0. It's after 1.0 that we dare not break anything "unless we have an extremely good reason" (as @wycats says). Let''s live with "warts like this" (as @steveklabnik says) if only they are noticed after 1.0.

I think the extra API bloat to keep around size_hint() would be confusing from my previous experience using libraries such as QT and PEG (Portable Embedded Graphics). In both of these libraries objects representing rectangles on the screen all have a size_hint() method which I always end up needing to look up to see what it does. In both of these libraries the size_hint() method refers to how many pixels the rectangles on the screen should be as a suggestion.
The semantics are clearly different than here, I think using size_hint() for a collection is confusing given my experience with these C++ libraries. +1 to renaming size_hint() to len_hint().

I agree with @carllerche — this is really minor. I'm OK with living with this small issue forever.

(This is a slightly modified version of my reply to @pcwalton here.)
"This is really minor" can go both ways:

This is really minor, so no need to fix this.
This is really minor, so why not fix this?

So we may agree to disagree. :)
Also, according to semver,  1.0.0-beta -> 1.0.0 (using the correct semver format here) is a special case where it is okay to have a small amount of breaking changes.
From the semver specification:

5. Version 1.0.0 defines the public API. ...
9. ... Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. ...

I'm in for the change. Sacrifices will have to be made either with breaking changes or regret...
I vote to break things, at least until 1.0 is out.
I posted the same for the auto deriving traits.

I support this. Sure, it's minor, and there's eventually going to be a few warts like this one, but I don't see any reason not to fix this one while we still can. Let's try not to ship a version 1.0 which already has warts.

The last release before 1.0 stable is a dry run for stability. It should be used to let all the changes (including last minute changes) that happened in the previous cycle to bake so that any emergency issues that are discovered can be fixed before 1.0.
If aesthetic / bike shedding level changes wish to be made, then there should be another pre 1.0 release that happens after the beta, perhaps a release candidate, to allow changes a chance to sit for a while and for users to actually use them.

@carllerche indeed, and not just 1.0 beta but every beta after that too. Beta releases only include features that have gone through a fairly rigorous process and have been enabled because they're ready to go. The beta release is one last chance to find bugs before committing to semver, and changes have a high bar to clear.
In general, if a problem is found in a feature that justifies a change, it means it wasn't actually stable enough to justify unflagging it, and it should be moved back to nightlies so the change can be made through the full process. If people don't think it's worth doing that, the reason isn't big enough to justify a late-breaking change.

Reading the arguments from others is pushing me towards the "meh, just leave it" camp. As @alexcrichton put it last night, we have a certain budget for "optional" breaking changes. I don't really think I would want to spend it here!

If anything it should probably be count_hint since an iterator doesn't really have a len per se. But I tend to agree that this ship has sailed, and speaking as a user I'd just like to move forward and start building things in rust.
To take a different approach, how about a retroactive justification for leaving it as is? The purpose of this method is to estimate the amount of data that can be retrieved from it, presumably from some underlying collection. This collection could be anything though, and might not necessarily have the linear notion of a len. It could be tree nodes, a file, a procedurally generated sequence, or anything really. I think '`size' is an appropriately general term to reflect the abstract nature of the data source. "size" also conjures notions of reserving space, which is likely the primary use for this method.
For my part, this handwavy justification is enough to satisfy me that it's fine left as is.

@wycats,

In general, if a problem is found in a feature that justifies a change, it means it wasn't actually stable enough to justify unflagging it ...

In general, yes. However, this particular change is basically because an oversight. I believe the content of the change is not controversial, only the timing is.
@carllerche, I won't mind another beta actually. (In general I believe pre-1.0.0 is where a bit special casing can apply.)
@nikomatsakis, if there is a "budget", then a small change like this won't occupy much of it. (Also, we may wait and see, if not "many" other optional breaking changes happen during the cycle, then this change can utilize the budget.)
@jpernst, len is uniformly used across Rust's standard collections, even the non-linear ones, to mean "numbers of elements". While size means "sizes of values". And size_hint is not consistent with the convention. The doc even directly says that size_hint returns a length.

Oops it was easy to accidentally hit the close button on mobile.
The flip side of the "budget" argument is, as this change itself is small, some may believe it is not worth landing if this is the only breaking change, but I'd argue that in that case, this change can totally "piggyback" on other breaking changes. (We are having breaking changes anyway, why not add this small one?)

To be clear, I'm not against this change in theory, as I'm sure most users aren't. I think the primary concern at play here is what stability really means, and how representative of the release API will betas be in general.
In projects of any significant size, there will always be just that one more thing that could be tweaked or improved. While it was fun for a while to keep up with the bleeding edge and ride the wave of nightlies, I'm weary of that and am ready to settle into stability. I'm personally very happy with rust as a language right now, and would be disappointed to see minutia push it into another round of beta. I'm eager to start using it in production, but that's a no-go while it remains pre-release. I have colleagues who are interested in it but are waiting for the "all clear" signal that it's safe to use.
I don't mind whichever way this particular change goes, but as an avid proponent of rust, I'm very much interested to see where the line gets drawn.

A @CloudiDust , since there are going to be breaking changes before 1.0 (e.g. 97f24a85965c3c51a2c18be029091ae52bbd7920), this change could just piggy-back on it. It's also special since it was an oversight, as well as minor.

rust-lang/rust/97f24a85965c3c51a2c18be029091ae52bbd7920

@jpernst, your concern is very valid.
According to semver, absolute backwards compatibility guarantee only starts at 1.0.0 (the first stable release), every release before that can have breaking changes, and every 1.x.y release after that should not contain any breaking changes (barring bugs).
This "no breaking changes" guarantee extends to all post-1.0.0 betas because, eh, they are post-1.0.0.
But this guarantee doesn't (have to) apply now. So 1.0.0 is that "clear signal".
Of course, breaking changes between 1.0.0-beta and 1.0.0 would be minor, if any.

I think we can help settle this issue with data. @brson has been working on a tool to automatically test new versions of the compiler against stable crates on crates.io, yes? Test the impact of this change with that tool and see how much breakage would result.

@bstrie, good idea!
I don't expect size_hint to be frequently used. (And when it is used, the fix is easy and quick.)
Actually Rust is the first language I am aware of that has size_hint on its iterator "interface". I am quite surprised when I see it in the docs.
Nitpick: I don't think there are any stable crates on crates.io now. ;)

As the maintainer of a non-trivial amount of the crates that will actually break from this change (collections) I'm more than happy to endure this.

@Gankro, I am curious, what is the main use case of size_hint? Is it for efficiently supporting the the lazy, functional transformations of collections and iterators?
In everyday codes, I almost always want to go through the entire yielded sequence. If I need a length, I'll just count and get an exact length value. An estimated length don't seem too useful to me.

@CloudiDust Primary usecase is reserving space when e.g. collecting into something. Not something I'd expect application code or quick-n-dirty iterator impls to fiddle with.

@bstrie Something to keep in mind, private production code & OSS crates will have different patterns. I know for a fact that there already is private Rust code in production that would break with this change.

@carllerche I trust that the proportion of private code that will break from this change will be indicative of the proportion of OSS code that will break. My comment is not intended to be in favor of this change nor against it. More data will not cause us to make a worse decision.
In any case, future changes to the language that toe the line of "backwards compatibility" (such as changes to type inference) will be judged using this process. If the closed-source Rust community is disserved by it, now is the time to determine that and take steps to remedy it (e.g. by creating a program whereby Rust-using companies can sign up to test new versions of the compiler themselves, or allowing them to upload their code to private repositories where we may run new versions of the compiler against their code at our whim).

Here is one thing missing from the RFC:
There is a std::iter::ExactSizeIterator trait which represents "an iterator that knows its exact length", and has a single method named len.
It is clear that this trait's name is inconsistent with its method name.
So, to truly achieve consistency, two renamings are needed:

size_hint -> len_hint;
ExactSizeIterator -> ExactLengthIterator.

I am not so sure if I should push for these two renamings, or simply accept the special case that for iterators, size and len are used interchangeably? (Actually the rule seems to be len = exact_size, which can, in a way, explain why it is size_hint, not len_hint. Is this interpretation convencing enough?)

Nice catch there @CloudiDust.

ExactSizeIterator is kind-of a really stupid type. It's pretty much exclusively used to auto-impl DoubleEndedIterator for certain iterator adaptors (unless someone's found another use? It certainly doesn't address trusted iterator len).
As such I'd only expect the rename to affect Iterator implementors. Even less than the amount that touch size_hint.

@tshepang @CloudiDust
We haven't made any breaking changes to stable APIs since the beta (the cited change was to an unstable API). Granted, it's only been a few days, and more warts are sure to surface. But I think the bar for a breaking change should be very high at this point; we need to commit to stability.
Note that this change is only breaking if size_hint is removed, not just deprecated. That is, we can:

add a len_hint method, defaulted to use size_hint's implementation,
deprecate size_hint.

I know it doesn't feel great to ship with deprecated APIs, but:

We should consider having rustdoc not show such APIs by default. The resulting default docs would look like the design we want.
The maintenance burden here is nil.
Deprecation limits the amount of code in the wild using an API; the sooner you do it, the less lock-in there is.

We have a great deprecation system, and I think we shouldn't be afraid to use it to make targeted cleanups without breakage. We get most of the benefit at little cost.
(Final note: we do plan a sweep to remove deprecated items prior to 1.0, but presumably that would be limited to pre-beta deprecations.)

@aturon I wasn't careful anough to check if the API was stable. Sorry for the noise, and thanks.

@aturon to be clear, If something major requires a Beta breaking-change, are you saying smaller changes (like this one) won't be allowed in... piggybacking?

@tshepang

@aturon to be clear, If something major requires a Beta breaking-change, are you saying smaller changes (like this one) won't be allowed in... piggybacking?

I'm not sure; there's not a clear policy at the moment, since this is such a unique situation.
But as I said in my earlier comment, I think it's a perfectly fine option to do a deprecation and introduce the new name, and leave it at that -- no breaking changes, but improved naming for newcomers.

Good to know, thanks.

Thanks everyone. I have updated the RFC. The "deprecate but retain" alternative is promoted, and ExactSizeIterator -> ExactLengthIterator is added.
@Gankro thanks for the explanations. I think it is a good idea to mention the intended use cases of len_hint and ExactLengthIterator in the docs.

In the current state the RFC is a win-win.

Let's get this out of the way. The current state of the RFC looks good enough.

Sorry for the delay! I will make sure this gets attention for a decision on the core team ASAP.

@aturon, excuse me but will this be accepted?

I'm hoping it will.

@CloudiDust ah thanks for the ping, it appears this has fallen by the wayside! @aturon and I discussed this awhile back and our thoughts on this basically boiled down to how the standard library deals with deprecated code. We would like to take a path of aggressively deprecating existing APIs if necessary (for cases like this), but taking this route has a number of downsides which haven't been fully thought through just yet. In short, I believe everyone's in favor of this RFC, but we do not have precedent yet for dealing with large-scale deprecations such as this. As a result there's been some hesitation while the ramifications of such a decision are explored.
With the recent change to Rust's governance, as well, this RFC will soon come under the purview of the libraries subteam, and we're still in the process of bootstrapping the subteams and getting then under way. This should happen within the coming weeks, however, and this will surely be one of the first RFCs under discussion by the subteam!
Sorry again for the delay, but thanks for your patience.

Note: this PR is in its Final Comment Period (as of yesterday).

Since we've released 1.0, I do not think it's sound to change this any more. size_hint is not the end of world. I prefer size_hint to len_hint, because the former is human-readable.

I'm still in favor... consistency is great, and nothing should be broken by the change.

This PR hasn't gotten a lot of comments in the past week, and I personally still had a number of concerns about the policy on deprecating APIs in the standard library. I would like to propose that we renew the FCP for this RFC (for one more week) to ensure that we're all comfortable with the precedent that this RFC is setting (deprecating APIs in the standard library).
I've written up a thread on internals about this topic, and I'd encourage discussion about the policy to deprecating APIs in the standard library to happen there instead of here (as this is focused on size_hint).
cc @rust-lang/libs

How does this look on the implementor side?
How do we enforce that len_hint and size_hint are in sync?
I fear some iterators implement size_hint and delegate to size_hint and some only len_hint and delegate to len_hint. It will be a mix. I understand size_hints aren't very well “appreciated” right now and mostly don't get much attention when you implement iterators — they are optional after all, but they are kind of important for allocations, that the reason we have them.

Oh that's a good point, I believe the implementation would be for size_hint to delegate to the defaulted len_hint function, but this means that iterators only implementing size_hint will have the wrong return value when they have len_hint called on them. This will not be the case, however, for any standard iterator (which is where I believe most perf-sensitive iteration happens).
On the other hand it means that all crates which want to remain compatible with 1.0 (and hence can't define len_hint) will have sub-par performance going forward (or have to give up 1.0 compat). This does seems like a legitimate drawback to mention (cc @CloudiDust)

Given the point raised by @bluss (and elaborated on by @alexcrichton), the fact that 1.0 is out, and that this is a minor "esthetic" change, it just doesn't seem worth it...

Oh that's a good point, I believe the implementation would be for size_hint to delegate to the defaulted len_hint function, but this means that iterators only implementing size_hint will have the wrong return value when they have len_hint called on them.

Hmm. So if I write an iterator under Rust 1.0, and somebody calls that iterator under Rust 1.2 (using non-deprecated methods), then len_hint will return an incorrect value? Personally, that seems like a much more unfortunate consequence than an inconsistent name. The damage is slightly ameliorated by the fact that an iterator with a broken len_hint is merely potentially very slow, but at least it still returns correct output. Still, it feels like we'd be trading a small wart for a medium wart here.

I am currently working on an RFC to make iterators more optimizable in unsafe code that would introduce "trusted_len" and "TrustedLen". I could call them trusted_size, but I'd rather not let this mistake bleed out.

Indeed that's a valid point, but it'll still give correct output.
That's 1.0 (the first stable release ever...) only though, it don't see why it should be a big factor on this decision.

@alexcrichton Just a question, if this was added is there a reason to not make len_hint delegate to size_hint by default? That way any crate wanting to stay backwards compatible can define just size_hint and keep performance on all versions.
Also, any crate which actually provides len_hint will be locked in to 1.2+ rust versions, so users of the function have no reason to use size_hint as the dependency iterator will already be incompatible with earlier rust versions.

I think you'd need a rustc method renaming feature to do this properly in fact. We need methods len_hint and size_hint to refer to the same method.

@daboross

Just a question, if this was added is there a reason to not make len_hint delegate to size_hint by default?

I think the problem unfortunately exists both ways. I outlined a problem where size_hint delegates to len_hint where defining an iterator is now difficult to do at 1.0 in the "fastest way possible" as new code using len_hint will not be using your implemented size_hint function, and you can't implement len_hint if you're locked to 1.0.
Conversely, if len_hint delegated to size_hint it would be difficult to consume an iterator. At 1.0 I could only call the size_hint method on a given iterator, but all new iterators would define len_hint instead of size_hint, so I wouldn't be getting the latest-and-greatest size hints from iterators I take from an API.
Deciding the direction of delegation affects what part of an API suffers, but I think regardless of what we choose it's impossible to have everyone on all versions of Rust using the same size hints.

@alexcrichton One point on that - if you are using any iterators which define len_hint instead of size_hint, aren't you already constrained to Rust 1.2+? I mean it seems like you would have no reason to use size_hint if you've already broken compatibility with 1.0/1.1.

If I'm a Rust 1.0 crate that wants to consume an iterator, I can only call size_hint, not the len_hint function. If len_hint delegates to size_hint, then new Rust 1.1+ iterators which only define len_hint (and hence size_hint returns the normal default) will be "slower" when used with my crate as my crate wouldn't be picking up the most accurate size hints.
Sure, though, if a crate actually calls len_hint then this is moot.

I think @bluss's suggestion of adding method renaming/aliasing ( https://github.com/rust-lang/rfcs/pull/1034#issuecomment-107871861) seems like a good way to solve this (and future cases). It's something we support with everything(?) except trait methods, since we can pub use other things to rename them. However, I'm not sure adding a new language feature is worth solving just this case, and it's not clearly to me how many others there will be.

Actually yeah having "function re-exports" would be a pretty sweet thing to have for a few problems. I imagine we'll stumble into more "weird name" problems and having this as just a "ok. problem solved" would be pretty sweet. No forward/back-compat struggles, and everyone gets the best name.
(someone should make an RFC for that...)

I tend to really dislike naming inconsistencies, so I was leaning towards being in favor of this change (despite the downsides of deprecation). However, the very subtle issues surrounding the conflict between size_hint and len_hint when both are present push me towards the other direction: the naming inconsistency is unfortunate, but the effects of deprecation are worse. I'd rather live with an unfortunate naming inconsistency than subtle effects on performance.
If there were some hypothetical mechanism to do renaming without incurring that cost, then I think I'd be in favor of this change.

Yes, at this point I think this should be closed/post-poned in favour of a more general renaming scheme like #[deprecated(renamed_to="new_name")] or fn foo = bar.

@Gankro Yes I agree, at that point it would be relatively simple to do.
I'm envisioning a renaming feature that makes sure users can't define both the old and the new name at the same time.

The consensus of the libs subteam is now that this RFC should not be merged at this time. @bluss's observation that this will lead to a performance degredation for crates tied to 1.0 is enough motivation to not push on this RFC at this time. Due to no mechanism being able to deprecate these methods in a truly zero-cost manner, I'm going to close this RFC at this time.
Thanks regardless for the RFC @CloudiDust! We definitely think it's possible to have a nice way to rename functions in the future (e.g. https://github.com/rust-lang/rfcs/pull/1150) which should allow changes like this to be made.

authors: BurntSushi CloudiDust Gankro alexcrichton arthurprs aturon ben0x539 bjadamson bluss bstrie carllerche daboross emk huonw jpernst liigo nikomatsakis nstoddard pcwalton steveklabnik tshepang wycats


text:
Match angle brackets syntactically

Remove the angle bracket blinking feature, and make it actually match < and > characters as parens in the syntax table instead.  This matching is suppressed as needed, so that less-than and greater-than operators, arrow operators, etc don't throw off the matches.
This has the following effects:

Angle brackets match like other braces/parens however they are configured, rather than blinking in a different way.
Movement commands like forward-sexp and backward-up-list acknowledge angle brackets.
electric-pair-mode works with angle brackets (also suppressed when needed.)
Fix #50 - angle brackets are matched in the right pairs; -> and other non-angle-bracket < and > characters do not attempt to match.
Fix #10 - multi-line lists inside angle brackets are indented like other lists.

Macros have arbitrary syntax and therefore it's not possible to know whether a < or > character is an angle bracket or not.  So the matching is always suppressed inside macro definitions and uses.
There are a few disadvantages: besides the fact that the code is rather hairy, it also has to detect the non-angle-brackets perfectly, or else it throws off the indentation for the whole rest of the file.  For that reason there is still a custom variable available to disable it (though with a different name than the previous one.)
Having said that, I don't know of any cases where it gets it wrong.  I tested it with this program, which compares what emacs thinks are the non-bracket </> characters with what the rust compiler thinks.  It passed for all of the rust compiler code base, as well as all the rust code in servo and as many of servo's dependencies as still compile with the latest nightly.
Also included are some bug fixes for some edge case issues in the handling of raw strings and character literals.  I found these while running the test script.  Even if the angle bracket matching itself is deemed to be too risky or hairy to be merged (and I would understand it if that turns out to be the case), you may want to merge the other commits for the bug fixes.  I've put them first to make this easy.
If this PR is accepted, close #66 (because the variable that it renames has been removed entirely) and close #74 (because post-self-insert-hook is no longer used at all.)  Both of these pertain to the old angle bracket blinking code that this PR removes entirely.
And if the PR is not accepted - hey, I still had fun writing it.

r? @pnkfelix
(rust_highfive has picked a reviewer for you, use r? to override)

I think I do want to accept this.  At the very least, I've noticed that the current bracket-blinking code totally messes up multiple-cursors mode.
cc @nikomatsakis any thoughts here?

Thanks @pnkfelix.
I just rebased after the latest other commits to master.  (Nothing else was changed.)

I have no objections -- it sounds strictly better than the hack I did. I don't quite understand how it works (but I haven't tried reading it).

authors: MicahChalmer nikomatsakis pnkfelix rust-highfive

repo: rust-lang/rust-mode


text:
Improve Windows .ico resolution.

The low resolution installer icon has bothered me for far too long, replaced with 256x256 version. :)

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @brson (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see the contribution instructions for more information.

Thanks!

authors: Eljay brson rust-highfive

repo: rust-lang/rust-packaging


text:
track configs set from cli flags

resolves #6252
There's more detail in that linked issue, but rustfmt internally needs to know whether the user explicitly specified a configuration value via a top level cli flag, e.g. --edition or --style-edition. This PR adds a separate boolean flag on configuration options that indicates whether the user specified it via a top level cli flag.
Notably, this intentionally does not make any changes to the config.set().* calls, nor the config.was_set().* behavior. That's because I'm unclear on the historical reasons why those ignored the CLI flag method, at this time I'm unclear on the potential side effects of changing that behavior, and we don't need to resolve nor risk any of that for the purposes of the 2024 work (i left an inline FIXME to revisit)

As a thought for future cleanup on this, I think perhaps we can expand the programmatic config setting logic to take an argument indicating whether it's a user supplied value or a rustfmt internal override like one of these:
https://github.com/rust-lang/rustfmt/blob/e21c1e220bdc6748e33b67e00394dd23c46a1a3d/src/comment.rs#L760
And then the config setter logic can use that to determine whether or not to flip the flag

repo: rust-lang/rustfmt


text:
rustbot says to "Please let @rust-lang/release know" but doesn't say how

I found a regression from stable to nightly.  I filed it.  I tried to set the regresson-from-stable-to-nightly tag, but the bot wouldn't let me.  I hoped someone else would do so.
Instead, time passed.  Now it is a regression from stable to beta.  @rustbot still says:

Please let @rust-lang/release know if you're having trouble with this bot.

How should I let @rust-lang/release know?  I ended up reading the triagebot wiki and found the ping command, but rustbot won't let me do that either.
IMO when it says "please let @rust-lang/release know" it ought to say how to contact that team.
FTR, the issue in rustc is https://github.com/rust-lang/rust/issues/96956

fair point.
I think the suggestion is meant to have the user type what is suggested (example @rustbot ping release). However, by reading the triagebot wiki, I think this behaviour needs to be enabled by editing the triagebot.toml and add something such as:
[ping.release]
message = "Hi release team, pls help..."

Not sure 100%, though, my understanding might be off.
Having said that, usually these automated comments are picked and handled up by someone with enough permissions.

We should probably replace the text with either an issue on this repo or a ping in #t-infra on Zulip.

or maybe both!  (note: Zulip ping requires an account, which not everyone might have)

Closing as fixed - we now point to this repo and #t-infra on Zulip.

authors: Mark-Simulacrum apiraino ijackson

repo: rust-lang/triagebot


text:
Soundness issue with base::Error

Hi there, we (Rust group @sslab-gatech) are scanning crates on crates.io for potential soundness bugs. We noticed that xcb exports the xcb::base::Error struct publicly:
https://github.com/rtbo/rust-xcb/blob/b44e52845e21621613d57bf5eb47c48c2ad521dd/src/base.rs#L130-L158
Since the struct and its fields are public, it can be created from safe Rust code which can potentially leading to use-after-frees and double-frees. Maybe this struct should have a hidden constructor or be marked unsafe?
Here's a proof-of-concept showing a use-after-free with this struct:
#![forbid(unsafe_code)]

use xcb::base::Error;

fn main() {
    let mut v1: Vec<i8> = vec![1, 2, 3, 0];
    let _ = Error {
        ptr: v1.as_mut_ptr(),
    };

    // use-after-free in v1
    // v1 and v2 are now backed by the same buffer.
    let v2: Vec<i8> = vec![4, 5, 6, 0];

    let measure1 = v2[0];
    v1[0] = 123;
    let measure2 = v2[0];

    assert_eq!(measure1, measure2);
}

This outputs:
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `4`,
 right: `123`', src/main.rs:32:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
free(): double free detected in tcache 2

Terminated with signal 6 (SIGABRT)

This is addressed in the new API. See v1.0.0-beta.0 release in the v1.0-dev branch.
In a nutshell, error management is now defined as follow:
// at crate level:

pub enum ProtocolError {
    X(x::Error),
    Xkb(xkb::Error),
    // other extensions errors
}

pub enum Error {
    Conn(ConnError),
    Protocol(ProtocolError),
}

pub type ProtocolResult<T> = std::Result<T, ProtocolError>;
pub type Result<T> = std::Result<T, Error>;

impl Connection {
    pub fn wait_for_event(&self) -> Result<Event> { /* ... */ }
    pub fn check_request(&self, cookie: CheckedVoidCookie) -> ProtocolResult<()> { /* ... */ }
    pub fn wait_for_reply<C>(&self, cookie: C) -> Result<C::Reply> { /* ... */ }
}

pub trait BaseError {
    /// Build an error from a raw pointer
    ///
    /// # Safety
    /// `raw` must be a valid pointer to the error, and be allocated with `libc::malloc`
    unsafe fn from_raw(raw: *mut xcb_generic_error_t) -> Self;

    /// Convert the error into a raw pointer
    ///
    /// # Safety
    /// returned value should be freed with `libc::free` to avoid memory leak, or used to build a new error
    unsafe fn into_raw(self) -> *mut xcb_generic_error_t;

    /// Obtain the error as a raw pointer
    fn as_raw(&self) -> *mut xcb_generic_error_t;
}

pub mod x {
    // auto generated module for the core X protocol

    pub struct RequestError {
        raw: *mut xcb_generic_error_t,
    }

    impl BaseError for RequestError {
        unsafe fn from_raw(raw: *mut xcb_generic_error_t) -> Self {
            RequestError { raw }
        }

        unsafe fn into_raw(self) -> *mut xcb_generic_error_t {
            let raw = self.raw;
            std::mem::forget(self);
            raw
        }

        fn as_raw(&self) -> *mut xcb_generic_error_t {
            self.raw
        }
    }

    impl RequestError {
        pub fn response_type(&self) -> u8 { /* ... */ }
        pub fn error_code(&self) -> u8 { /* ... */ }
        pub fn bad_value(&self) -> u32 { /* ... */ }
    }

    pub struct ValueError {
        raw: *mut xcb_generic_error_t,
    }

    impl BaseError for ValueError { /* ... */ }

    pub type WindowError = ValueError;
    pub type PixmapError = ValueError;

    /// Unified error type for the X core protocol
    #[derive(Debug)]
    pub enum Error {
        Request(RequestError),
        Value(ValueError),
        Window(WindowError),
        Pixmap(PixmapError),
        // ...
    }
}

and would generally be used as follow:
fn main() -> xcb::Result<()> {
    // ...
    conn.check_request(conn.send_request_checked(&x::ChangeProperty {
        mode: x::PropMode::Replace,
        window,
        property: wm_protocols,
        r#type: x::ATOM_ATOM,
        data: &[wm_del_window],
    }))?;  // <-- note '?' here

    loop {
        match conn.wait_for_event()? {  // <-- note '?' here
            // ...
        }
    }
}

v1.0.0 is released.

authors: ammaraskar rtbo

repo: rust-x-bindings/rust-xcb


text:
Custom std::fmt::Debug for Line & Ray

fn main() {
    println!("{:?}", Line3::new(Point3::new(1,2,3),Point3::new(4,5,6)));
    println!("{:?}", Ray3::new(Point3::new(1,2,3),Vector3::new(4,5,6)));
}

Usually prints this:
Line { origin: Point3 [1, 2, 3], dest: Point3 [4, 5, 6], phantom_s: PhantomData, phantom_v: PhantomData }
Ray { origin: Point3 [1, 2, 3], direction: Vector3 [4, 5, 6], phantom_s: PhantomData }

This patch changes the output to look like this:
Line(Point3 [1, 2, 3], Point3 [4, 5, 6])
Ray(Point3 [1, 2, 3], Vector3 [4, 5, 6])

Is this something you want a PR for?
Suggestions, reviews and other feedback is welcome.

Sounds useful!

#134

authors: eadf kvark

repo: rustgd/collision-rs


text:
Closures Example is not working.

link:
https://rustwasm.github.io/wasm-bindgen/exbuild/closures/
is not working.
It is showing the following error on console
RuntimeError: unreachable
    at __rust_start_panic (wasm-function[673]:1)
    at rust_panic (wasm-function[594]:31)
    at std::panicking::rust_panic_with_hook::h5d8808384a53a826 (wasm-function[130]:304)
    at std::panicking::continue_panic_fmt::h821bed92a14cf5d5 (wasm-function[324]:116)
    at rust_begin_unwind (wasm-function[664]:3)
    at core::panicking::panic_fmt::hfa7141b9630aa10b (wasm-function[487]:70)
    at core::option::expect_failed::he814056c2f8215e8 (wasm-function[396]:91)
    at <core::option::Option<T>>::expect::h33643d65ce465d73 (wasm-function[161]:170)
    at closures::setup_clock::hcd8ed9afea8a32fa (wasm-function[44]:115)
    at closures::run::h0707c66cb6048ff9 (wasm-function[31]:1014)

and a warning:
[Deprecation] Element.createShadowRoot is deprecated and will be removed in M73, around March 2019. Please use Element.attachShadow instead. See https://www.chromestatus.com/features/4507242028072960 for more details.

cc @xtuc when trying to debug this with --target web it looks like the error goes away, so I'm curious if you know if this was an accidental regression in webpack?

I'm having an issue building the example locally, when running wasm-pack:
thread 'main' panicked at 'index 114 out of range for slice of length 39', src/libcore/slice/mod.rs:2413:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::_print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::continue_panic_fmt
   6: rust_begin_unwind
   7: core::panicking::panic_fmt
   8: core::slice::slice_index_len_fail
   9: <&'src str as wasm_bindgen_cli_support::decode::Decode<'src>>::decode
  10: <alloc::vec::Vec<T> as wasm_bindgen_cli_support::decode::Decode<'src>>::decode
  11: <wasm_bindgen_cli_support::decode::Export<'a> as wasm_bindgen_cli_support::decode::Decode<'a>>::decode
  12: <alloc::vec::Vec<T> as wasm_bindgen_cli_support::decode::Decode<'src>>::decode
  13: <wasm_bindgen_cli_support::decode::Program<'a> as wasm_bindgen_cli_support::decode::Decode<'a>>::decode
  14: wasm_bindgen_cli_support::Bindgen::_generate
  15: wasm_bindgen::main
  16: std::rt::lang_start::{{closure}}
  17: std::panicking::try::do_call
  18: __rust_maybe_catch_panic
  19: std::rt::lang_start_internal
  20: main
Error: Running the wasm-bindgen CLI

Does it seems familiar to you @alexcrichton?
wasm-pack 0.8.1. I'm unsure how I could get wasm-bindgen's version.

Ah that's unfortunately expected from a few other bugs, but you can fix it by copying the example out to a separate directory and building from there

Indeed, I can build it now. It's quite hard to debug but it seems to be in the wasm binary itself. I'll keep trying.

Found the bug! Let me do a PR.

authors: alexcrichton sahil-bansal-sb xtuc

repo: rustwasm/wasm-bindgen


text:
Validate the schema version before processing descriptors

While looking into #3204 I noticed that the error given by wasm-pack test was a panic while decoding descriptors, rather than the 'version mismatch' error that using an incompatible CLI version should give. It turns out that that was happening because descriptors were getting parsed before the custom section, and hence before the version check.
So, I reordered things so that the custom section is parsed (but not processed) before the descriptors, which includes checking the schema version. The custom section still gets processed afterwards, though, since that seems to depend on the results of processing descriptors.

👍

authors: Liamolucko alexcrichton


text:
Default flow direction and spatial transforms

🐛 Bug
First of all: I have really enjoyed and benefited from working with PyTorch Geometric in my thesis. Great work!
Now the issue: The spatial transforms (like transforms.Cartesian and transforms.Polar) compute the coördinates for target nodes relative to the source nodes, i.e. in the tangent plane of the source nodes:
 cart = pos[col] - pos[row]

However, the default flow for MessagePassing networks is from source to target. For example, for nn.GMMConv, it seems to me that the aggregation step therefore uses the wrong coordinates (target -> src, instead of src -> target).
Additional context
This issue does not seem to break the performance of GMMConv. I ran into this, as I am working on a technique that assumes we are working in the tangent plane of src (as is assumed in Polar and Cartesian transforms) and breaks when this assumption is broken.
Additional thoughts
It might help to rename col and row variable names to src and target to more easily distinguish between the two and know what each index is referring to.

Isn‘t that correct? Given that row is the source and col is the target node, we compute the Cartesian vector as pos[col] - pos[row], which is the natural formulation in linear algebra (and isn’t even that related to message passing, is it?) In addition, it does not break anything as long as it is consistent.

It’s definitely correct for computing the polar and Cartesian coordinates relative to the source node. I thought (and I’ll recheck this, since I am not 100% sure) that this is not consistent with how GMMConv is currently implemented. I’ll get back to you on this later tonight.
On 18 Aug 2019, 16:13 +0200, Matthias Fey notifications@github.com, wrote:

Isn‘t that correct? Given that row is the source and col is the target node, we compute the Cartesian vector as pos[col] - pos[row], which is the natural formulation in linear algebra (and isn’t even that related to message passing, is it?) In addition, it does not break anything as long as it is consistent.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

I've looked at it again. TL;DR the issue is (only) semantic and most people will likely not run into it the same way I did. I'm sorry for nitpicking. I thought it would help to clarify, as I found out about this inconsistency through a week of debugging my code.
Now for the issue: GMMConv takes as input some pseudo coordinates, let's denote them as pseudo[i,j]. Per default, i corresponds to the target nodes and j corresponds to the source nodes:
# self.flow defaults to 'source to target'
i, j = (0, 1) if self.flow == 'target_to_source' else (1, 0)

If we use the cartesian coordinates for pseudo, we would expect to get the following formulation:
pseudo[i, j] = pos[j] - pos[i]

Since we assumed i corresponds to the target nodes and j to the source nodes, we can write this as:
# row = src, col = target
pseudo[i, j] = pos[row] - pos[col]

This is the inverse of what is actually computed in transforms.Cartesian and transforms.Polar.
This typically doesn't matter, as most spatial methods do not care if you input pseudo[i, j] or -pseudo[i, j]. I ran into this issue, as I experimented with a random permutation of the polar coordinates for each point, breaking the relation between pseudo[i,j] and pseudo[j,i], so that pseudo[i,j] != -pseudo[j,i].

Thank you for the detailed description. Nitpicking is good and helps improving the package :)
I see your point, but IMO I would expect Cartesian coordinates to be computed via
pos[i] - pos[j] = pos[col] - pos[row]

since this denotes a vector from point j to i (which is equivalent to the default message passing flow). In other words, you would not compute pseudo[i,j] = pos[j] - pos[i] in the default message passing flow, but rather pseudo[j,i] = pos[i] - pos[j] and save it as an edge feature to the edge e_{j,i}. WDYT?

I think I get what you're saying: the vector represented by the cartesian or polar pseudo coordinates should point in the direction of the message passing flow and it is true that this is what happens with the default message passing flow.
I would argue, in the case of GMMConv and other spatial methods, that it should be in the reverse direction, because that means the coordinates are centered around the point the messages are aggregated to. This is the way Masci et al. define the convolutional operator in Geodesic Convolutional Neural Networks on Riemannian Manifolds (p 39, eq 7) which is followed by Monti et al. for GMM.
It could also be that this seems natural to me, as I had been assuming the default flow to be the other way around (from col to row). This is mainly due to me working within the context of spatial methods, where one tends to aggregate values from neighbors to the 'center point', whereas it is more natural in the message passing paradigm to send messages from the 'center point' to its neighbors.


text:
Support for AirQ

Description:
Discuss with Alexey about supporting AirQ in webUI so we can continue fw project

Some units need to be fixed

authors: laurijamsa markoaamunkajo


text:
Unification: min / max / average

Description:
Let's use same formula for calculation as is used on iOS

Confirmed values match with iOS, QA passed


text:
[erlang 19] Release 1.1.2 ?

Sat Aug 20 12:12:43 BST 2016
Attempting to update the homebrew formula  from  lfe-1.0.
Release 1.1.1 fails to build using erlang 19 (either with make compile or  rebar compile):
src/lfe_macro.erl:624: Warning: function trim_stacktrace/1 is unused
src/lfe_macro.erl:1022: Warning: variable 'V' shadowed in 'fun'
Compiled src/lfe_macro.erl
src/lfe_qlc.erl:282: Warning: call to erl_lint:modify_line/2 will fail, since it was removed in 19.0; use erl_parse:map_anno/2
src/lfe_qlc.erl:372: Warning: call to erl_parse:set_line/2 will fail, since it was removed in 19.0; use erl_anno:set_line/2
src/lfe_qlc.erl:439: Warning: call to erl_parse:set_line/2 will fail, since it was removed in 19.0; use erl_anno:set_line/2
src/lfe_qlc.erl:2470: Warning: call to erl_parse:set_line/2 will fail, since it was removed in 19.0; use erl_anno:set_line/2
src/lfe_qlc.erl:2473: Warning: call to erl_parse:set_line/2 will fail, since it was removed in 19.0; use erl_anno:set_line/2
src/lfe_qlc.erl:2476: Warning: erl_parse:get_attribute/2: removed in 19.0; use erl_anno:{column,line,location,text}/1 instead
src/lfe_qlc.erl:2651: Warning: call to erl_parse:set_line/2 will fail, since it was removed in 19.0; use erl_anno:set_line/2
src/lfe_qlc.erl:2680: Warning: erl_parse:get_attribute/2: removed in 19.0; use erl_anno:{column,line,location,text}/1 instead
src/lfe_qlc.erl:2682: Warning: call to erl_parse:set_line/2 will fail, since it was removed in 19.0; use erl_anno:set_line/2
src/lfe_qlc.erl:2694: Warning: erl_parse:get_attribute/2: removed in 19.0; use erl_anno:{column,line,location,text}/1 instead
src/lfe_qlc.erl:2696: Warning: call to erl_parse:set_line/2 will fail, since it was removed in 19.0; use erl_anno:set_line/2
src/lfe_qlc.erl:2711: Warning: call to erl_parse:set_line/2 will fail, since it was removed in 19.0; use erl_anno:set_line/2
src/lfe_qlc.erl:2715: Warning: erl_parse:get_attribute/2: removed in 19.0; use erl_anno:{column,line,location,text}/1 instead
src/lfe_qlc.erl:2722: Warning: erl_parse:get_attribute/2: removed in 19.0; use erl_anno:{column,line,location,text}/1 instead
src/lfe_qlc.erl:2726: Warning: erl_parse:get_attribute/2: removed in 19.0; use erl_anno:{column,line,location,text}/1 instead
...
src/lfe_edlin_expand.erl:228: Warning: function over_non_symbol/3 is unused
...
src/lfe_eval.erl:128: Warning: variable 'M' shadowed in 'fun'
src/lfe_eval.erl:132: Warning: variable 'M' shadowed in 'fun'
src/lfe_eval.erl:462: Warning: function init_letrec_env/1 is unused
src/lfe_eval.erl:468: Warning: function extend_letrec_env/3 is unused
src/lfe_eval.erl:468: Warning: variable 'Fbs0' is unused
src/lfe_eval.erl:737: Warning: variable 'M' shadowed in 'fun'
src/lfe_eval.erl:741: Warning: variable 'M' shadowed in 'fun'
...
src/lfe_codegen.erl:830: Warning: variable 'St' shadowed in 'fun'
src/lfe_codegen.erl:953: Warning: variable 'St' shadowed in 'fun'
src/lfe_codegen.erl:960: Warning: variable 'St' shadowed in 'fun'
src/lfe_codegen.erl:965: Warning: variable 'St' shadowed in 'fun'
Compiled src/lfe_codegen.erl
ERROR:
*** MISSING LFE COMPILER ***
  You must do one of the following:
    a) Install LFE globally in your erl libs
    b) Add LFE as a dep for your project, eg:
       {lfe, "0.6.1",
        {git, "git://github.com/rvirding/lfe",
         {tag, "v0.6.1"}}}

Compiling src/cl.lfe failed:

Would it be possible to have release-1.1.2 created - to accommodate erlang 19?

See #248. I've been using the develop branch on 19 with no issues for maybe a week now, by the way. I think @rvirding has a little more polishing/experimenting to do, but the next release is on the way :smile:

Sat Aug 20 12:24:18 BST 2016
I did see #248 before posting - seemed to focus on parallel make (-j).
No problems with HEAD (apart from warnings about shadowed vars).
Looking forward to impending release!

Right, I guess I just meant my comment on there.

There is a fix in the develop branch for lfe_qlc.erl so it will now work with erlang 19. It will be in 1.1.2. The lfe_qlc module is only used for query list comprenesions so for most people this is not a problem. I can't do much about the parallel compilation, you need to find a way which compiles all the .elr files first and the .lfe files.

FYI @rprimus, we're testing on 19.0 on Travis as of fa824cd.

I believe lfe-1.2.0 resolve this issue.

If @rprimus agrees I think we can close this issue.

authors: arpunk rprimus rvirding yurrriq

repo: rvirding/lfe


text:
README document

Create a readme document at root of repo to play the game. I am thinking of making a github release with different arch builds so that users can use curl to install the program as a single binary using Robs build tool https://github.com/rwxrob/good.
For now, I can point the install steps using go install.

Done

repo: rwx-yxu/blackjack


text:
Version mismatch and compile errors

There are different issues:

version mismatch: when I load NativeToolkit from Unity Asset store, there are 2 version:
version 1.2 from May,22 2019 and for Unity 2018.2.20
version 1.2.2 from August,13 2018
Why has the new version a lower version number? This way Asset Store update mechanism is confused.

Unity build for iOS: Using latest unity 2019.3.3f1, on OSX Catalina 10.15.3
here I get a build error: Exception: Calling TargetGuidByName with name='Unity-iPhone' is deprecated.
I needed to change file Assets/NativeToolkit/Editor/PostProcessor.cs, line 24 to:
string targetGuid = proj.GetUnityMainTargetGuid();

Compile errors in XCode Version 11.3.1: compiling a sample project with Native Toolkit only I get a list of linker errors:

Undefined symbols for architecture arm64:
  "_OBJC_CLASS_$_ALAssetsLibrary", referenced from:
      objc-class-ref in ImageTools.o
  "_OBJC_CLASS_$_ABPeoplePickerNavigationController", referenced from:
      objc-class-ref in Contacts.o
  "_kABPersonFirstNameProperty", referenced from:
      -[Contacts peoplePickerNavigationController:shouldContinueAfterSelectingPerson:] in Contacts.o
  "_kABPersonPhoneProperty", referenced from:
      -[Contacts peoplePickerNavigationController:shouldContinueAfterSelectingPerson:] in Contacts.o
  "_kABPersonEmailProperty", referenced from:
      -[Contacts peoplePickerNavigationController:shouldContinueAfterSelectingPerson:] in Contacts.o
  "_ABRecordCopyValue", referenced from:
      -[Contacts peoplePickerNavigationController:shouldContinueAfterSelectingPerson:] in Contacts.o
  "_kABPersonLastNameProperty", referenced from:
      -[Contacts peoplePickerNavigationController:shouldContinueAfterSelectingPerson:] in Contacts.o
  "_OBJC_CLASS_$_MFMailComposeViewController", referenced from:
      objc-class-ref in Email.o
  "_ABMultiValueCopyValueAtIndex", referenced from:
      -[Contacts peoplePickerNavigationController:shouldContinueAfterSelectingPerson:] in Contacts.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

What to do to link without errors?
Thank you
Frank

Did you have any luck getting this building? I'm having issues getting it built too.

Also having this issue. Any updates?

authors: helferapp mahgo mr-austinmiller


text:
lorri: allow customization of the lorri package

Description
Allow me to install a different Lorri package with the new package option.
Checklist

[x] Code formatted with ./format.

[x] Code tested through nix-shell --pure tests -A run.all.

[ ] Test cases updated/added. See example.

[x] Commit messages are formatted like
{component}: {description}

{long description}

See CONTRIBUTING for more information and recent commit messages for examples.

If this PR adds a new module

[ ] Added myself as module maintainer. See example.

[ ] Added myself and the module files to .github/CODEOWNERS.

Thanks! Rebased to master in ad8b644de19aca8a7534c9695a7446b258156d06.

authors: kalbasit rycee

repo: rycee/home-manager

license: mit


text:
Create UI Mockup for Profile Page

About the Profile Page:

Users should be able to view their profile information, such as name, email, and role.
Users should be able to change their password.
The page should provide a logout option to securely exit the application.

Task:

[ ] Design a profile page where users can view personal information, change passwords, and log out.

I started working for the profile page in the morning.

Status: Ongoing
Completed: The logo and bars
Next Stop: Icons
Blockers: It's hard to finalize and think what is the appropriate visuals for our UI.

authors: rykieldc shanebergado


text:
Completed assignment 2

What changes are you trying to make? (e.g. Adding or removing code, refactoring existing code, adding reports)
Built RNN model for text generation
What did you learn from the changes you have made?
How to use Keras to build RNN model
Was there another approach you were thinking about making? If so, what approach(es) were you thinking of?
NA
Were there any challenges? If so, what issue(s) did you face? How did you overcome it?
NA
How were these changes tested?
NA
A reference to a related issue in your repository (if applicable)
NA
Checklist

[x] I can confirm that my changes are working as intended

A2 complete


text:
Support for sorted queries

Two primary use cases for this are prioritized ACLs and longest prefix matching in routing

Do you need 1 output or many? For one aggregation (max) is enough.

We need one, but we also don't have support for aggregation yet.

authors: mbudiu-vmw ryzhyk


text:
how to generate getter

how to generate getter??
example ：
private String something;
public String getSomething(){
return something==null?"":something;
}

This is not generatable atm. Lombok only provides support to shorten simple getters wth the @Getter annotation.
Also I think the code you have should just ddeal with nulls instead of empty strings, but thats another topic.

In the light of the recent thoughts on onNull, and the niceties of a getOrDefault kind of construct, this could be a feature request for a default-value parameter on @Getter.
However, since annotation parameters can't be ordinary objects, the closest one could reasonably get would be to rewrite @Getter(defaultValue="42") Integer foo; to return this.foo == null ? Integer.valueOf("42") : this.foo;.

repo: rzwitserloot/lombok


text:
Getter and Setter in interface?

Good mornig, is there a way to integrate @Getter and @Setter into a interface?
Example:
public interface example{
    @Getter @Setter int variable;
}

public class exampleClass implements example{
   @Getter @Setter int variable;
}

or something like this.
Thanks.

What code would you have them generate that they don't generate already?

We would like to write @getter and @setter into interface instead of getFoo() and setFoo(), whereas we have a lot of attributes to be expose!

Still confused. You can already write @Getter and @Setter for an interface field foo. They generate abstract methods: public abstract <type> getFoo(); and public abstract void setFoo(<type> foo);. Can you please write what the generated code of your example
public interface example{
    @Getter @Setter int variable;
}

should look like?

Eclipse return me an error when i write this piece of code
public interface example{
    @Getter @Setter int variable;
}

this is the error "The blank final field variable may not have been initialized" it's defined like a final variable, but it isn't what i would.

You'll get the same error without Lombok, too. Interfaces allow only constants. You'd need Lombok to remove the field and to generate the accessors.
This sounds like an interesting feature, but possibly not common enough. AFAIK this is not implemented yet and I can't see it in the changelog either.
I added an initializer expression to variable so the error disappeared. Now, In my Eclipse 3.8.1 with Lombok 1-16.8, the field gets marked as static final and a getter and a setter get generated as abstract methods. This doesn't look like a sensible behavior.

So if I marked as static final, I'm able to use the abstract generated method? i didn't think about it, perfect!
Anyway I think that it could be an intresting feature to implement, if it's possible.

@lucalas, let me clear this up a bit because it seams you are missing some details. Any field in an interface is automatically public static final, that is, a constant. This is why the example you gave initially was confusing and I tried to get you to write the result you wanted.
Annotating these fields adds public abstract methods like I showed above. You would need to implement them in a the implementing class. a setter is useless because the field is a constant, unless you declare a field with the same name in the class and refer the generated methods to it, and you have no way to enforce that field declaration. Furthermore, you would be left with a meaningless public constant which isn't supposed to be used.
You could generate a getter for the constant field in the interface if the method would be modified to default, something I do not recommend. What I think you want is to force the class to have a getter and setter method. That is, what you want is an automatic way to generate this:
interface MyInter {
    int getMyInt();
   `void setMyInt(int myInt);
}

which kind of forces
class MyClass implements MyInter {
    @Setter @Getter private int myInt;
}

The problem is that there is no field in the interface to annotate. That means that the best you could ask for is something like:
@Getter{of="myInt"} @Setter{of="myInt"}
interface MyInter

which will generate the above abstract interface methods and possibly the concrete, normal, methods for any implementing class. That will force the programmer to write thew appropriate field declaration.
Does that make sense to you?

The problem is that there is no field in the interface to annotate.

IMHO what the OP was expecting from this example
public interface MyInterface {
    @Getter @Setter int x;
}

namely a transformation into
public interface MyInterface {
    int getX();
    void setX(int x);
}

i.e., the generation of the accessors and the removal of the field is reasonable.
The fact that all fields in an interface are effectively static final is irrelevant here, as the field only exists as a placeholder the annotations can be placed on.

@omega09 I understand your concerns, and I know that i can declare only a static final field in a interface and my question may seem a bit strange, but if you read last @Maaartinus  answer maybe it's more clearly what i would like to do.

The fact that all fields in an interface are effectively static final is irrelevant here, as the field only exists as a placeholder the annotations can be placed on.

I don't really need a field in interface, it's something like a placeholder, nothing more, because i need the two methods get and set.
Have getter and setter help me to have a neater code!  (or maybe because i'm too lazy to write get and set method for all fields ahahah)
Maybe my question it wasn't clear, sorry!

IMHO what the OP was expecting from this example

That may very well be and it seems that you're right, but I wish the "this generates that" section would have been written in the initial post and save all the guesses.

the removal of the field is reasonable.
the field only exists as a placeholder the annotations can be placed on.

I would be glad if this is the case and this feature can be implemented the way you mentioned. Did you ever see Lombok "removing" typed code?

As already mentioned, the current behavior is that Lombok generates static getters and setters for the static field. Although one could argue that that is not as useful, we will not fix that, breaking other people's code, without a sufficient reason.
We technically could trigger on uninitialized fields, generate the interface methods and remove the field. But I am afraid that just the fact that the field has an initializer modifies the static-ness might be  confusing.
Also, Lombok can only do its job if the java file was syntactically correct. And I am afraid that the parser for interfaces already doesn't allow for uninitialized fields, or might no longer in a future update.

One more thing, although Lombok has a way to generate javadoc, for interfaces I think I would prefer to see the javadoc in the code.
And it is just method signatures. So it really doesn't save that much code.

authors: Maaartinus lucalas omega09 rspilker


text:
Feature request: Annotation to transform between transport and business objects

I often separate my transport layer from my business logic layer, although they use very similar objects.  Often their fields and types are identical. I frequently write boilerplate to construct one object from the other, or transform one into the other. I would really appreciate an annotation to do that instead.

This can get arbitrarily complicated. Luckily, there's http://mapstruct.org and it works together with lombok.

authors: Maaartinus judebert