Enable propagating host rustflags to build scripts

What does this PR try to resolve?
This PR primarily fixes #10206, but in doing so it also slightly modifies the interface for the unstable target-applies-to-host feature (#9453), and adds the unstable target-applies-to-host-kind flag to mirror target-applies-to-host for build scripts and other host artifacts.
The commit messages have more in-depth discussion.
How should we test and review this PR?
The test case from #10206 now works rather than producing an error. It has also been added a regression test case. A few additional test cases have also been added to handle the expected behavior around rustflags for build scripts with and without target-applies-to-host-kind enabled.
Additional information

This changes the interface for target-applies-to-host so that it does not need to be specified twice to be used. And it can still be set through configuration files using the [unstable] table. However, we may(?) want to pick a stable format for in-file configuration of this setting unless we intend for it to only ever be a command-line flag.
It may be that target-applies-to-host-kind is never behavior we want users to turn on, and that it should therefore simply be removed and hard-coded as being false.
It's not entirely clear how target-applies-to-host-kind should interact with -Zmultitarget. If, for example, requested_kinds = [HostTarget, SomeOtherTarget] and kind.is_host(), should RUSTFLAGS take effect or not? For the time being I've just hard-coded the behavior for single targets, and the answer would be "no".

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

PR failures are due to new clap 3.1.0 deprecations combined with -Dwarnings. Fixing separately in https://github.com/rust-lang/cargo/pull/10396.

/cc @jameshilliard too since you contributed the original feature :)

This changes the interface for target-applies-to-host so that it does not need to be specified twice to be used. And it can still be set through configuration files using the [unstable] table. However, we may(?) want to pick a stable format for in-file configuration of this setting unless we intend for it to only ever be a command-line flag.

Why did you remove the stable format? The only reason you have to specify target-applies-to-host twice is because the nightly feature is not yet stabilized.

3. It's not entirely clear how target-applies-to-host-kind should interact with -Zmultitarget. If, for example, requested_kinds = [HostTarget, SomeOtherTarget] and kind.is_host(), should RUSTFLAGS take effect or not? For the time being I've just hard-coded the behavior for single targets, and the answer would be "no".

Target configs are always triple specific, so setting the config flag target-applies-to-host = true is just intended to use/apply the target specific triple configs as if they were also host triple specific configs, the idea is you would basically get equivalent behavior by copying the target triple configs manually as host triple configs(this is effectively cargo's current default behavior). Setting target-applies-to-host = true should never apply a target triple config unless the host triple being built matches the target triple config.

I gave the original discussion for the feature another reading, and I agree with you that having the top-level configuration option is probably the way to go. It has a similar flavor to resolver = "2", where we may want to flip the default in the future. So I've restored the past logic in that regard 👍
The reason this is hairy is because the behavior of Cargo today is inconsistent. Only linker and runner from [target.<host triple>] are applied to host artifacts, but not rustflags. The way I've represented that in the latest revision of this PR that I just pushed is that target-applies-to-host really has three states: unset, true, and false. When unset, the current (inconsistent) behavior is preserved. When set to true, everything from [target.<host triple>] is respected for host artifacts. And when set to true, [target.<host triple>] is ignored for host artifacts. That strikes the right balance to me at least.
I'm personally also not in favor of having -Zhost-config change the default for target-applies-to-host. Instead, I'd prefer for -Zhost-config to produce an error if target-applies-to-host isn't set to false. That way we start to incentivize affected users to put target-applies-to-host = false in their configuration files. But I've left that logic as-is for now.

The reason this is hairy is because the behavior of Cargo today is inconsistent.

Yeah, it's def a hairy mess.

Only linker and runner from [target.] are applied to host artifacts, but not rustflags.

Ugh, that's pretty bad, I only tested the linkers myself since that's what was causing build errors for us. That should probably just be fixed outright as it's clearly a bug.

When unset, the current (inconsistent) behavior is preserved.

IMO the best behavior when unset would be to apply target triples to host if --target is not set but don't apply if it is set. In addition if a host table is present without --target set I would have it override that and disable apply target configs to host.
So defaults like this for cases where target-applies-to-host is not explicitly specified is probably the least likely to break configurations IMO:

if --target unset && no host table present => target-applies-to-host = true
if --target unset && host table present => target-applies-to-host = false
if --target set => target-applies-to-host = false

And when set to true, [target.<host triple>] is ignored for host artifacts.

I assume you mean when set to false here right?

I'm personally also not in favor of having -Zhost-config change the default for target-applies-to-host. Instead, I'd prefer for -Zhost-config to produce an error if target-applies-to-host isn't set to false.

Well the main reason for having it change the default was mostly to minimize the amount of combinations(branch conditions essentially) to test, I only wanted the host table feature to be tested with the new defaults for target-applies-to-host. By having it change the default it cuts down the amount of combination testing needing as you then no longer have to test the host table combined with old defaults.

Only linker and runner from [target.] are applied to host artifacts, but not rustflags.

Ugh, that's pretty bad, I only tested the linkers myself since that's what was causing build errors for us. That should probably just be fixed outright as it's clearly a bug.

When unset, the current (inconsistent) behavior is preserved.

IMO the best behavior when unset would be to apply target triples to host if --target is not set but don't apply if it is set.

I don't think we can just fix it, sadly, as that would likely break a bunch of cross-compiling users. Hence the "legacy" mode this PR implements. I think we almost certainly have to preserve backwards compatibility here, or cause a bunch of unnecessary churn for users. Though if the Cargo team is okay with the breakage, I'm okay with removing the legacy mode. I just assumed they wouldn't be.

In addition if a host table is present without --target set I would have it override that and disable apply target configs to host.
So defaults like this for cases where target-applies-to-host is not explicitly specified is probably the least likely to break configurations IMO:
1. if `--target` unset && no host table present => `target-applies-to-host = true`

2. if `--target` unset && host table present => `target-applies-to-host = false`

3. if `--target` set => `target-applies-to-host = false`

I really dislike dynamic defaults, since they tend to be hard to discover and hard to debug. I'd much rather (as this PR implements) have -Zhost-config require target-applies-to-host = false. I also don't think we can change today's behavior with respect to --target being set/unset except at something like an edition boundary, since a fair number of users probably rely on the current behavior (though here, too, if the Cargo team is okay with the breakage, we should do it). Which then leads to the choices this PR makes:

If -Zhost-config and target-applies-to-host != false, error.
If target-applies-to-host is true, pick up linker, runner, and rustflags (or, really, all keys) from target.<host> for host artifacts.
If target-applies-to-host is false, do not pick up target.<host> for host artifacts.
If target-applies-to-host is unset (which implies no host table), pick up linker, runner, and any future fields from target.<host> for host artifacts. Pick up rustflags only if --target isn't passed.

Then, come next edition, we make target-applies-to-host = "false" the default. And maybe the edition after we remove target-applies-to-host as a user-visible configuration option.

And when set to true, [target.<host triple>] is ignored for host artifacts.

I assume you mean when set to false here right?

Sorry, yes, false.

I'm personally also not in favor of having -Zhost-config change the default for target-applies-to-host. Instead, I'd prefer for -Zhost-config to produce an error if target-applies-to-host isn't set to false.

Well the main reason for having it change the default was mostly to minimize the amount of combinations(branch conditions essentially) to test, I only wanted the host table feature to be tested with the new defaults for target-applies-to-host. By having it change the default it cuts down the amount of combination testing needing as you then no longer have to test the host table combined with old defaults.

The number of combinations should be the same, since = true is just outright disallowed with -Zhost-config.

I don't think we can just fix it, sadly, as that would likely break a bunch of cross-compiling users.

We're talking about fixing the rustflags bug in the nightly only host-config feature right? Isn't the entire point of the feature being nightly only to allow breaking changes/fixes?

Hence the "legacy" mode this PR implements. I think we almost certainly have to preserve backwards compatibility here, or cause a bunch of unnecessary churn for users. Though if the Cargo team is okay with the breakage, I'm okay with removing the legacy mode. I just assumed they wouldn't be.

I'm highly skeptical changing the target-applies-to-host defaults would be all that problematic mostly since the target-applies-to-host = false default behavior already effectively exists for target triple != host triple cross compilation scenarios.
But this target-applies-to-host default change is an entirely separate issue AFAIU from fixing the host-config rustflags bug, I think it's probably best to fix the rustflags bug separately then worry about the defaults/stabilization path for the host-config and target-applies-to-host features after that's taken care of.
Build scripts typically don't usually need custom build flags at all to function(we don't even need/use the host-config feature in buildroot, we only use the target-applies-to-host feature to override the existing default buggy target-applies-to-host = true behavior so that our x86_64 cross builds don't break due to linker errors) AFAIU in most cases build scripts just need to be able to execute on the host and cargo doesn't even have a way to provide a host artifact specific configs without enabling -Zhost-config anyways, only triple specific configs are supported in stable toolchains which are inherently buggy for host artifact cross compilation configuration.
Arguably anyone cross compiling who has a config that changing this default breaks has a buggy config already, they just happen to have things working by accident, either way the point of the target-applies-to-host config flag is to provide an escape hatch to restore the previous buggy cross compilation behavior for anyone who actually depends on it.
From my understanding the Cargo team is fine with this approach provided there is a transition period before changing the default(although I personally don't actually think this is necessary since fixing the buggy behavior is only likely to break obscure configurations anyways).

I really dislike dynamic defaults, since they tend to be hard to discover and hard to debug.

I mean, if the goal is to have host triple == target triple cross compilation work as expected by default while breaking the least amount of existing configs then dynamic defaults here is probably the least terrible option.

I'd much rather (as this PR implements) have -Zhost-config require target-applies-to-host = false.

What are you trying to do here? Requiring a config option that's intended to be stabilized in order to enable setting a nightly gate for a feature also intended to be stabilized makes no sense to me.
Setting -Zhost-config isn't something that will do anything when the host config feature is stabilized, you would use the host config options once stabilized just by adding a host config table, -Zhost-config is a nightly feature gate option that will be removed.

I also don't think we can change today's behavior with respect to --target being set/unset except at something like an edition boundary, since a fair number of users probably rely on the current behavior (though here, too, if the Cargo team is okay with the breakage, we should do it).

Either way this seems to be something separate from the host.rustflags fix. Can we not fix the host.rustflags bug in the nightly host-config feature and then worry about --target behavior separately? The host/target split logic in cargo is rather complex/confusing in general and having all these changes intertwined makes things difficult to review here.

Which then leads to the choices this PR makes:
1. If `-Zhost-config` and `target-applies-to-host != false`, error.

This doesn't make sense since -Zhost-config is just a nightly feature gate flag that will not even exist when running builds with stable toolchains.

2. If `target-applies-to-host` is `true`, pick up `linker`, `runner`, and `rustflags` (or, really, all keys) from `target.<host>` for host artifacts.

This sounds fine.

3. If `target-applies-to-host` is `false`, do not pick up `target.<host>` for host artifacts.

This sounds fine.

4. If `target-applies-to-host` is unset (which implies no host table), pick up `linker`, `runner`, and any future fields from `target.<host>` for host artifacts. Pick up `rustflags` only if `--target` _isn't_ passed.

This is extremely confusing, AFAIU isn't not even possible to set host artifact specific rustflags at all without this fix, or any host artifact specific config options at all(only triple specific flags seem possible without nightly features) for that matter without enabling the nightly -Zhost-config feature gate.
The report #10206 that this fixes seems to be entirely referencing a bug in the nightly host-config feature and not something applicable to a stabilized feature, which should be able to be fixed without a migration period as that feature is not stabilized yet.
Is there also a different bug with rustflags for target triple config flags(ie without -Zhost-config being used at all).

Then, come next edition, we make target-applies-to-host = "false" the default. And maybe the edition after we remove target-applies-to-host as a user-visible configuration option.

I think the important part is just changing the default before we stabilize the host-config feature to reduce the amount of potential branch conditions we have to handle/test.

The number of combinations should be the same, since = true is just outright disallowed with -Zhost-config.

We want to test the host-config feature behavior as if it were already stabilized. You appear to be effectively trying to test the -Zhost-config nightly feature gating logic which isn't particularly useful as nightly feature gating isn't applicable to features once stabilized at all.

I don't think we can just fix it, sadly, as that would likely break a bunch of cross-compiling users.

We're talking about fixing the rustflags bug in the nightly only host-config feature right? Isn't the entire point of the feature being nightly only to allow breaking changes/fixes?

#10206 is the primary bug being fixed here, but I think it's better to also give a path towards fixing the logic around rustflags in [target.*], which is currently entirely ignored for host artifacts, since that can also be fixed through the target-applies-to-host flag. And rustflags in [target.*] is stable, so we can't just change its behavior.
We could just say that rustflags in [target.*] will never be supported for host artifacts, and then have target-applies-to-host = true just have this known bug, but that seems unsatisfactory when target-applies-to-host eventually stabilizes. After all, when it's set to true, you'd expect it to work "for everything".

I'm highly skeptical changing the target-applies-to-host defaults would be all that problematic ..

This is speculation. You might be entirely right, but it is changing behavior in a backwards incompatible way, so it may break users we haven't thought about. Ultimately, the decision of whether or not it's okay to change the defaults for target-applies-to-host within an edition, and whether or not we can just make rustflags in [target.*] start applying to host artifacts in a minor Cargo release, is up to the Cargo team, so I'd like to hear their take on that aspect of this.

I mean, if the goal is to have host triple == target triple cross compilation work as expected by default while breaking the least amount of existing configs then dynamic defaults here is probably the least terrible option.

I don't understand why that's the case? The dynamic default only applies with -Zhost-config, which is unstable, so I'm not worried about breaking that by making it a hard error rather than a changing default.

I'd much rather (as this PR implements) have -Zhost-config require target-applies-to-host = false.

What are you trying to do here? Requiring a config option that's intended to be stabilized in order to enable setting a nightly gate for a feature also intended to be stabilized makes no sense to me.

The "real" behavior I want here is that if there is a [host] table in the config and target-applies-to-host != false, then that should generate an error. But since host-config is unstable, this was a small-diff way to achieve the same thing. The current "change the default" logic also relies on -Zhost-config, so either way the logic would need to be updated for the eventual stabilization of host-config.

Can we not fix the host.rustflags bug in the nightly host-config feature and then worry about --target behavior separately? The host/target split logic in cargo is rather complex/confusing in general and having all these changes intertwined makes things difficult to review here.

#10206 is really just an artifact of a larger bug in the rustflag application logic for host artifacts. This PR fixes that logic, which happens to also fix #10206. I wouldn't want to special-case a fix just for #10206 but otherwise leave the logic for rustflags for host artifacts in its current state.

... Is there also a different bug with rustflags for target triple config flags(ie without -Zhost-config being used at all).

Yes. I don't know that it's been filed, but basically:
[target.x86_64-unknown-linux-gnu]
rustflags = ["-Clink-arg=-foo"]
linker = "some-linker"

Will use some-linker to build host artifacts (like build scripts), but will not pass -Clink-arg=-foo to rustc (and thus not to the linker).

Then, come next edition, we make target-applies-to-host = "false" the default. And maybe the edition after we remove target-applies-to-host as a user-visible configuration option.

I think the important part is just changing the default before we stabilize the host-config feature to reduce the amount of potential branch conditions we have to handle/test.

This is where I think it comes down to whether this is breakage the Cargo team is okay with. I suspect they'll only want to change the default at an edition boundary. Note, though, that that doesn't preclude stabilizing host-config before the edition, it just means that anyone who wants to use [host] will need to explicitly set target-applies-to-host = false (hence why I want not setting that to be an error).

I think it's better to also give a path towards fixing the logic around rustflags in [target.*], which is currently entirely ignored for host artifacts

I guess it makes sense to fix this if target-applies-to-host = true although setting rustflags for host scripts this way is probably not a good idea in general since target-applies-to-host = true is generally not desired behavior in general it's there mostly as an escape hatch once the default is changed that allows restoring the previously inconsistent behavior as well as to force the correct behavior before the default is changed.

We could just say that rustflags in [target.*] will never be supported for host artifacts, and then have target-applies-to-host = true just have this known bug, but that seems unsatisfactory when target-applies-to-host eventually stabilizes. After all, when it's set to true, you'd expect it to work "for everything".

The downside to fixing it in [target.*] is that target-applies-to-host = true would no longer restore the previous buggy behavior that users may depend on. I mean target-applies-to-host = true is just a bad idea in general so I'm not sure we should actually fix it but I don't really care much either way.

Ultimately, the decision of whether or not it's okay to change the defaults for target-applies-to-host within an edition, and whether or not we can just make rustflags in [target.*] start applying to host artifacts in a minor Cargo release, is up to the Cargo team, so I'd like to hear their take on that aspect of this.

Yeah, personally I think both the defaults and rustflags in [target.*] bug should just be immediately fixed as the existing behavior is causing a lot of pain for anyone trying to cross compile.

The dynamic default only applies with -Zhost-config, which is unstable, so I'm not worried about breaking that by making it a hard error rather than a changing default.

The idea is that setting -Zhost-config allows for testing the new defaults at the same time as the host-config feature, hard erroring based on -Zhost-config due to anything other than another -Z flag is IMO not useful as -Zhost-config won't exist in the future.

The "real" behavior I want here is that if there is a [host] table in the config and target-applies-to-host != false, then that should generate an error.

Right, you should actually make it error under those conditions and test for that error.

But since host-config is unstable, this was a small-diff way to achieve the same thing.

Testing for a -Z flag is not useful as it doesn't test for the actual desired behavior(we want to essentially emulate the after stabilization behavior), I realize it's much easier to test for a -Z flag...but it's basically a pointless test since it's not testing that the error is produced under the right error conditions(a [host] table in the config and target-applies-to-host != false). The reason for tying the default change to the [host] table was so that the [host] table can be used without having to set target-applies-to-host at all. I think we should allow the [host] table as long as target-applies-to-host is not set to true once the host-config feature is stabilized as this simplifies things.

Yes. I don't know that it's been filed, but basically:
[target.x86_64-unknown-linux-gnu]
rustflags = ["-Clink-arg=-foo"]
linker = "some-linker"

Will use some-linker to build host artifacts (like build scripts), but will not pass -Clink-arg=-foo to rustc (and thus not to the linker).

Ok, yeah, not sure if cargo team wants that existing buggy behavior preserved.

This is where I think it comes down to whether this is breakage the Cargo team is okay with. I suspect they'll only want to change the default at an edition boundary.

Well we can at least fix this in the host-config table immediately since that's nightly only, fixing it in target tables can be left for later worst case and may need to be preserved for backwards compat(I don't really think it matters myself), but yeah that would be up to cargo team.

Note, though, that that doesn't preclude stabilizing host-config before the edition, it just means that anyone who wants to use [host] will need to explicitly set target-applies-to-host = false (hence why I want not setting that to be an error).

Plan AFAIU was to first stabilize the target-applies-to-host config variable, so I don't think erroring on target-applies-to-host = true plus [host] existing would be an issue.

I think it's better to also give a path towards fixing the logic around rustflags in [target.*], which is currently entirely ignored for host artifacts

I guess it makes sense to fix this if target-applies-to-host = true although setting rustflags for host scripts this way is probably not a good idea in general since target-applies-to-host = true is generally not desired behavior in general it's there mostly as an escape hatch once the default is changed that allows restoring the previously inconsistent behavior as well as to force the correct behavior before the default is changed.

I totally agree! The goal should be to make the default for target-applies-to-host be false. I'm just saying that since we're thinking of stabilizing target-applies-to-host, we'll want to stabilize it such that = true also actually enables what the setting says it enables. If setting it to true didn't change the behavior as it relates to rustflags, I think the setting should be renamed to something like consistently-apply-target, where = false gives the current behavior (including not fixing rustflags), and = true gives the same behavior as target-applies-to-host = false. I prefer the true/false/unset toggle this PR currently implements though.

The downside to fixing it in [target.*] is that target-applies-to-host = true would no longer restore the previous buggy behavior that users may depend on. I mean target-applies-to-host = true is just a bad idea in general so I'm not sure we should actually fix it but I don't really care much either way.

Ah, but users can simply leave target-applies-to-host unset to retain exactly the same as the current behavior. But if they set it to true or false, then they get exactly the behavior implied by the setting's name.

personally I think both the defaults and rustflags in [target.*] bug should just be immediately fixed as the existing behavior is causing a lot of pain for anyone trying to cross compile.

I'm totally open to that path too, and I agree it would be theoretically "better". The question is just whether it would incur too much ecosystem breakage, which I feel like I have a relatively poor handle on.

The idea is that setting -Zhost-config allows for testing the new defaults at the same time as the host-config feature, hard erroring based on -Zhost-config due to anything other than another -Z flag is IMO not useful as -Zhost-config won't exist in the future.

But the code already does that by changing the default based on whether -Zhost-config is passed. When, in the future, it is stabilized, and so the flag isn't passed, what would the default be changed based on? If you're saying the default will already have been changed by then, then that would mean we cannot land host-config until target-applies-to-host defaults to false, which might be a long time for now. By instead requiring target-applies-to-host to be set to false, we can stabilize host-config without changing the default to target-applies-to-host.
That said, you are right that the logic here should be updated so that it's an error to even specify [host] without having target-applies-to-host = false. I can update this PR to do that, or do that in a follow-up PR since -Zhost-config isn't stable at the moment anyway, and the current code already relies on being able to check for its existence. I'd slightly prefer the latter, but if it's a requirement I'll update the PR tomorrow.

Testing for a -Z flag is not useful as it doesn't test for the actual desired behavior ... The reason for tying the default change to the [host] table was so that the [host] table can be used without having to set target-applies-to-host at all. I think we should allow the [host] table as long as target-applies-to-host is not set to true once the host-config feature is stabilized as this simplifies things.

I disagree here — this is the "explicit is better than implicit" argument; it's better for the config to actually specify the settings its changing from defaults, rather than relying on arcane knowledge of what settings change what defaults. Down that path lies misery. It's very counter-intuitive for the presence of [host] in a configuration file to implicitly change the semantics of [target.*].

Plan AFAIU was to first stabilize the target-applies-to-host config variable, so I don't think erroring on target-applies-to-host = true plus [host] existing would be an issue.

It is a problem if, as I argue for above, we don't allow the presence of [host] to change the default of target-applies-to-host.

I'm just saying that since we're thinking of stabilizing target-applies-to-host, we'll want to stabilize it such that = true also actually enables what the setting says it enables. If setting it to true didn't change the behavior as it relates to rustflags, I think the setting should be renamed to something like consistently-apply-target, where = false gives the current behavior (including not fixing rustflags), and = true gives the same behavior as target-applies-to-host = false. I prefer the true/false/unset toggle this PR currently implements though.

The purpose of target-applies-to-host was from my understanding just to allow a user to retain the existing buggy behavior across the default change, essentially they would pre-emptively set target-applies-to-host = true(after stabilization of target-applies-to-host but before the default change and stabilization of the host-config feature) so that the default change would have no effect if they actually depended on that buggy behavior. So it was more for retaining backwards/forwards compatibility when changing the default. Using the true/false/unset toggle approach would mean this wouldn't really work for that purpose AFAIU.

Ah, but users can simply leave target-applies-to-host unset to retain exactly the same as the current behavior. But if they set it to true or false, then they get exactly the behavior implied by the setting's name.

This wouldn't allow retaining behavior compatibility across a default change with the same configuration though, that's the issue.

I'm totally open to that path too, and I agree it would be theoretically "better". The question is just whether it would incur too much ecosystem breakage, which I feel like I have a relatively poor handle on.

IMO it wouldn't but the cargo team didn't seem to think that was the case.

If you're saying the default will already have been changed by then, then that would mean we cannot land host-config until target-applies-to-host defaults to false, which might be a long time for now.

Yeah, AFAIU the plan was to change the default prior to or at the same time as the host-config was stabilized.

That said, you are right that the logic here should be updated so that it's an error to even specify [host] without having target-applies-to-host = false. I can update this PR to do that, or do that in a follow-up PR since -Zhost-config isn't stable at the moment anyway, and the current code already relies on being able to check for its existence.

The -Zhost-config changing defaults was to simplify the amount of branch conditions to test(since I didn't want to have to test [host] tables with both old and new defaults, only the new defaults), the default change is kinda separate from this, IMO the [host] table feature should not be stabilized before the defaults are changed.

I disagree here — this is the "explicit is better than implicit" argument; it's better for the config to actually specify the settings its changing from defaults, rather than relying on arcane knowledge of what settings change what defaults. Down that path lies misery. It's very counter-intuitive for the presence of [host] in a configuration file to implicitly change the semantics of [target.*].

Yeah, I mean I basically wanted to sidestep this issue entirely by not stabilizing the [host] table feature before a default change.

It is a problem if, as I argue for above, we don't allow the presence of [host] to change the default of target-applies-to-host.

I was mostly suggesting the dynamic defaults as a way to potentially stabilize the [host] table feature before the default change, although it's probably best to just push off [host] tables. I agree allowing the presence of a [host] to change the default is confusing, hence why the nightly gate -Zhost-config always applies the new defaults.

I think we're mostly understanding each other. I think this all comes down to the question: do we want to allow users to explicitly opt into host artifacts consistently (that is, including rustflags) using target configuration? I think I'm at this point convinced that we probably don't — we'd rather users move over to using [host] than opt into what we consider to be unfortunate and error-prone behavior. In which case I propose we rename target-applies-to-host to legacy-target-config-rules with a default of true (for now). This should (hopefully) avoid user confusion when they see target-applies-to-host = true and still don't have target.<host>.rustflags apply to host artifacts.
I'll then update this PR to remove support for having build.rustflags, target.<host>.rustflags, and RUSTFLAGS apply when --target is specified, and retain exactly the old behavior when legacy-target-config-rules = true. When legacy-target-config-rules = false (and -Zhost-config is on), host.rustflags (and only host.rustflags) will be respected (fixing #10206).
Of course we can bikeshed the name of the option further if we'd like, but I do think it needs to be changed given how inconsistently rustflags are applied today.

Alternatively, I could just make today's rustflags behavior consistent with how linker and runner are treated, and make build.rustflags, target.<host>.rustflags, and RUSTFLAGS apply after all when --target is specified. Then the configuration option could continue to be called target-applies-to-host, since = true would indeed give the expected behavior. And = false would make only [host] take effect, as for linker and runner. I think that's probably more likely to break users, but I'm happy to take that path instead if the Cargo team thinks it's better.

I think this all comes down to the question: do we want to allow users to explicitly opt into host artifacts consistently (that is, including rustflags) using target configuration? I think I'm at this point convinced that we probably don't — we'd rather users move over to using [host] than opt into what we consider to be unfortunate and error-prone behavior.

I'd say a little bit after host-config is stabilized(along with the target-applies-to-host = false default) we should start throwing deprecation warnings for target-applies-to-host = true and eventually remove the option entirely after users have had the chance to migrate to the new [host] table format.

In which case I propose we rename target-applies-to-host to legacy-target-config-rules with a default of true (for now). This should (hopefully) avoid user confusion when they see target-applies-to-host = true and still don't have target.<host>.rustflags apply to host artifacts.

I think target-applies-to-host is fine , even if it's not 100% accurate across all edge cases(like for rustflags) it's still far more descriptive than something like legacy-target-config-rules(it's entirely non-descriptive regarding what the legacy rules actually are).

Yes. I don't know that it's been filed, but basically:
[target.x86_64-unknown-linux-gnu]
rustflags = ["-Clink-arg=-foo"]
linker = "some-linker"

Will use some-linker to build host artifacts (like build scripts), but will not pass -Clink-arg=-foo to rustc (and thus not to the linker).

So based on my reading the docs this is not actually a bug, it just appears cargo intentionally does not support passing rustflags for host binaries when cross compiling with --target at all here.

I'll then update this PR to remove support for having build.rustflags, target.<host>.rustflags, and RUSTFLAGS apply when --target is specified

Yeah, that seems to be consistent with the docs.

Alternatively, I could just make today's rustflags behavior consistent with how linker and runner are treated, and make build.rustflags, target.<host>.rustflags, and RUSTFLAGS apply after all when --target is specified.

Probably not a good idea since the docs explicitly indicate rustflags never apply to host binary builds at all when --target is specified. IMO the rustflags behavior here of not applying to host binary builds is correct while the linker and runner behavior of applying to host binary builds is not.

Then the configuration option could continue to be called target-applies-to-host, since = true would indeed give the expected behavior.

Except the rustflags behavior of never applying to host binaries when compiling with --target is actually a documented exception here so that would violate the expectations implied by the documentation. So we should probably only apply to host binaries when a --target is specified for the [host] table regardless.

And = false would make only [host] take effect, as for linker and runner.

Looking at this in more detail I think we should in general make linker and runner behave like rustflags rather than the other way around, for that matter I wonder why there's no build.linker or build.runner options along the lines of build.rustflags, that seems like an omission that should be fixed as well as the whole target triple specific configuration format is not desirable in a lot of cases as it requires dirty hacks like this when setting the cross linker in the env.

I still think a different name would be better, since target-applies-to-host = true pretty strongly implies that it would apply "fully". That is, including rustflags. I agree my proposed name isn't great either, since it doesn't fully convey what it actually changes, but I'd argue neither does target-applies-to-host since it has exceptions. I'd rather someone go look up what the behavior is because the name is vague, than have them assume incorrectly and get surprised, since that path tends to be a lot more painful to debug ("three days later it turned out my problem was the Cargo doesn't respect rustflags from target, but does respect the linker setting, despite what the option implies").

I'd rather someone go look up what the behavior is because the name is vague, than have them assume incorrectly and get surprised, since that path tends to be a lot more painful to debug ("three days later it turned out my problem was the Cargo doesn't respect rustflags from target, but does respect the linker setting, despite what the option implies").

Just add a conditional warning if target-applies-to-host = true is set explicitly while target.<host>.rustflags is set that those flags will not be applied to the host build.

Just add a conditional warning if target-applies-to-host = true is set explicitly while target.<host>.rustflags is set that those flags will not be applied to the host build.

Unfortunately that'll generate spurious warnings that the user would then have no way to avoid. Specifically, target.<host>.rustflags will apply to non-build-script artifacts, and that may be exactly what the user wanted.

Unfortunately that'll generate spurious warnings that the user would then have no way to avoid.

By limiting it to configurations with an explicit target-applies-to-host = true setting you would mostly avoid spurious warnings(which you'd probably want to log at info level or something like that), and once host-config is stabilized those users can migrate to that.

Specifically, target.<host>.rustflags will apply to non-build-script artifacts, and that may be exactly what the user wanted.

Only target.<target>.rustflags would apply to non-build-script artifacts AFAIU which is only sometimes the same as target.<host>.rustflags(ie only in target triple == host triple scenarios), you'd only want to log something when target.<host>.rustflags is set and target-applies-to-host = true.
Notably this particular configuration would be rather unusual/uncommon as the behavior for linkers with target-applies-to-host = true is effectively broken in a lot of cases due to the target triple == host triple linker confusion issue(which target-applies-to-host = false fixes).

By limiting it to configurations with an explicit target-applies-to-host = true setting you would mostly avoid spurious warnings(which you'd probably want to log at info level or something like that), and once host-config is stabilized those users can migrate to that.

Cargo doesn't really have log levels that users can hide. There's only warnings and errors. I also don't think it's great to introduce warnings that users cannot avoid except by rewriting their configurations to use [host]. That could be a decent chunk of work, and forcing them to do it isn't ideal. I'm not entirely against the idea though, just a concern that needs to be weighed.

Notably this particular configuration would be rather unusual/uncommon

Do you have any data on this? Given that it's how Cargo works today, I worry about all of the many many Cargo configurations that are already out there and are working even if it's for, perhaps, the wrong reasons.

Thanks for the thorough write-up!
So, the reason why the PR does things the way it does is because it was trying to allow for us to take the path of having a tri-state target-applies-to-host of legacy (today's behavior), true ([target.<host>] always applies to host artifacts), and false ([target.<host>] never applies to host artifacts). If the decision is that we don't want to support that middle option, I can simplify the logic accordingly. Will do that shortly.

For example instead of what we have today I might propose dropping -Ztarget-applies-to-host and instead just having -Zhost-config which gates [host] and reading the top-level target-applies-to-host field.

That makes sense to me, since I think no-one will want target-applies-to-host = false without the ability to set [host], so we might as well group them together under one -Z. I think we should do that in a separate PR though.

Does that make sense and still solve the original problem at hand here? I'm mostly thinking that the get_target_applies_to_host function is a bit overly complicated right now as it seems to be trying to post-rationalize things that may not have been working in the first place.

I think I can remove all the changes I made to get_target_applies_to_host from this PR, and have things still work, so will do that. We can always do a follow-up PR where we update that logic as necessary.

Additionally I don't think env_args is structured internally as I would expect because naively I'd expect one path for host stuff and one path for target stuff, preceded by some complicated backwards compatibility logic about which path to take.

Yep, as mentioned above this is because I originally wrote this to be amenable to having = true do "what it says on the tin". If we never think we should support that, I'll make that change to simplify 👍

Also, to add, the current logic in env_args already has a lot of early returns, so this PR doesn't really change that. Those early returns are because, for example, if RUSTFLAGS is used then no other rustflag sources are even considered. This PR just changes when each of those source are considered in the first place.

@alexcrichton I believe I've modified this to be more in line with your expectations now. As mentioned above, I think we should adjust the -Z flag and (potentially) change the logic in get_target_applies_to_host in a separate PR, so I've reverted my changes related to those two in this PR.

Is the latest patch more in line with what you were expecting?

Ok I think I understand what you mean by the tri-state behavior, I never fully understood that but seeing the test cases now and how they're working clarifies this for me at least. My main priority in reviewing all of this rustflags/target/host related stuff is to ensure that breakage is quanitified and either mitigated or deemed acceptable. In that sense I'm pretty confident that this PR doesn't change the current behavior, which is good in the sense that it mitigates possible breakage. For the future, though, I think we'll want the tri-state idea but not necessarily super-well-supported.
I don't think anyone will really argue that today's behavior is correct and should be codified into Cargo for all time. Today's behavior is the amalgamation of growing over years as PRs touched various portions and we as Cargo reviewers didn't do a great job of seeing how everything fits together. What's done is done though, we move past it. This I think means that the stabilization story for target-applies-to-host may be a bit different though. In my mind the "tri-state" is "not configured", true, and false. The "not configured" case is whatever Cargo does today to prevent breaking any existing builds. In the future I was assuming we would stabilize as true and then in the future switch to false at some point later. I believe, though, that at least in my desired interpretation of true then stabilizing as true would be a breaking change because as noted here some tests aren't behaving as I'd expect (where when you say target-applies-to-host that doesn't actually happen). Instead this may mean that we need to bite the bullet on breakage and simply stabilize the false option first (and maybe even just switch internal defaults and leave the target-applies-to-host option unstable).
Basically what I'm trying to do is to chart a course from where we are to where we want to be with minimal breakage to the ecosystem. Ideally this would mean that at any time if someone hits a breakage they can flip a switch to go back to some previous behavior or something like that. I've been working under the assumption that this is possible but it may simply not be possible. This may all simply mean that breakage is unavoidable and if the breakage doesn't work for someone all we can say is "sorry you can hold back on upgrading Cargo for a bit while the breakage is worked through".

I completely agree — that matches my thinking on the subject.
I think the right question then becomes is "how hard is mitigation". If target-applies-to-host = false is made the default, then that will break users with no recourse until [host] is stabilized — they'll be unable to set the rustflags and linker for build scripts when --target is passed. Which seems untenable to me. We could perhaps (as you suggested) group target-applies-to-host and host-config together under a single -Z so they land together, but I'll leave that up to you. In the meantime, I actually wonder if the right thing to do short-term is to change the default to = true so that Cargo's behavior is at least consistent, and so that there is a way to accomplish what users might want, even if it's not exactly the behavior we think is least likely to cause problems.
In any case, I also agree with you that this PR doesn't change current behavior beyond fixing #10206, and so should be possible to safely land.

@bors: r+
Ok well we can get all this sorted out during the stabilization of the features here. I agree this is fine to go for now. Personally I continue to feel that these unstable features are also gated on the fact that cargo build is "all host" rather than the expected "some host some target" builds, because if we were to stabilize target-applies-to-host = false, which I think is what we want, then RUSTFLAGS="" cargo build wouldn't actually apply any flags anywhere.

:pushpin: Commit 56db82957fa356b63a58176e591593ee1d5c5ee3 has been approved by alexcrichton

:hourglass: Testing commit 56db82957fa356b63a58176e591593ee1d5c5ee3 with merge 3d6970d50e30e797b8e26b2b9b1bdf92dc381f34...

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

It's a good point. I wonder if the way to go here is to take a lesson from https://github.com/alexcrichton/cc-rs/pull/9 and add support for RUSTFLAGS_$TARGET and the like. That way we can say that RUSTFLAGS applies to all targets (including the host), TARGET_RUSTFLAGS applies only to the target(s), HOST_RUSTFLAGS applies only to the host, RUSTFLAGS_$TARGET applies only to $TARGET, etc. What do you think?

Maybe? That's something I think needs discussion outside of just this PR and input from others as well.

Oh, yes, definitely. I just don't see a way around doing that, or something like it, if we want cargo build to work like cargo build --target <host>.

@rustbot label: +Z-target-applies-to-host


feat(MeasureTheory/Measure/WithDensity): add withDensity_ae_eq

For a given density d, if it is a.e. nonnegative, then, for any functions f and g, f =ᵐ[μ.withDensity d] g ↔ f =ᵐ[μ] g.

Can you replace the current withDensity_absolutelyContinuous' with the following:
lemma withDensity_absolutelyContinuous'' {μ : Measure α} {f : α → ℝ≥0∞}
    (hf : AEMeasurable f μ) (hf_ne_zero : ∀ᵐ x ∂μ, f x ≠ 0)  :
    μ ≪ μ.withDensity f := by
  refine Measure.AbsolutelyContinuous.mk (fun s hs hμs ↦ ?_)
  rw [withDensity_apply _ hs, lintegral_eq_zero_iff' hf.restrict,
    ae_eq_restrict_iff_indicator_ae_eq hs, Set.indicator_zero', Filter.EventuallyEq, ae_iff] at hμs
  simp only [ae_iff, ne_eq, not_not] at hf_ne_zero
  simp only [Pi.zero_apply, Set.indicator_apply_eq_zero, not_forall, exists_prop] at hμs
  have hle : s ⊆ {a | a ∈ s ∧ ¬f a = 0} ∪ {a | f a = 0}
  . exact fun x hx ↦ or_iff_not_imp_right.mpr <| fun hnx ↦ ⟨hx, hnx⟩
  exact measure_mono_null hle <| nonpos_iff_eq_zero.1 <| le_trans (measure_union_le _ _)
    <| hμs.symm ▸ zero_add _ |>.symm ▸ hf_ne_zero.le

and then your lemma is then simply
theorem withDensity_ae_eq {f g : α → β} {d : α → ℝ≥0∞}
    (hd : AEMeasurable d μ) (h_ae_nonneg : ∀ᵐ x ∂μ, d x ≠ 0) :
    f =ᵐ[μ.withDensity d] g ↔ f =ᵐ[μ] g := by
  refine ⟨fun h ↦ Measure.AbsolutelyContinuous.ae_eq ?_ h,
    fun h ↦ Measure.AbsolutelyContinuous.ae_eq (withDensity_absolutelyContinuous μ d) h⟩
  refine withDensity_absolutelyContinuous'' hd  h_ae_nonneg

Note that with this you only need ae measurability

Thank you for your suggestion. It indeed relax the Measurable hypothesis on d. By the way, I was able to show
theorem withDensity_apply_eq_zero' {f : α → ℝ≥0∞} {s : Set α} (hf : AEMeasurable f μ) :
    μ.withDensity f s = 0 ↔ μ ({ x | f x ≠ 0 } ∩ s) = 0

which is basically the same as withDensity_apply_eq_zero but relaxing the Measurable assumption. It makes the proof of withDensity_apply_eq_zero way simpler:
theorem withDensity_apply_eq_zero {f : α → ℝ≥0∞} {s : Set α} (hf : Measurable f) :
    μ.withDensity f s = 0 ↔ μ ({ x | f x ≠ 0 } ∩ s) = 0 :=
  withDensity_apply_eq_zero' <| Measurable.aemeasurable hf

I will probably be able to prove ae_withDensity_iff' and ae_withDensity_iff_ae_restrict' and probably more using only AEMeasurable assumption. Do we want that?

Yes, if you are able to relax the conditions that'd be great

Ok, I'll do another PR for everything. Thanks!


Disable focus on the input filter on open

Is there an option to disable focus on the filter on open, on small mobile screens it scrolls to the selected option then jumps back to the filter input form which is confusing.

Closing this in favor of #1511.


Added option to work with services sales, avoiding shipment addresses

Hi all,
According V2 API docs, I added an option at Config class with intent to reduce checkout steps when selling services that do not requires shipment addresses.
pagseguro-api-pagamentos-anexo-checkout-servico.pdf
If it be useful, please feel free to do any enhancement

Config has changed, needs adjusts

May I adjust it with the new Config file version?

@jdcarvalho yeah would be great so we can merge, I think @ellisonleao can help if any question about the new config parser. (but AFAIK it is just a simple dict now)


Automatic assignment to Flex Team

As an Intake user
I want open General requests to be automatically assigned to the Flex team
so that I don't have to assign requests individually

Assumptions & Scope
Only General requests will be automatically assigned to the Flex Team Queue
Personal requests will stay with the currently assigned user when opened
Assignment occurs when moving request from Intake in Progress state to Open state
If multiple ministries are selected, all resulting individual requests will be assigned to Flex Team
What is IN scope?
What is NOT in scope?
Acceptance Criteria
Scenario 1: Select Open state in state change dropdown

GIVEN I am an IAO user on a request in the Intake in Progress state
WHEN I select Open from the state change dropdown
THEN the state change modal will appear
AND the modal will display the "IAO Assigned To" field as "Flex Team Queue"

Scenario 2: Cancel Open state change

GIVEN I have selected Open from the state change dropdown
WHEN I select Cancel on the state change modal
THEN the modal will close
AND the IAO assigned user will remain as the same user previously assigned

*Scenario 3: Save Open state change

GIVEN I have selected Open from the state change dropdown
WHEN I select Save on the state change modal
THEN the modal will close
AND the request will now be assigned to the Flex Team Queue
AND the previous user will no longer be assigned
AND the request will no longer display in the Intake team queue

Dependencies? What is the impact of this dependency? (If so, link dependency in the ticket, make it visible in a team´s backlog)
Validation Rules? (If yes, list here)
Design
@xxx - please link the Design here
Definition of Ready

[ ] Is there a well articulated User Story?
[ ] Is there Acceptance Criteria that covers all scenarios (happy/sad paths)?
[ ] If there is a user interface, is there a design?
[ ] Does the user story need user research/validation?
[ ] Does this User Story needs stakeholder approval?
[ ] Design / Solution accepted by Product Owner
[ ] Is this user story small enough to be completed in a Sprint? Should it be split?
[ ] Are the dependencies known/ understood? (technical, business, regulatory/policy)
[ ] Has the story been estimated?

Definition of Done

[ ] Passes developer unit tests
[ ] Passes peer code review
[ ] If there's a user interface, passes UX assurance
[ ] Passes QA of Acceptance Criteria with verification in Dev and Test
[ ] Confirm Test cases built and succeeding
[ ] No regression test failures
[ ] Test coverage acceptable by Product Owner
[ ] Ticket ready to be merged to master or story branch
[ ] Developer to list Config changes/ Update documents and designs
[ ] Can be demoed in Sprint Review
[ ] Tagged as part of a Release
[ ] Feature flagged if required
[ ] Change Management activities done?

@m-prodan @lmullane @mpilchar @JHarrietha-AOT Please review and make any changes you see fit. For refinement at Sprint Planning Nov 24

Looks good to me, @arielleandrews

@arielleandrews Looks good, I just added General Request in the Scenarios. I know its in the assumptions just always good to have in the specific scenarios as well

Team structure and Ministries serviced found at this link: https://bcgov.sharepoint.com/:x:/r/teams/03521/Shared Documents/General/IAO Processing Teams.xlsx?d=w74ab3990f0574ab49121c6d455cb9c60&csf=1&web=1

QA completed, all scenarios passed in Chrome, Edge and Firefox. Personal requests are assigned to generic Processing Team, will need to be assigned to specific teams in future user story.


Initial code for building customized VexRiscv on-demand.

Prototype code for generating a VexRiscv variant on demand.   To trigger, just use any unrecognized variant, for example, add this to the project Makefile:
export EXTRA_LITEX_ARGS
EXTRA_LITEX_ARGS += --cpu-variant doesnotexist+cfu

The current code ignores the variant and just builds a vanilla VexRiscv.   More code needs to be added to parse the variant string to generate the config and the corresponding canonical Verilog file name.

Does this code change also patch it into the cpu variants dictionary? Assuming you tested this change to make sure it did?

Okay looks good to me. We can discuss the TODOs as next action item.


Stationary Zone

Just thought to open a conversation for better understanding of the stationary zone.
I understand its usage in terms of the ping minimisation etc - But I now have my users coming up as 'Stationary' rather than 'Away'
Could we even name the stationary zone based on their location - ie lat long determining the suburb and naming the zone accordingly ?
I dont recall if this was the same in v2 - i hung off reinstalling until v3 was ready so it has been some time

The Stationary Zone is just like all other zones except it changes Location to where you have been for a while. The iOS app picks up it’s location and moves a device into and out of it. Exit triggers are issued when the device moves out of the zone like all other zones.
The naming of the stationary zone is the same as in v2.4. It’s not possible to do  a lat/long lookup to see where you are. Since each device has their own stationary zone, You can change the base text and add the first 3-letters of the device name to the friendly name. For example, instead of all devices having a display name of “Stationary”, set the custom name to “[name]StatZone  “. My stationary would be GarStatZone in the Event Log and on the device tracker state values.
The stationary Zone is configured on the Special Zones screen.


mscc crashes when tuned outside of amateur bands

When tuning outside of the assigned amateur bands mscc switches to the GEN band and then can crash when moving in that band.
Another symptom - mscc was on 17m and when tuning down outside of that band it went to 20m and back to 17m then to 20m etc...
Attaching logs grabbed after that crash.
17m-20_crash.tar.gz

I think this has been fixed in the latest release on the forum.  Please download and install again.

Installed the newest MSCC.
Still crashing when going outside of the amateur band.
E.G. on 20m and tuning down outside of the band it moves to 9MHZ then crashes as you move down more.

I believe that it was set to1K as that is what I normally use for moving through the band.

This has been fixed.   Note:  When in an amateur band tuning stops at the top or bottom of the band.


Changes schema to include LinkReport model

This is a pull request that forms part of a link-checking feature for collections-publisher. The aim is for publishers to be able to check that links in their step-by-step guides are still alive. We're going to batch up all the links in a Step and send them to link-checker-api, collect the returned batch_id and store it against the Step, and then retrieve that batch by calling the API again when the batch is complete..
This pull request changes the schema and adds a new table to the database, called LinkReports. It also adds a relationship to the Step table. It sets up the branch for application changes.

@jonodrew Can you change the title to of the commit to something shorter so that it fits on one line?
The convention is that the title should be no more than 50 characters, and each line no more than 72 characters.


Consider not supporting boolean matrixes

Commit cd9d5f8481edbebb2e62e4979ae4f73b7ac8ddd9 added support for boolean matrixes.
SPIR-V does not allow boolean matrixes. Section 2.16.1, Universal Validation Rules, Data Rules, states:

Matrix types can only be parameterized with floating-point types.

Good idea. Cross compilation between WSL and SPIR-V is important.


how pass react-pdf attributtes to the components

Hi, first thank you for create this package.
I read how work the package and if i understand, this package converts html tags like  and  to the react-pdf component .
My question is how to pass the react-pdf attributes directly to the converted component, for example:
I want to pass hyphenationCallback attribute to all the  components that the package returns.

Hi @JuanDiegoGV. Thank you for your question. Because this package only converts html strings to react-pdf components, it doesn't have a full react-dom setup with jsx attributes. In theory, someone could create a react-pdf-dom type of package that directly converts from react-dom JSX to react-pdf and passes along callback attributes, but I haven't taken that on at this time and it doesn't seem as useful because react-pdf can already be written in JSX.


Third-Party Plugins warning always shows

Bug Report
System Information

Debian 10 (Buster) LXC container on Proxmox server (Also Debian 10 Buster)
AMP Release "Ganymede" v<IP_ADDRESS>, built 02/03/2021 12:23
Mainline release stream

I confirm:

[x] that I have searched for an existing bug report for this issue.
[x] that I am using the latest available version of AMP.
[x] that my operating system is up-to-date.

Symptoms

Every time the Plugins menu item is selected, the Third Party Notice is displayed and needs to be acknowledged, regardless of whether or not the "Don't show me this again please" box has been checked previously. This is happening on a Minecraft server instance - I'm not sure if it happens on other types of instances.
Reproduction

Manage a Minecraft instance
Click on Plugins from the Main Menu
View the Third Party Notice
Set "Don't show" control to On, then click Acknowledge
Click on Status from the Main Menu
Click on Plugins from the Main Menu again
Observe that the Third Party Notice is shown again

Do you have any browser extensions installed that block cookies or similar?

I had Adblock Plus installed on Chrome on one Win10 machine - disabling the plugin didn't result in a change in behavior. I ran into the problem on Chrome 90.0.4430.72 (64-Bit Official) on two Win10 machines, one with ABP, one without any plugins at all. Also experienced on Vivaldi (unknown version, unknown plugins) on Win10, and Chrome for Android 89.0.4389.105 on Samsung Galaxy S10 5G (Android 11) with no plugins.
I did notice that today the behavior is slightly different across the board. Now, the "don't show" option persists through a management session. As long as I don't click "Return to Instances," I can navigate in and out of plugins and the notice is not displayed. However, if I click "Return to Instances" then manage the instance again, the notice is displayed.

This has been fixed. It was caused by a type issue. LocalStorage at one point used to preserve the types of things put into the root namespace. Now they become strings so "true" != true and it showed the prompt every time.


Cannot install module on [nvm v0.31.0 / node v5.10.0 / npm v3.8.5]

/Users/Cichol/.nvm/versions/node/v5.10.0/lib
└── (empty)

npm ERR! Darwin 15.4.0
npm ERR! argv "/Users/Cichol/.nvm/versions/node/v5.10.0/bin/node" "/Users/Cichol/.nvm/versions/node/v5.10.0/bin/npm" "install" "-g" "npm-check"
npm ERR! node v5.10.0
npm ERR! npm  v3.8.5
npm ERR! path /Users/Cichol/.nvm/versions/node/v5.10.0/bin/npm-check
npm ERR! code EEXIST

npm ERR! Refusing to delete /Users/Cichol/.nvm/versions/node/v5.10.0/bin/npm-check: ../lib/node_modules/npm-check/bin/cli.js symlink target is not controlled by npm /Users/Cichol/.nvm/versions/node/v5.10.0
npm ERR! File exists: /Users/Cichol/.nvm/versions/node/v5.10.0/bin/npm-check
npm ERR! Move it away, and try again.

npm ERR! Please include the following file with any support request:
npm ERR!     /Users/Cichol/Workspace/npm-debug.log
npm ERR! code 1

/Users/Cichol/Workspace/npm-debug.log @ https://gist.github.com/morrighan/08fdc964d167679972120b2aadcf5a39

Is it possible you might have installed with sudo in the past?
I think it's usually best to never installed node modules with sudo.


Milestone Two: Create a Portfolio Mobile Version

This milestone accomplishes the following:

Create a mobile portfolio version based on the Figma design
Make the page responsive using responsive measurements
Ensure no error using linter

Added the following sections as requested by @ouasamine

Contributing
Show Your Support
Acknowledgement


feature: repeat counter and repeat delay (in secs)

Merged to master. Please review code now on master since I am unable to verify the code at this moment since I do not have access to RPI @hiryu85 , thank you.


Invalid commonjs default import in prod builds

Describe the bug
We received a bug report (see: https://github.com/preactjs/preset-vite/issues/75) for the Preact vite preset that there is an issue with importing react-datetime. Upon further inspection this issue isn't related to Preact and can be reproduced with the React preset too. I was able to narrow it down to a difference in how default exports from commonjs modules are treated.
import DateTime from 'react-datetime';

if (typeof DateTime !== 'function') {
  // We hit this path only in prod builds
  throw new Error('This is a bug');
}
console.log('it works');

In development mode everything works as expected. But in production mode the default export is wrapped into an object: { default: ... } with a default property which contains the expected value. This additional indirection causes production builds to be incorrect.
Reproduction
https://stackblitz.com/edit/vitejs-vite-k6uuun?file=main.js
Steps to reproduce

Run npm install
Run npm run build
Run npm run preview
Check console

System Info
Not relevant, happens on all systems.

  System:
    OS: macOS 13.3.1
    CPU: (8) arm64 Apple M1 Pro
    Memory: 90.64 MB / 16.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 19.7.0 - /opt/homebrew/bin/node
    Yarn: 1.22.19 - /opt/homebrew/bin/yarn
    npm: 9.5.0 - /opt/homebrew/bin/npm
  Browsers:
    Chrome: 112.0.5615.137
    Chrome Canary: 114.0.5734.0
    Firefox: 111.0.1
    Safari: 16.4
  npmPackages:
    @vitejs/plugin-react: ^4.0.0 => 4.0.0
    vite: ^4.3.2 => 4.3.2

Used Package Manager
npm
Logs
No response
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

This didn't work with 4.3.2 but it worked with the current main branch (5731ac9caaef629e892e20394f0cc73c565d9a87). I guess https://github.com/rollup/plugins/pull/1455 fixed this.
This will work in the next version. 👍


Fix building of local urls in urlmap

In case a urlmap was created with usage of hosted repositories, the
resulting urls for some artifacts looked like
http://localhost:8080/api/depgraph/repo/urlmap/api/hosted/local-repo/...
instead of just
http://localhost:8080/api/hosted/local-repo/...
The same problem was found for downlog and content.

Note to self: thus also needs to be ported to new cartographer


asks

You might want to add asks to your "similar projects" list.

Nice, will add it in next commit.


Migration flags

Changes pulled out of #272

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 68.31%. Comparing base (81fde1a) to head (78fdf68).

Additional details and impacted files
@@           Coverage Diff           @@
##           celo10     #275   +/-   ##
=======================================
  Coverage   68.30%   68.31%
=======================================
  Files          54       54
  Lines        4118     4119    +1
=======================================
+ Hits         2813     2814    +1
  Misses       1126     1126
  Partials      179      179

Flag
Coverage Δ

cannon-go-tests
68.31% <100.00%> (+<0.01%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines
Coverage Δ

cannon/mipsevm/testutil/evm.go
71.05% <100.00%> (+0.25%)
:arrow_up:

Flag changes are in https://github.com/celo-org/optimism/pull/279


add redirect for Jest blog feed

Summary

Docusaurus v1 RSS feed: https://jestjs.io/blog/feed.xml
Docusaurus v2 RSS feed: https://jestjs.netlify.app/blog/rss.xml

Redirect /blog/feed.xml to /blog/rss.xml so that feed subscribers can keep using their feeds after the migration.
The following URL should work: https://jestjs.netlify.app/blog/feed.xml
CC @SimenB

👍 good catch


Ongoing: integrate features implemented elsewhere into standalone node

This goes for advances in the network layer, ledger layer, consensus protocol layer, node shell, etc.

No time estimate: this will be an ongoing task updating the demo with features developed elsewhere.

This effort is centralised in the cardano-node repository.


About Us page hard to read on light themed browsers

Make the text on this section of the About Us page be light text when the browser is light themed

closed by #1408


[Bug]: Qwen2VL doesn't work with TPU backend

Your current environment

The output of `python collect_env.py`
Collecting environment information...
PyTorch version: 2.6.0.dev20241126+cpu
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: Ubuntu 22.04.2 LTS (x86_64)
GCC version: (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0
Clang version: Could not collect
CMake version: version 3.31.1
Libc version: glibc-2.35

Python version: 3.10.12 (main, Nov  6 2024, 20:22:13) [GCC 11.4.0] (64-bit runtime)
Python platform: Linux-5.19.0-1022-gcp-x86_64-with-glibc2.35
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

CPU:
Architecture:                    x86_64
CPU op-mode(s):                  32-bit, 64-bit
Address sizes:                   48 bits physical, 48 bits virtual
Byte Order:                      Little Endian
CPU(s):                          240
On-line CPU(s) list:             0-239
Vendor ID:                       AuthenticAMD
Model name:                      AMD EPYC 7B12
CPU family:                      23
Model:                           49
Thread(s) per core:              2
Core(s) per socket:              60
Socket(s):                       2
Stepping:                        0
BogoMIPS:                        4499.99
Flags:                           fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid tsc_known_freq pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw topoext ssbd ibrs ibpb stibp vmmcall fsgsbase tsc_adjust bmi1 avx2 smep bmi2 rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 clzero xsaveerptr arat npt nrip_save umip rdpid
Hypervisor vendor:               KVM
Virtualization type:             full
L1d cache:                       3.8 MiB (120 instances)
L1i cache:                       3.8 MiB (120 instances)
L2 cache:                        60 MiB (120 instances)
L3 cache:                        480 MiB (30 instances)
NUMA node(s):                    2
NUMA node0 CPU(s):               0-59,120-179
NUMA node1 CPU(s):               60-119,180-239
Vulnerability Itlb multihit:     Not affected
Vulnerability L1tf:              Not affected
Vulnerability Mds:               Not affected
Vulnerability Meltdown:          Not affected
Vulnerability Mmio stale data:   Not affected
Vulnerability Retbleed:          Mitigation; untrained return thunk; SMT enabled with STIBP protection
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1:        Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:        Mitigation; Retpolines, IBPB conditional, STIBP always-on, RSB filling, PBRSB-eIBRS Not affected
Vulnerability Srbds:             Not affected
Vulnerability Tsx async abort:   Not affected

Versions of relevant libraries:
[pip3] numpy==1.26.4
[pip3] pyzmq==26.2.0
[pip3] torch==2.6.0.dev20241126+cpu
[pip3] torch-xla==2.6.0+git39e67b5
[pip3] torchvision==0.20.0.dev20241126+cpu
[pip3] transformers==4.47.0
[conda] Could not collect
ROCM Version: Could not collect
Neuron SDK Version: N/A
vLLM Version: 0.6.4.post2.dev266+g7be15d93
vLLM Build Flags:
CUDA Archs: Not Set; ROCm: Disabled; Neuron: Disabled
GPU Topology:
Could not collect

LD_LIBRARY_PATH=/home/carlesoctav/vllm/.venv/lib/python3.10/site-packages/cv2/../../lib64:

Model Input Dumps
No response
🐛 Describe the bug
What I did was simply run vllm serve Qwen/Qwen2-VL-7B-Instruct. Previously, I tested the pure LLM (Qwen2.5-7B), and it worked.
I think this error code is relevant for debugging:
(RayWorkerWrapper pid=22778) INFO 12-08 10:38:29 importing.py:15] Triton not installed or not compatible; certain GPU-related functions will not be available. [repeated 2x across cluster]
(RayWorkerWrapper pid=22792) INFO 12-08 10:38:30 weight_utils.py:243] Using model weights format ['*.safetensors'] [repeated 2x across cluster]
(RayWorkerWrapper pid=22792) ERROR 12-08 10:40:08 worker_base.py:467] Error executing method determine_num_available_blocks.  Setting PJRT_DEVICE=TPU. [repeated 2x across cluster]

Before submitting a new issue...

[X] Make sure you already searched for relevant issues, and asked the chatbot living at the bottom right corner of the documentation page, which can answer lots of frequently asked questions.

this output is maybe more informative for debugging:
[rank0]: torch._dynamo.exc.TorchRuntimeError: Failed running call_function <built-in function getitem>(*(FakeTensor(..., device='xla:0', size=(1, s1, 24)), 1), **{}):
[rank0]: index 1 is out of bounds for dimension 0 with size 1

Hey @carlesoctav ! Thanks very much for this bug, we're landing multimodal model support for TPU in a month or so, so we'll check back on this bug when it's ready!!


Cannot read property 'default' of undefined

Since the @1.3.0 update we get this error:

Error location:

@pYr0x had this issue before and he thinks it had something to do with a export default in a module.
If I downgrade back to @1.2.2 the error is gone.

If we upgrade all our components to @1.3.0 the issue is resolved.
So, it only occurs when there is a mix of @1.2.2 and @1.3.0.


Update to pypi version

I noticed that this library hasn't been updated recently on pypi, when are you planning to release it?

+1

+1 really I need some of the features that are currently on master

I first installed this from pypi then got some error and though I have updated locally but once I install it using aws elastic beanstalk..the local changes to this plugin will be overwritten? How can I rectify this


Switch between collections

I have checked the following:

[X] I've searched existing issues and found nothing related to my issue.

Describe the feature you want to add
I'd like to switch between open collections.
I've 3 collections open, and it's awesome that the open requests belong to collection, but I'm not able to switch between the open collections.
I should be able to change either with ctrl+tab or simply left clicking the collection name.
Or am I wrong, and there is some way to do this?
Mockups or Images of the feature
Simply change to the collection when it is left-clicked.

Hey @AMetnik,
Thanks for the suggestion! It’s definitely a great feature to consider. At the moment, we're prioritizing our core product development, but we’re keeping this in mind as a potential future enhancement.

@AMetnik , @sreelakshmi-bruno, @helloanoop , just created PR #3395 that aims to cover this:


[iOS]App crashs immediately after launching

What happened?

Followed the environment and project setup step by step based on my project.
run case by execute: detox test -c ios.sim.debug  --record-logs all
but got  error info below:
Detox can't seem to connect to the test app(s)!
HINT:
The test app might have crashed prematurely, or has had trouble setting up the connection.

What was the expected behaviour?
the APP not crash right after launch and run the case accordingly
Was it tested on latest Detox?

[X] I have tested this issue on the latest Detox release and it still reproduces.

Did your test throw out a timeout?

[X] I have followed the instructions under Identifying which synchronization mechanism causes us to wait too much.

Help us reproduce this issue!
I tested based on my project.
In what environment did this happen?
Detox version: 20.22.2
React Native version: v0.63.3
Has Fabric (React Native's new rendering system) enabled: (yes/no)
Node version: 18.12.0 and 20.10.2 both encountered error
Device model: iPhone 14
iOS version: iOS 16.4
macOS version: 14.3.1
Xcode version: 15.2
Test-runner (select one): jest / other jest
Detox logs
Detox logs
[detox_output.log](https://github.com/wix/Detox/files/15430304/detox_output.log)
paste logs here!

Device logs
De
[detox.log](https://github.com/wix/Detox/files/15430308/detox.log)
vice logs
```
paste your device.log here!
```

More data, please!
No response

This issue just popped up in our repo as well last week. No code was changed from one day to the other and all of a sudden iOS started failing


[Feature] Remove project settings addons apply button

On the project settings page, under the checkbox list of addons, there existed an 'Apply' button which was inconvenient for users. This feature removes the apply button and updates the page when the checkboxes are clicked.
Jira ticket: https://openscience.atlassian.net/browse/OSF-5854
Before

After

Looks good.  Nice work @TomHeatwole  :tada:
RFM


Unexpected error: litellm.InternalServerError: AnthropicException - Overloaded

Issue
Aider v0.46.0
Models: claude-3-5-sonnet-20240620 with diff edit format, weak model claude-3-haiku-20240307
Git repo: .git with 280 files
Repo-map: using 1024 tokens
Use /help  for help, run "aider --help" to see cmd line args
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

/ask Tell me the key functionality of the code

Unexpected error: litellm.InternalServerError: AnthropicException - Overloaded. Handle with litellm.InternalServerError.
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/3.12/lib/python3.12/site-packages/litellm/utils.py", line 9950, in next
chunk = next(self.completion_stream)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Library/Frameworks/Python.framework/Versions/3.12/lib/python3.12/site-packages/litellm/llms/anthropic.py", line 1100, in next
return self.chunk_parser(chunk=data_json)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Library/Frameworks/Python.framework/Versions/3.12/lib/python3.12/site-packages/litellm/llms/anthropic.py", line 1060, in chunk_parser
raise AnthropicError(
litellm.llms.anthropic.AnthropicError: Overloaded
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/3.12/lib/python3.12/site-packages/aider/coders/base_coder.py", line 863, in send_new_user_message
yield from self.send(messages, functions=self.functions)
File "/Library/Frameworks/Python.framework/Versions/3.12/lib/python3.12/site-packages/aider/coders/base_coder.py", line 1124, in send
yield from self.show_send_output_stream(completion)
File "/Library/Frameworks/Python.framework/Versions/3.12/lib/python3.12/site-packages/aider/coders/base_coder.py", line 1198, in show_send_output_stream
for chunk in completion:
File "/Library/Frameworks/Python.framework/Versions/3.12/lib/python3.12/site-packages/litellm/utils.py", line 10025, in next
raise exception_type(
^^^^^^^^^^^^^^^
File "/Library/Frameworks/Python.framework/Versions/3.12/lib/python3.12/site-packages/litellm/utils.py", line 8034, in exception_type
raise e
File "/Library/Frameworks/Python.framework/Versions/3.12/lib/python3.12/site-packages/litellm/utils.py", line 6556, in exception_type
raise litellm.InternalServerError(
litellm.exceptions.InternalServerError: litellm.InternalServerError: AnthropicException - Overloaded. Handle with litellm.InternalServerError.
Version and model info
Aider v0.46.0
Models: claude-3-5-sonnet-20240620 with diff edit format, weak model claude-3-haiku-20240307
Git repo: .git with 280 files
Repo-map: using 1024 tokens

Thanks for trying aider and filing this issue.
That error means that Anthropic's API servers are overloaded. Best thing is to try again in a bit and see if they've recovered.

Great thanks

I think aider should somehow handle this exception, because now the user doesn't know what to do. I've just entered a request "please retry" and ai handled that fine. But before that I've searched the issues in this repo, so that indicates that some level of confusion is present ;) Cheers. I love the new /ask feature.

Good point. I've added litellm.InternalServerError to be retried with exponential backoff.
The change is available in the main branch. You can get it by installing the latest version from github:
python -m pip install --upgrade git+https://github.com/paul-gauthier/aider.git

If you have a chance to try it, let me know if it works better for you.

I'm on latest docker version (0.46 iirc), and I get the same "unexpected error" with same line numbers, and the same "During handling of the above exception, another exception occurred". Thank you @SupraSummus for the "please retry" hint, will try the retry next time :-)

Fyi, In latest version v0.46.2-dev (from dockerhub, pulled this afternoon, the smaller standard version for now), I still got a cutoff error, like this one:
Unexpected error: litellm.APIConnectionError: Response ended prematurely
Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/requests/models.py", line 820, in generate
    yield from self.raw.stream(chunk_size, decode_content=True)
  File "/usr/local/lib/python3.10/site-packages/urllib3/response.py", line 1057, in stream
    yield from self.read_chunked(amt, decode_content=decode_content)
  File "/usr/local/lib/python3.10/site-packages/urllib3/response.py", line 1206, in read_chunked
    self._update_chunk_length()
  File "/usr/local/lib/python3.10/site-packages/urllib3/response.py", line 1136, in _update_chunk_length
    raise ProtocolError("Response ended prematurely") from None
urllib3.exceptions.ProtocolError: Response ended prematurely

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/litellm/utils.py", line 9950, in __next__
    chunk = next(self.completion_stream)
  File "/usr/local/lib/python3.10/site-packages/litellm/llms/anthropic.py", line 1084, in __next__
    chunk = self.response_iterator.__next__()
  File "/usr/local/lib/python3.10/site-packages/requests/models.py", line 869, in iter_lines
    for chunk in self.iter_content(
  File "/usr/local/lib/python3.10/site-packages/requests/models.py", line 822, in generate
    raise ChunkedEncodingError(e)
requests.exceptions.ChunkedEncodingError: Response ended prematurely

Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/requests/models.py", line 820, in generate
    yield from self.raw.stream(chunk_size, decode_content=True)
  File "/usr/local/lib/python3.10/site-packages/urllib3/response.py", line 1057, in stream
    yield from self.read_chunked(amt, decode_content=decode_content)
  File "/usr/local/lib/python3.10/site-packages/urllib3/response.py", line 1206, in read_chunked
    self._update_chunk_length()
  File "/usr/local/lib/python3.10/site-packages/urllib3/response.py", line 1136, in _update_chunk_length
    raise ProtocolError("Response ended prematurely") from None
urllib3.exceptions.ProtocolError: Response ended prematurely

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/litellm/utils.py", line 9950, in __next__
    chunk = next(self.completion_stream)
  File "/usr/local/lib/python3.10/site-packages/litellm/llms/anthropic.py", line 1084, in __next__
    chunk = self.response_iterator.__next__()
  File "/usr/local/lib/python3.10/site-packages/requests/models.py", line 869, in iter_lines
    for chunk in self.iter_content(
  File "/usr/local/lib/python3.10/site-packages/requests/models.py", line 822, in generate
    raise ChunkedEncodingError(e)
requests.exceptions.ChunkedEncodingError: Response ended prematurely

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/aider/coders/base_coder.py", line 865, in send_new_user_message
    yield from self.send(messages, functions=self.functions)
  File "/usr/local/lib/python3.10/site-packages/aider/coders/base_coder.py", line 1126, in send
    yield from self.show_send_output_stream(completion)
  File "/usr/local/lib/python3.10/site-packages/aider/coders/base_coder.py", line 1200, in show_send_output_stream
    for chunk in completion:
  File "/usr/local/lib/python3.10/site-packages/litellm/utils.py", line 10025, in __next__
    raise exception_type(
  File "/usr/local/lib/python3.10/site-packages/litellm/utils.py", line 8034, in exception_type
    raise e
  File "/usr/local/lib/python3.10/site-packages/litellm/utils.py", line 7998, in exception_type
    raise APIConnectionError(
litellm.exceptions.APIConnectionError: litellm.APIConnectionError: Response ended prematurely
Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/requests/models.py", line 820, in generate
    yield from self.raw.stream(chunk_size, decode_content=True)
  File "/usr/local/lib/python3.10/site-packages/urllib3/response.py", line 1057, in stream
    yield from self.read_chunked(amt, decode_content=decode_content)
  File "/usr/local/lib/python3.10/site-packages/urllib3/response.py", line 1206, in read_chunked
    self._update_chunk_length()
  File "/usr/local/lib/python3.10/site-packages/urllib3/response.py", line 1136, in _update_chunk_length
    raise ProtocolError("Response ended prematurely") from None
urllib3.exceptions.ProtocolError: Response ended prematurely

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/litellm/utils.py", line 9950, in __next__
    chunk = next(self.completion_stream)
  File "/usr/local/lib/python3.10/site-packages/litellm/llms/anthropic.py", line 1084, in __next__
    chunk = self.response_iterator.__next__()
  File "/usr/local/lib/python3.10/site-packages/requests/models.py", line 869, in iter_lines
    for chunk in self.iter_content(
  File "/usr/local/lib/python3.10/site-packages/requests/models.py", line 822, in generate
    raise ChunkedEncodingError(e)
requests.exceptions.ChunkedEncodingError: Response ended prematurely

Also still got (with v0.47.2 docker full) the overload double-error:
Unexpected error: litellm.InternalServerError: AnthropicException - Overloaded. Handle with `litellm.InternalServerError`.
Traceback (most recent call last):
  File "/venv/lib/python3.10/site-packages/litellm/utils.py", line 9950, in __next__
    chunk = next(self.completion_stream)
  File "/venv/lib/python3.10/site-packages/litellm/llms/anthropic.py", line 1100, in __next__
    return self.chunk_parser(chunk=data_json)
  File "/venv/lib/python3.10/site-packages/litellm/llms/anthropic.py", line 1060, in chunk_parser
    raise AnthropicError(
litellm.llms.anthropic.AnthropicError: Overloaded

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/venv/lib/python3.10/site-packages/aider/coders/base_coder.py", line 865, in send_new_user_message
    yield from self.send(messages, functions=self.functions)
  File "/venv/lib/python3.10/site-packages/aider/coders/base_coder.py", line 1126, in send
    yield from self.show_send_output_stream(completion)
  File "/venv/lib/python3.10/site-packages/aider/coders/base_coder.py", line 1200, in show_send_output_stream
    for chunk in completion:
  File "/venv/lib/python3.10/site-packages/litellm/utils.py", line 10025, in __next__
    raise exception_type(
  File "/venv/lib/python3.10/site-packages/litellm/utils.py", line 8034, in exception_type
    raise e
  File "/venv/lib/python3.10/site-packages/litellm/utils.py", line 6556, in exception_type
    raise litellm.InternalServerError(
litellm.exceptions.InternalServerError: litellm.InternalServerError: AnthropicException - Overloaded. Handle with `litellm.InternalServerError`.

I found a bug in litellm which is causing this. I implemented a work around and reported it to them.
https://github.com/BerriAI/litellm/issues/5000
The change is available in the main branch. You can get it by installing the latest version from github:
python -m pip install --upgrade git+https://github.com/paul-gauthier/aider.git

If you have a chance to try it, let me know if it works better for you.

I'm going to close this issue for now, but feel free to add a comment here and I will re-open or file a new issue any time.

I've gotten this error a few times still, unfortunately:

Hi ! I've just installed the latest update and I'm also facing the same error, not sure if there is any way to fix it or if it is solely on Anthropic's side. It just started happening today, never seen this error before.

These errors are because Anthropic's API servers are overloaded/down. Aider is simply reporting that the server is broken.
Anthropic has been having serious issues since yesterday. You can directly check their server status here:
https://status.anthropic.com/

It might be worth linking to that status page in the error message @paul-gauthier


Added auto configuration to automatically publish on new pull request…

… merges to master
By creating this pull request you agree to the terms in CONTRIBUTING.md.
https://github.com/Infineon/.github/blob/master/CONTRIBUTING.md
--- DO NOT DELETE ANYTHING ABOVE THIS LINE ---
Add auto configuration

:rocket: PR was released in v1.0.3 :rocket:


Pronto-rubocop doesn't detect all violations

Hi Mindaugas.
From my understanding the following two commands executed on the same repo should produce the same output.
rubocop
pronto run -r rubocop
However, when I try with a dummy repo I get

Pronto is missing several violations, in particular violations such as

Method has too many lines. [12/5]
Literal true appeared in a condition.
Useless assignment to variable - h.
Redundant empty else-clause.

As you can see in both cases the same configuration file is used.
Am I missing something here?
Thanks

@sigfrid that would be true if you're running Prontoagainst all commits. By default, Pronto only diffs againstmaster. That means it only runs Rubocop against the code you see from git diff master`.
Does that help?

@mmozuras thanks for the explanation.
I see some issues with this, for instance let's say I have a  3 line long method in master and in my current branch the method becomes 20 line long. Since the method signature does not change the diff includes only the added body and Rubocop does not detect the method is too long as shown in my screenshot.
What do you think about?

@sigfrid that would require changes to both Rubocop and Pronto. It's useful and doable, but I don't expect to implement something similar in the very near future.

@mmozuras sure I don't expect you to implement it anytime soon, I'd like just to know if you agree with me on this or perhaps I'm missing something here.   Closing the issue.


moving private repo to official

This is working for very simple stuff. Could be used as beta in small projects until more tests are made.
Most work should be done I guess on

Schema resolving which is now relying still on Pulsars official library. However it could be useful to connect ObjectMapper from Micronaut into JSON resolver or create a custom schema that does it. Maybe creating custom schema resolver for all types? This is done quite poorly now in terms of features and flexibility. It's simple annotation to pulsar lib mapping just to get things going
Acknowledgement is automatic but could probably be beneficial to provide developers more flexibility like negativ ack in case of some errors.
Error handling and retries

@pgressa will be having a first pass review at this. Thanks for the PR

@pgressa will be having a first pass review at this. Thanks for the PR

Thanks for the reply, glad I could push some code here 👍

@harissecic hi thanks for updates! Let me get to it today or monday latest. Thanks for contribution!

@harissecic hi thanks for updates! Let me get to it today or monday latest. Thanks for contribution!

No problem, hope I get it good enough soon. I only need some replies and verification. I'm working on "Reader" annotation and other things but slowly due to full time job.
Thanks

@harissecic did you run gradle task spotlessJavaApply and checkstyleMain?

@harissecic did you run gradle task spotlessJavaApply and checkstyleMain?

Yes, I do it through WSL. Also that one cause major issues for me as I'm working on Windows. Each time I touched it on Windows directly it creates a havoc removing stuff from my files or breaking down on Unix style endlines which are demanded by your servers but for some reason problematic on Windows for spotless. And to top that Git by default on windows tries to replace \n with \r\n for local files but pushes \n. So it will take a while until I adjust it properly if possible at all. I assume it will not run build / it will fail if code is pushed and those test don't pass? That's what happened last time I forgot but now they're running

@harissecic let me check

@harissecic The first code quality reviews by @pgressa have been completed, I will be looking at this today or tomorrow to make other suggestions from an implementation point of view. Thanks

@harissecic Do you no longer wish to contribute this functionality? Sorry for the delay we have a lot going on however @burtbeckwith had this on his todo list to look at soon

@harissecic Do you no longer wish to contribute this functionality? Sorry for the delay we have a lot going on however @burtbeckwith had this on his todo list to look at soon

Sorry, renaming the repo on my side (was micronaut-pulsar-1 while my own repo was micronaut-pulsar), did some cleanup I'll reopen this one.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: harissecic:x: Haris SecicHaris Secic seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

@burtbeckwith @harissecic nice work guys, so this looks ready for initial merge? Thoughts?

@graemerocher I think so, it'll be more convenient to do the remaining work here. Could you add @harissecic as a contributor?

I invited @harissecic
@burtbeckwith feel free to merge whenever you are ready

Thanks @graemerocher  @burtbeckwith  - hope this gets some more attention and with it contributors.