feedback-to-code/mozzarella huggingface dataset:
Repository: bazelbuild/bazel
Issue: On Windows, genrule-setup.sh contains carriage returns
Labels: P1
area-Windows
untriaged
team-OSS

### Description of the problem / feature request:

On both a Linux and a Windows box, I have Bazel 0.17.2 installed. On the Linux system, the copy of `tools/genrule/genrule-setup.sh` is 858 bytes in size, whereas the copy shipped with the Windows version of Bazel is 882 bytes in size. The former uses NL, whereas the latter uses CR+NL.

Though `genrule-setup.sh` may contain CR+NL on Windows and work properly, the problem is that remote builds from Windows on a Linux cluster breaks as a result of it. Bash doesn't seem to like executing such files.

### Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

1. Create a [Buildbarn](https://github.com/EdSchouten/bazel-buildbarn) setup running on a pile of Linux servers.
2. Install Bazel on a Windows system.
3. Perform a build of a `genrule()` target against the Buildbarn setup, using flags along the lines of `--host_cpu=k8 --cpu=k8`.
4. Notice that targets will throw the following warnings during execution:

```
external/bazel_tools/tools/genrule/genrule-setup.sh: line 2: $'\r': command not found
external/bazel_tools/tools/genrule/genrule-setup.sh: line 16: $'\r': command not found
: invalid optionools/tools/genrule/genrule-setup.sh: line 18: set: -
set: usage: set [-abefhkmnptuvxBCHP] [-o option-name] [--] [arg ...]
external/bazel_tools/tools/genrule/genrule-setup.sh: line 19: $'\r': command not found
: invalid optionools/tools/genrule/genrule-setup.sh: line 21: set: -
set: usage: set [-abefhkmnptuvxBCHP] [-o option-name] [--] [arg ...]
external/bazel_tools/tools/genrule/genrule-setup.sh: line 22: $'\r': command not found
: invalid option nametools/genrule/genrule-setup.sh: line 24: set: pipefail
```

### What operating system are you running Bazel on?

Windows 10 1803.

### What's the output of `bazel info release`?

release 0.17.2

Installed it using Chocolatey.

###  Have you found anything relevant by searching the web?

No.

### Any other information, logs, or outputs that you want to share?

Maybe the artifacts that are shipped with Bazel and are used as input files should be marked as binary, so they are byte-for-byte identical between platforms?

Issue comments:
This can also be reproduced easily on a Linux system directly:

- Check out the Bazel source code.
- Change the line endings of `tools/genrule/genrule-setup.sh` to CRLF (e.g., using `:set ff=dos` in Vim and saving the file).
- Run it directly using Bash. It will print the same errors as shown above.

Pull request review comments:

Patch that resolved the issue:
diff --git a/.gitattributes b/.gitattributes
index c0f7b6a44d1b9c..35e4e72eeb31a1 100644
--- a/.gitattributes
+++ b/.gitattributes
@@ -1,3 +1,6 @@
 *.bzl linguist-language=Python
 BUILD linguist-language=Python
 site/* linguist-documentation
+
+# Files that should not use CRLF line endings, even on Windows.
+tools/genrule/genrule-setup.sh -text


Test patch:
Repository: bazelbuild/bazel
Issue: Release note generator should add contributors list
Labels: type: feature request
P2
area-EngProd
team-OSS

Currently, we're manually adding the list of contributors to thank to the release notes: we should instead be generating this.

Current script:
```
git log <previous version baseline>..<current version baseline> --format="%aN <%aE>" | sort | uniq | grep -v 'google\.com' | cut -d '<' -f 1
```

Issue comments:
A small enhancement: discovering the issue(s) the contributor's commit(s) closes, and linking to those issues too.

e.g.

```
This release contains contributions from many people at Google, as well as:

* Jane Doe: #1234 Fixes foo bug, #1235 Added bar feature
* John Doe: #1236 Improved baz performance
```
@jin Currently we're not linking individual contributors to single issues, just listing everyone who contributed. I'm not sure trying to do that is going to be useful in the release notes: anyone who is interested can check the Git history themselves.

Pull request review comments:

Patch that resolved the issue:
diff --git a/scripts/release/relnotes.sh b/scripts/release/relnotes.sh
index c1598c6f50aec6..6557cefe23c214 100755
--- a/scripts/release/relnotes.sh
+++ b/scripts/release/relnotes.sh
@@ -124,8 +124,9 @@ function __format_release_notes() {
 # Create the release notes since commit $1 ($2...${[#]} are the cherry-picks,
 # so the commits to ignore.
 function __release_notes() {
+  local last_release=$1
   local i
-  local commits=$(__get_release_notes_commits $@)
+  local commits=$(__get_release_notes_commits $last_release)
   local length="${#RELNOTES_TYPES[@]}"
   __generate_release_notes "$commits"
   for (( i=0; $i < $length; i=$i+1 )); do
@@ -140,6 +141,17 @@ function __release_notes() {
       echo
     fi
   done
+
+  # Add a list of contributors to thank.
+  local external_authors=$(git log $last_release..HEAD --format="%aN <%aE>" \
+    | sort \
+    | uniq \
+    | grep -v "google.com" \
+    | sed -e 's/[[:space:]]$//' \
+    | tr '\n' ',' \
+    | sed -e 's/,$/\n/' \
+    | sed -e 's/,/, /g')
+  echo "This release contains contributions from many people at Google, as well as ${external_authors}."
 }
 
 # A wrapper around all the previous function, using the CHANGELOG.md


Test patch:
Repository: bazelbuild/bazel
Issue: Broken formatting for packaging rules
Labels: type: bug
type: documentation (cleanup)
P1
team-Bazel

See [packaging rules docs](https://docs.bazel.build/versions/master/be/pkg.html#pkg_tar).

Formatting is very broken, tables render correctly but headers do not, italics start and stop at various places.
![packaging_rules_formatting](https://user-images.githubusercontent.com/326527/48152495-14fc9400-e292-11e8-8994-1637a0ceb793.png)


Issue comments:
@laurentlb, is this possibly related to ea4840042b0c087685ab4faffab58ba6906b06f5?
Testing locally, the docs render correctly.
Actually, no, they just break differently. Still investigating.
There are two issues, I think.

- The HTML is broken. I'm fixing it. With the fix, page should render correctly when testing locally.
- Syntax highlighting is broken on the site since my update. I suspect we need to update Jekyll or Rouge (cc @philwo).
Now that 4616fdd0e2f567ae2395803e4404054a79787b22 is in, should I close this, or keep it open and re-assign for the syntax highlighting part?
Asking @laurentlb whether to keep this open or not.
Note that all multi-line code blocks are also broken currently, on the website itself:
https://docs.bazel.build/versions/master/skylark/aspects.html
Documentation using multi-line code blocks are severely broken (https://docs.bazel.build/versions/master/android-instrumentation-test.html), I will submit a rollback to use redcarpet first. 
The rollback (rollforward?) worked. Closing this for now.

Pull request review comments:

Patch that resolved the issue:
diff --git a/tools/build_defs/pkg/README.md b/tools/build_defs/pkg/README.md
index b1b962fc42136b..445e38602f82c5 100644
--- a/tools/build_defs/pkg/README.md
+++ b/tools/build_defs/pkg/README.md
@@ -118,7 +118,7 @@ Creates a tar file from a list of inputs.
         <code>String, default to 'tar'</code>
         <p>
             The extension for the resulting tarball. The output
-            file will be '<i>name<i>.<i>extension<i>'. This extension
+            file will be '<i>name</i>.<i>extension</i>'. This extension
             also decide on the compression: if set to <code>tar.gz</code>
             or <code>tgz</code> then gzip compression will be used and
             if set to <code>tar.bz2</code> or <code>tar.bzip2</code> then
@@ -284,7 +284,6 @@ Creates a tar file from a list of inputs.
       </td>
     </tr>
   </tbody>
-  </tbody>
 </table>
 
 <a name="pkg_deb"></a>
@@ -448,7 +447,6 @@ for more details on this.
       </td>
     </tr>
   </tbody>
-  </tbody>
 </table>
 
 <a name="pkg_rpm"></a>
@@ -517,5 +515,4 @@ for more details on this.
       </td>
     </tr>
   </tbody>
-  </tbody>
 </table>


Test patch:
Repository: bazelbuild/bazel
Issue: Document the build processes of the Bazel websites
Labels: type: documentation (cleanup)
P2
team-Bazel

This impacts {www, docs, blog}.bazel.build.

The three web assets share a significant part of their build processes. These processes are lightly documented in the [READMEs](https://github.com/bazelbuild/bazel-website#bazel-website) or in code themselves.

It would be useful to document how the Bazel web assets are built and deployed, and identify areas where we can decouple and reuse commonly shared libraries, like CSS, JS, and header/footer/layout includes.

Issue comments:
Closing this as a dupe of https://github.com/bazelbuild/bazel/issues/1707

Pull request review comments:

Patch that resolved the issue:
diff --git a/scripts/docs/doc_versions.bzl b/scripts/docs/doc_versions.bzl
index 4e4b76a5ffc52e..09f2c80aacfdd9 100644
--- a/scripts/docs/doc_versions.bzl
+++ b/scripts/docs/doc_versions.bzl
@@ -22,6 +22,10 @@
 """This module contains the versions and hashes of Bazel's documentation tarballs."""
 
 DOC_VERSIONS = [
+    {
+        "version": "0.21.0",
+        "sha256": "23ec39c0138d358c544151e5c81586716d5d1c6124f10a742bead70516e6eb93",
+    },
     {
         "version": "0.20.0",
         "sha256": "bb79a63810bf1b0aa1f89bd3bbbeb4a547a30ab9af70c9be656cc6866f4b015b",
diff --git a/site/_config.yml b/site/_config.yml
index 00f82998f49c69..9e82fe02e149d8 100644
--- a/site/_config.yml
+++ b/site/_config.yml
@@ -15,6 +15,7 @@ version: "master"
 # This must be kept in sync with //site/script/docs:versions.bzl
 doc_versions:
   - master
+  - 0.21.0
   - 0.20.0
   - 0.19.2
   - 0.19.1


Test patch:
Repository: bazelbuild/bazel
Issue: Starlark language docs link to list instead of tuple
Labels: type: documentation (cleanup)
P3

On https://docs.bazel.build/versions/master/skylark/lib/string.html#endswith the link to "tuple" in "tuple of strings" actually points at the list documentation. Which then gave me a syntax error because I needed the "tuple" syntax with parentheses instead of square brackets. I'm also not sure where this documentation lives in Github... presumably it's autogenerated, and therefore this problem might affect other documentation pages?

Issue comments:

Pull request review comments:

Patch that resolved the issue:
diff --git a/src/main/java/com/google/devtools/build/docgen/skylark/SkylarkDoc.java b/src/main/java/com/google/devtools/build/docgen/skylark/SkylarkDoc.java
index 95f740e002ee79..f2a38819fa84d0 100644
--- a/src/main/java/com/google/devtools/build/docgen/skylark/SkylarkDoc.java
+++ b/src/main/java/com/google/devtools/build/docgen/skylark/SkylarkDoc.java
@@ -61,7 +61,7 @@ protected String getTypeAnchor(Class<?> type) {
     } else if (Map.class.isAssignableFrom(type)) {
       return "<a class=\"anchor\" href=\"dict.html\">dict</a>";
     } else if (type.equals(Tuple.class)) {
-      return "<a class=\"anchor\" href=\"list.html\">tuple</a>";
+      return "<a class=\"anchor\" href=\"tuple.html\">tuple</a>";
     } else if (type.equals(MutableList.class) || type.equals(ImmutableList.class)) {
       return "<a class=\"anchor\" href=\"list.html\">list</a>";
     } else if (type.equals(SkylarkList.class)) {


Test patch:
diff --git a/src/test/java/com/google/devtools/build/docgen/SkylarkDocumentationTest.java b/src/test/java/com/google/devtools/build/docgen/SkylarkDocumentationTest.java
index 07c684f73d714c..7796c5d8cbdb23 100644
--- a/src/test/java/com/google/devtools/build/docgen/SkylarkDocumentationTest.java
+++ b/src/test/java/com/google/devtools/build/docgen/SkylarkDocumentationTest.java
@@ -442,7 +442,7 @@ public void testSkylarkContainerReturnTypesWithoutAnnotations() throws Exception
                 + "MockClassWithContainerReturnValues.depset()");
     assertThat(signatures)
     .contains(
-        "<a class=\"anchor\" href=\"list.html\">tuple</a> "
+        "<a class=\"anchor\" href=\"tuple.html\">tuple</a> "
             + "MockClassWithContainerReturnValues.tuple()");
     assertThat(signatures)
         .contains(
Repository: bazelbuild/bazel
Issue: //scripts/packages:without-jdk/bazel includes a jdk
Labels: P2
area-EngProd
team-Rules-Java
team-OSS

`//scripts/packages:rename-bazel-bin-without-jdk`, which produces `//scripts/packages:without-jdk/bazel` includes `//src:bazel`[0], which due to semi-recent changes, now **includes** a jdk. It should be changed to `//src:bazel_nojdk` to support generating a bazel.sh without an embedded JDK. This change seems to have been missed by 7c49bd9c73385db84e678469aa7e6a5bb801c28a 

[0] As of c67dceca77a93646961fc4bb863826e344fda5e0

Issue comments:
cc @meisterT 

Pull request review comments:

Patch that resolved the issue:
diff --git a/scripts/packages/BUILD b/scripts/packages/BUILD
index 5a66400d1f440c..7e9ec210b2578e 100644
--- a/scripts/packages/BUILD
+++ b/scripts/packages/BUILD
@@ -93,7 +93,7 @@ genrule(
 
 genrule(
     name = "rename-bazel-bin-without-jdk",
-    srcs = ["//src:bazel"],
+    srcs = ["//src:bazel_nojdk"],
     outs = ["without-jdk/bazel-real"],
     cmd = "mkdir -p $$(dirname $@); cp $< $@",
 )


Test patch:
Repository: bazelbuild/bazel
Issue: remote: update grpc and google auth library to latest
Labels: P2
type: process
team-Remote-Exec


Issue comments:
I need this for properly fixing #6400 (support for grpc.enable_http_proxy channel arg was added in gRPC 1.14).
@tetromino this is about the gRPC Java dependency. I believe you need https://github.com/bazelbuild/bazel/issues/2804
The Google auth library in third_party/auth is quite old.  It did not work with my company's proxy to GCS when I tried to use a GCS bucket as a remote cache.  It needs to be updated.

See https://github.com/bazelbuild/bazel/pull/8017

Pull request review comments:

Patch that resolved the issue:
diff --git a/third_party/BUILD b/third_party/BUILD
index c927b759969b42..90ab565687731f 100644
--- a/third_party/BUILD
+++ b/third_party/BUILD
@@ -226,8 +226,8 @@ java_import(
 java_import(
     name = "auth",
     jars = [
-        "auth/google-auth-library-oauth2-http-0.6.0.jar",
-        "auth/google-auth-library-credentials-0.6.0.jar",
+        "auth/google-auth-library-oauth2-http-0.15.0.jar",
+        "auth/google-auth-library-credentials-0.15.0.jar",
     ],
     runtime_deps = [
         ":api_client",


Test patch:
Repository: bazelbuild/bazel
Issue: Windows, java_binary: MakeDirectoriesW fail in launcher
Labels: type: bug
P1
area-Windows
team-OSS

### Description of the problem / feature request:

If you copy a java_binary's outputs somewhere out of bazel-bin and try to run it from the current working directory, the launcher will fail with a MakeDirectoriesW error.

BUILD:
```
java_binary(
  name = "foo",
  srcs = ["Main.java"],
  main_class = "Main",
)
```

Main.java
```
public class Main {
  public static void main(String[] args) {
    System.out.println("helloworld");
  }
}
```

Then copy `bazel-bin\foo.exe`, `bazel-bin\foo.exe.runfiles_manifest`, and `bazel-bin\foo.jar` into `c:\tmp1\launcher_test`, and run foo.exe:

```
C:\tmp1\launcher_test>foo.exe --classpath_limit=0  --print_launcher_command
FATAL: MakeDirectoriesW(foo.exe.j) could not find dirname: (error: 2): The system cannot find the file specified.
```

### What operating system are you running Bazel on?

Windows 10

### What's the output of `bazel info release`?

0.22.0

Issue comments:

Pull request review comments:
when does this happen?
If `path` itself was empty.
Shall I move this check above the conversion?
Yes please.
Done.

Patch that resolved the issue:
diff --git a/src/main/cpp/util/file_windows.cc b/src/main/cpp/util/file_windows.cc
index cc2225ed37ae72..a71db514216aca 100644
--- a/src/main/cpp/util/file_windows.cc
+++ b/src/main/cpp/util/file_windows.cc
@@ -755,22 +755,28 @@ void SyncFile(const string& path) {
 }
 
 bool MakeDirectoriesW(const wstring& path, unsigned int mode) {
-  if (path.empty()) {
+  std::wstring abs_path;
+  std::string error;
+  if (abs_path.empty()) {
     return false;
   }
-  if (IsRootDirectoryW(path) || IsDirectoryW(path)) {
+  if (!AsAbsoluteWindowsPath(path, &abs_path, &error)) {
+    BAZEL_DIE(blaze_exit_code::LOCAL_ENVIRONMENTAL_ERROR) << "MakeDirectoriesW("
+        << blaze_util::WstringToString(path) << "): " << error;
+  }
+  if (IsRootDirectoryW(abs_path) || IsDirectoryW(abs_path)) {
     return true;
   }
-  wstring parent = SplitPathW(path).first;
+  wstring parent = SplitPathW(abs_path).first;
   if (parent.empty()) {
-    // Since `path` is not a root directory, there should have been at least one
-    // directory above it.
+    // Since `abs_path` is not a root directory, there should have been at least
+    // one directory above it.
     BAZEL_DIE(blaze_exit_code::LOCAL_ENVIRONMENTAL_ERROR)
-        << "MakeDirectoriesW(" << blaze_util::WstringToString(path)
+        << "MakeDirectoriesW(" << blaze_util::WstringToString(abs_path)
         << ") could not find dirname: " << GetLastErrorString();
   }
   return MakeDirectoriesW(parent, mode) &&
-         ::CreateDirectoryW(path.c_str(), NULL) == TRUE;
+         ::CreateDirectoryW(abs_path.c_str(), NULL) == TRUE;
 }
 
 bool MakeDirectories(const string& path, unsigned int mode) {


Test patch:
Repository: bazelbuild/bazel
Issue: incompatible_java_coverage: allow coverage collection for JVM languages
Labels: incompatible-change

The option `--incompatible_java_coverage`:

- makes possible collecting coverage for Starlark JVM languages and jars imported with `java_import`
- only includes JVM files in the coverage report (dismisses data files, for example `.js` files that shouldn't have been in the report in the first place)
- the report includes the actual path of the files relative to the workspace root instead of the package path (e.g. `src/com/google/Action.java` instead of `com/google/Action.java`). This allows `genhtml` to generate HTML reports from the combined bazel coverage output.

For more details see [Bazel coverage for JVM languages](https://docs.google.com/document/d/1mQLQa2uMIgVcwTE-hwaKgwQ5upExIRH5p9lHFyxhj4g/edit?usp=sharing).

# Migration Notes

The users do not have to do any migration. Having the package paths in the report was filed as a bug (see #2528).


Issue comments:

Pull request review comments:

Patch that resolved the issue:
diff --git a/src/main/java/com/google/devtools/build/lib/analysis/config/BuildConfiguration.java b/src/main/java/com/google/devtools/build/lib/analysis/config/BuildConfiguration.java
index 4347d97681d619..0732a81409504f 100644
--- a/src/main/java/com/google/devtools/build/lib/analysis/config/BuildConfiguration.java
+++ b/src/main/java/com/google/devtools/build/lib/analysis/config/BuildConfiguration.java
@@ -589,7 +589,7 @@ public static class Options extends FragmentOptions implements Cloneable {
 
     @Option(
         name = "incompatible_java_coverage",
-        defaultValue = "false",
+        defaultValue = "true",
         documentationCategory = OptionDocumentationCategory.OUTPUT_PARAMETERS,
         effectTags = {OptionEffectTag.AFFECTS_OUTPUTS},
         metadataTags = {


Test patch:
Repository: bazelbuild/bazel
Issue: Windows: Bazel binary has no icon
Labels: type: bug
P4
area-Windows
team-OSS

### Description of the problem / feature request:

Regression from earlier versions.
The Bazel binary no longer has an icon on Windows.

See message thread: https://github.com/bazelbuild/bazel/commit/f8128c3ce2160e5d6243a2dfd94b399d11ee282e


### What operating system are you running Bazel on?

Windows 10

### What's the output of `bazel info release`?

0.24.0

Issue comments:

Pull request review comments:

Patch that resolved the issue:
diff --git a/src/main/cpp/BUILD b/src/main/cpp/BUILD
index 483df2cd70925f..fea97a8d6b7014 100644
--- a/src/main/cpp/BUILD
+++ b/src/main/cpp/BUILD
@@ -79,7 +79,7 @@ cc_binary(
         "global_variables.h",
         "main.cc",
     ] + select({
-        "//src/conditions:windows": ["//src/main/native/windows:resources"],
+        "//src/conditions:windows": ["resources.o"],
         "//conditions:default": [],
     }),
     copts = select({
diff --git a/src/main/native/windows/BUILD b/src/main/native/windows/BUILD
index 8567b35b2e861b..e1e14249107d8f 100644
--- a/src/main/native/windows/BUILD
+++ b/src/main/native/windows/BUILD
@@ -78,14 +78,6 @@ cc_binary(
     ],
 )
 
-# Directly re-export resources.o so it can be consumed in the client.
-cc_library(
-    name = "resources",
-    srcs = ["resources.o"],
-    linkstatic = 1,
-    visibility = ["//src/main/cpp:__pkg__"],
-)
-
 filegroup(
     name = "embedded_java_tools",
     srcs = [


Test patch:
Repository: bazelbuild/bazel
Issue: incompatible_use_native_patch: Use native patch in http_archive and git_repository rules
Labels: type: feature request
P1
area-Windows
team-OSS

# Description
Bazel's [repository rules](https://github.com/bazelbuild/bazel/tree/master/tools/build_defs/repo) depends on `patch` and bash tools on all platforms. This requires users to install MSYS2 on Windows. We need to break the bash dependency from repository rule.

To break the dependency on the patch command line tool from repository rules, we implement patch in Bazel-native code and expose `repository_ctx.patch` API. Repository rules can use this API to apply patch file, but at the same time, we also allow fallback to patch command line tool in `http_archive` and `git_repository` rules.

Documentation: https://docs.bazel.build/versions/master/repo/http.html

A subtask of https://github.com/bazelbuild/bazel/issues/4319

# Migration plan
If your project is broken by this flag, it's probably because you're trying to apply an inaccurate patch file. To migrate your project, there are two ways:

- Fix your patch file to match the exact content you want to patch.
- Specify `patch_tool` attribute to `patch` (or a path to the patch tool you want to use), Bazel will fall back to use the patch command line tool instead of the native patch. But in this case, please make sure you have `patch` in PATH (or exist at the path you specified).

# Rollout plan

- Bazel 0.29.0 is expected to support this flag, with default value being false.
- Bazel 1.0 is expected to support this flag, with default value being true.

Issue comments:
Since this is Windows-specific and @meteorcloudy is in the Windows subteam, can we label this as "team-Windows"?
This is not entirely Windows specific, we will also enable native patch on other platforms. But since we are doing the work, I don't mind labeling it as "team-Windows"
Is this on track for 1.0?
Yes, waiting to be released in 0.29, then we can try to flip this flag. Will be default in 1.0.

Pull request review comments:

Patch that resolved the issue:
diff --git a/src/main/java/com/google/devtools/build/lib/bazel/repository/RepositoryOptions.java b/src/main/java/com/google/devtools/build/lib/bazel/repository/RepositoryOptions.java
index 8081d54484d4bc..ce2ad4afdabd76 100644
--- a/src/main/java/com/google/devtools/build/lib/bazel/repository/RepositoryOptions.java
+++ b/src/main/java/com/google/devtools/build/lib/bazel/repository/RepositoryOptions.java
@@ -135,7 +135,7 @@ public class RepositoryOptions extends OptionsBase {
 
   @Option(
       name = "incompatible_use_native_patch",
-      defaultValue = "false",
+      defaultValue = "true",
       documentationCategory = OptionDocumentationCategory.UNCATEGORIZED,
       effectTags = {OptionEffectTag.LOADING_AND_ANALYSIS},
       metadataTags = {


Test patch: