1252798 - mach file-info gives bogus "Please define JAR_MANIFESTS" error when JAR_MANIFESTS is defined

Status: RESOLVED DUPLICATE of bug 1203266

(Firefox Build System :: General, defect)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

In my sourcedir, I get the following error, which seems bogus since there *is* a JAR_MANIFESTS line pointing to the jar.mn!

Maybe related to bug 1241421?


$ ./mach file-info bugzilla-component layout/style/nsCSSRuleProcessor.cpp 
Error running mach:

    ['file-info', 'bugzilla-component', 'layout/style/nsCSSRuleProcessor.cpp']

The error occurred in code that was called by the mach command. This is either
a bug in the called code itself or in the way that mach is calling it.

You should consider filing a bug for this issue.

If filing a bug, please include the full output of mach, including this error
message.

The details of the failure are as follows:

SandboxValidationError: 
==============================
ERROR PROCESSING MOZBUILD FILE
==============================

The error occurred while processing the following file or one of the files it includes:

    /hdd/builds/build-mozilla-central/mozilla/layout/style/moz.build

The error occurred when validating the result of the execution. The reported error is:

    A jar.mn exists but it is not referenced in the moz.build file. Please define JAR_MANIFESTS.



  File "/hdd/builds/build-mozilla-central/mozilla/python/mozbuild/mozbuild/frontend/mach_commands.py", line 108, in file_info_bugzilla
    for p, m in self._get_files_info(paths, rev=rev).items():
  File "/hdd/builds/build-mozilla-central/mozilla/python/mozbuild/mozbuild/frontend/mach_commands.py", line 218, in _get_files_info
    return reader.files_info(allpaths)
  File "/hdd/builds/build-mozilla-central/mozilla/python/mozbuild/mozbuild/frontend/reader.py", line 1374, in files_info
    flags += test_ctx_reader.test_defaults_for_path(path, ctxs)
  File "/hdd/builds/build-mozilla-central/mozilla/python/mozbuild/mozbuild/frontend/reader.py", line 1422, in test_defaults_for_path
    for obj in emitter.emit_from_context(test_context):
  File "/hdd/builds/build-mozilla-central/mozilla/python/mozbuild/mozbuild/frontend/emitter.py", line 907, in emit_from_context
    for obj in self._process_jar_manifests(context):
  File "/hdd/builds/build-mozilla-central/mozilla/python/mozbuild/mozbuild/frontend/emitter.py", line 1323, in _process_jar_manifests
    'Please define JAR_MANIFESTS.', context)

Comment 1

[Gregory Szorc [:gps]]

This is related to bug 1203266.

Basically, as part of trying to resolve tests metadata we feed an empty Context into the emitter and the emitter is complaining that there is a jar.mn file without the JAR_MANIFESTS entry. I have a feeling the easiest solution for this is a dirty hack...

Comment 2

[Gregory Szorc [:gps]]

Attachment: MozReview Request: Bug 1252798 - Add a hack to stop processing after test manifests are read; r?chmanchester

This is a hack. The tests manifests should be readable in the reader
layer. But we have this nasty interplay between the reader and emitter
causing all kinds of pain. See also bug 1203266.

Review commit: https://reviewboard.mozilla.org/r/37665/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/37665/

Comment 3

[Chris Manchester (limited bugmail, email directly)]

Comment on attachment 8725829 [details]
MozReview Request: Bug 1252798 - Add a hack to stop processing after test manifests are read; r?chmanchester

https://reviewboard.mozilla.org/r/37665/#review34225

Can we just land bug 1203266 ? We were considering it blocked on packaging all the test manifest parsers (bug 1215709), but now that I think about it hg mozbuildinfo is already using files_info (which ends up running the emitter to read test manifests anyway), so it wouldn't be a regression.

Comment 4

[Chris Manchester (limited bugmail, email directly)]

https://reviewboard.mozilla.org/r/37665/#review34225

As discussed on irc, hg mozbuildinfo appears to be avoiding this because it's using a version of the mozbuild package before bug 1184405 introduced the idea of files_info reading test manifests. 

I rebased bug 1203266, and it fixes this problem, so I'll re-request review there shortly. I don't really mind landing this hack if it comes with a regression test and a FIXME comment explaining the situation.