tests: add a substitution pattern for dates in HTTP headers and LFS payload This will be useful when printing HTTP headers and JSON payload received from an LFS server. The RFC 1123 date masking has uses elsewhere too.

xdiff: fix a hard crash on Windows The xdiff case of test-diff-antipatience.t started crashing in the C extension with 882657a9f768 (with 6a71a5ba666b backported so it compiles). There are a few more instances of 'long', but this resolves the crashing.

templater: split template functions to new module It has grown enough to be a dedicated module.

templater: move hybrid class and functions to templateutil module And make _hybrid and _mappable classes public. _showlist() is still marked as private since it's weird and third-party codes shouldn't depend on it.

templater: move stringify() to templateutil module As we have a util module, it doesn't make sense to import stringify() from templatefilters.py.

dagop: move lines() out of annotate()

dagop: extract core algorithm of annotate() from context.py See the previous patch for why.

dagop: move annotateline and _annotatepair from context.py The annotate logic is large. Let's move it out of the context module, which is basically an abstraction layer of repository operations.

bdiff: convert more longs to int64_t MSVC previously flagged these where the function is stored in a pointer: bdiff.c(284) : warning C4028: formal parameter 1 different from declaration bdiff.c(284) : warning C4028: formal parameter 2 different from declaration bdiff.c(284) : warning C4028: formal parameter 3 different from declaration bdiff.c(284) : warning C4028: formal parameter 4 different from declaration

xdiff: silence a 32-bit shift warning on Windows It's probably harmless, but: warning C4334: '<<' : result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) Adding a 'ULL' suffix to 1 also works, but I doubt that's portable.

xdiff: backport int64_t and uint64_t types to Windows Sadly, MSVC 2008 lacks stdint.h. These are the only two definitions needed right now.

templater: extract template evaluation utility to new module Prepares for splitting template functions to new module. All eval* functions were moved to templateutil.py, and run* functions had to be moved as well due to the dependency from eval*s. eval*s were aliased as they are commonly used in codebase. _getdictitem() had to be made public.

templater: move function table to the "context" object Prepares for splitting template functions from templater.py.

hgweb: remove wsgirequest (API) Good riddance. .. api:: The old ``wsgirequest`` class for handling everything WSGI in hgweb has been replaced by separate request and response types. Various high-level functions in the hgweb WSGI applications now receive these new types as arguments instead of the old ``wsgirequest`` type. Differential Revision: https://phab.mercurial-scm.org/D2832

tweakdefaults: add commands.status.verbose to tweakefaults commands.status,verbose if set to True, shows conflict information in `hg status`. It shows which unresolved state you are in, which are the unresolved files and how to continue the unresolved state. That sounds like a very good candidate for tweakdefaults. bisect is added to commands.status.skipstates because people generally leave unresolved bisect state and we should skip that in morestatus output. Differential Revision: https://phab.mercurial-scm.org/D2806

hgweb: store the raw WSGI environment dict We need this so we can construct a new request instance from the original dict. Differential Revision: https://phab.mercurial-scm.org/D2831

hgweb: remove dead wsgirequest code All responses now go through our modern response type. All code related to response handling can be deleted. Differential Revision: https://phab.mercurial-scm.org/D2830

hgweb: port to new response API These were the last consumers of wsgirequest.respond() \o/ Differential Revision: https://phab.mercurial-scm.org/D2829

hgweb: pass modern request type into templater() Only a handful of consumers of wsgirequest remaining in this file... Differential Revision: https://phab.mercurial-scm.org/D2828

hgweb: use modern response type for index generation Differential Revision: https://phab.mercurial-scm.org/D2827

hgweb: don't pass wsgireq to makeindex and other functions We only ever access attributes that are available on our newer request type. So we no longer need this argument. Differential Revision: https://phab.mercurial-scm.org/D2826

hgweb: replace PATH_INFO with dispatchpath This was the last consumer of wsgireq.env from our WSGI applications! (Although indirect consumers of this attribute exist in wsgirequest.respond().) Differential Revision: https://phab.mercurial-scm.org/D2825

hgweb: rewrite path generation for index entries I think this code is easier to read. But the real reason to do this is to eliminate a consumer of wsgirequest. Differential Revision: https://phab.mercurial-scm.org/D2824

hgweb: construct {url} with req.apppath This is how the hgweb WSGI application does it. Let's make the behavior consistent. Differential Revision: https://phab.mercurial-scm.org/D2823

hgweb: support constructing URLs from an alternate base URL The web.baseurl config option allows server operators to define a custom URL for hosted content. The way it works today is that hgwebdir parses this config option into URL components then updates the appropriate WSGI environment variables so the request "lies" about its details. For example, SERVER_NAME is updated to reflect the alternate base URL's hostname. The WSGI environment should not be modified because WSGI applications may want to know the original request details (for debugging, etc). This commit teaches our request parser about the existence of an alternate base URL. If defined, the advertised URL and other self-reflected paths will take the alternate base URL into account. The hgweb WSGI application didn't use web.baseurl. But hgwebdir did. We update hgwebdir to alter the environment parsing accordingly. The old code around environment manipulation has been removed. With this change, parserequestfromenv() has grown to a bit unwieldy. Now that practically everyone is using it, it is obvious that there is some unused features that can be trimmed. So look for this in follow-up commits. Differential Revision: https://phab.mercurial-scm.org/D2822

hgweb: clarify that apppath begins with a forward slash Differential Revision: https://phab.mercurial-scm.org/D2821

hgweb: change how dispatch path is reported When I implemented the new request object, I carried forward some ugly hacks until I could figure out what was happening. One of those was the handling of PATH_INFO to determine how to route hgweb requests. Essentially, if we have PATH_INFO data, we route according to that. But if we don't, we route by the query string. I question if we still need to support query string routing. But that's for another day, I suppose. In this commit, we clean up the ugly "havepathinfo" hack and replace it with a "dispatchpath" attribute that can hold None or empty string to differentiate between the presence of PATH_INFO. This is still a bit hacky. But at least the request parsing and routing code is explicit about the meaning now. Differential Revision: https://phab.mercurial-scm.org/D2820

hgweb: refactor repository name URL parsing The hgwebdir WSGI application detects when a requested URL is for a known repository and it effectively forwards the request to the hgweb WSGI application. The hgweb WSGI application needs to route the request based on the base URL for the repository. The way this normally works is SCRIPT_NAME is used to resolve the base URL and PATH_INFO contains the path after the script. But with hgwebdir, SCRIPT_NAME refers to hgwebdir, not the base URL for the repository. So, there was a hacky REPO_NAME environment variable being set to convey the part of the URL that represented the repository so hgweb could ignore this path component for routing purposes. The use of the environment variable for passing internal state is pretty hacky. Plus, it wasn't clear from the perspective of the URL parsing code what was going on. This commit improves matters by making the repository name an explicit argument to the request parser. The logic around handling of this value has been shored up. We add various checks that the argument is used properly - that the repository name does represent the prefix of the PATH_INFO. Differential Revision: https://phab.mercurial-scm.org/D2819

tests: add test coverage for parsing WSGI requests A subsequent commit will need to make this code more complicated in order to support alternate base URLs. Let's establish some test coverage before we diverge too far from PEP 3333. As part of this, a minor bug related to a missing SCRIPT_NAME key has been squashed. Differential Revision: https://phab.mercurial-scm.org/D2818

hgweb: construct static URL like hgweb does hgwebdir has a bit of code for constructing URLs. This reinvents wheels from our parsedrequest instance. And sometimes the behavior varies from what hgweb does. We'll want to converge that behavior. This commit changes hgwebdir so its staticurl template keyword is constructed the same way as hgweb's. There's probably room to factor this into a shared function. But let's solve the problem of divergence first. Differential Revision: https://phab.mercurial-scm.org/D2817

hgweb: remove unused **map argument It was unused before the recent code refactoring AFAICT. Differential Revision: https://phab.mercurial-scm.org/D2816

hgweb: extract entries() to standalone function There was some real wonkiness going on here. Essentially, the inline function was being executed with default arguments because a function reference was passed as-is into the templater. That seemed odd. So now we pass an explicit generator of the function result. Moving this code out of makeindex() makes makeindex() small enough to reason about. This makes it easier to see weird things, like the fact that we're calling self.refresh() twice. Why, I'm not sure. I'm also not sure why we need to call updatereqenv() to possibly update the SERVER_NAME, SERVER_PORT, and SCRIPT_NAME variables as part of rendering an index. I'll dig into these things in subsequent commits. Differential Revision: https://phab.mercurial-scm.org/D2815

hgweb: move rawentries() to a standalone function It was only accessing a few variables from the outer scope. Let's make it standalone so there is better clarity about what the inputs are. Differential Revision: https://phab.mercurial-scm.org/D2814

hgweb: move archivelist to standalone function This doesn't need to exist as an inline function in a method. Minor formatting changes were made as part of the move. Differential Revision: https://phab.mercurial-scm.org/D2813

hgweb: move readallowed to a standalone function hgwebdir s kind of large. Let's make the class smaller by moving things that don't need to be there. Differential Revision: https://phab.mercurial-scm.org/D2812

hgweb: remove some use of wsgireq in hgwebdir While we're here, rename a method so abide by our style policy, since otherwise check-commit would complain. Differential Revision: https://phab.mercurial-scm.org/D2805

hgweb: fix a bug due to variable name typo It looks like the "sort" query string parameter was not being honored properly. Differential Revision: https://phab.mercurial-scm.org/D2804

hgweb: stop passing req and tmpl into @webcommand functions (API) We have effectively removed all consumers of the old wsgirequest type. The templater can be accessed on the requestcontext passed into the @webcommand function. For the most part, these arguments are unused. They only exist to provide backwards compatibility. And in the case of wsgirequest, use of that object could actively interfere with the new request object. So let's stop passing these objects to @webcommand functions. With this commit, wsgirequest is practically dead from the hgweb WSGI application. There are still some uses in hgwebdir though... .. api:: @webcommand functions now only receive a single argument. The request and templater instances can be accessed via the ``req`` and ``templater`` attributes of the first argument. Note that the request object is different from previous Mercurial releases and consumers of the previous ``req`` 2nd argument will need updating to use the new API. Differential Revision: https://phab.mercurial-scm.org/D2803

hgweb: pass modern request type into various webutil functions (API) Our march towards killing wsgirequest continues. .. api:: Various functions in hgweb.webutil now take a modern request object instead of ``wsgirequest``. Differential Revision: https://phab.mercurial-scm.org/D2802

hgweb: don't redundantly pass templater with requestcontext (API) The requestcontenxt has a ``tmpl`` attribute to access the templater. We don't need to pass the templater explicitly when passing a requestcontext instance. .. api:: Various helper functions in hgweb.webutil no longer accept a templater instance. Access the templater through the ``web`` argument instead. Differential Revision: https://phab.mercurial-scm.org/D2801

hgweb: use templater on requestcontext instance After this commit, all @webcommand function no longer use their "tmpl" argument. Instead, they use the templater attached to the requestcontext. This is the same exact object. So there should be no difference in behavior. Differential Revision: https://phab.mercurial-scm.org/D2800

hgweb: add a sendtemplate() helper function This pattern is common. Let's make a helper function to reduce boilerplate. We store the "global" template on the requestcontext instance and use it. The templater used by the helper function is the same templater that's passed in as an argument to the @webcommand functions. It needs to be this way because various commands are accessing and mutating the defaults on the templater instance. Differential Revision: https://phab.mercurial-scm.org/D2799

hgweb: use web.req instead of req.req We now have access to the modern request type on the requestcontext instance. Let's access it from there. While we're here, remove an unused argument from _search(). Differential Revision: https://phab.mercurial-scm.org/D2798

hgweb: stop setting headers on wsgirequest All commands now go through the new response API. This is dead code. Differential Revision: https://phab.mercurial-scm.org/D2797

hgweb: always return iterable from @webcommand functions (API) We had to hack up this function to support our transition to the new response API. Now that we're done with the transition (!!), we can return to returning an iterator of content chunks from these functions. It is tempting to return a normal object and not a generator. However, as the keyword extension demonstrates, extensions may wish to wrap commands and have a try..finally block around execution. Since there is a generator producing content and that generator could be executing code, the try..finally needs to live for as long as the generator is running. That means we have to return a generator so wrappers can consume the generator inside a try..finally. .. api:: hgweb @webcommand functions must use the new response object passed in via ``web.res`` to initiate sending of a response. The hgweb WSGI application will no longer start sending the response automatically. Differential Revision: https://phab.mercurial-scm.org/D2796

hgweb: send errors using new response API Our slow march off of wsgirequest continues. Differential Revision: https://phab.mercurial-scm.org/D2795

hgweb: refactor 304 handling code We had generic code in wsgirequest for handling HTTP 304 responses. We also had a special case for it in the catch all exception handler in the WSGI application. We only ever raise 304 in one place. So, we don't need to treat it specially in the catch all exception handler. But it is useful to validate behavior of 304 responses. We port the code that sends a 304 to use the new response API. We then move the code for screening 304 sanity into the new response API. As part of doing so, we discovered that we would send Content-Length: 0. This is not allowed. So, we fix our response code to not emit that header for empty response bodies. Differential Revision: https://phab.mercurial-scm.org/D2794

hgweb: transition permissions hooks to modern request type (API) We're trying to remove ``wsgirequest``. The permissions hooks don't do anything they can't do with our new request type. So let's pass that in. This was the last use of ``wsgirequest`` in the wire protocol code! .. api:: hgweb.hgweb_mod.permhooks no longer take a ``wsgirequest`` instance as an argument. Differential Revision: https://phab.mercurial-scm.org/D2793

hgweb: port archive command to modern response API Well, I tried to go with PEP 3333's recommendations and only allow our WSGI application to emit data via a response generator. Unfortunately, the "archive" command calls into the zipfile and tarfile modules and these operator on file objects and must send their data to an object with write(). There's no easy way turn these write() calls into a generator. So, we teach our response type how to expose a file object like object that can be used to write() output. We try to keep the API consistent with how things work currently: callers must call a setbody*(), then sendresponse() to trigger sending of headers, and only then can they get a handle on the object to perform writing. This required overloading the return value of @webcommand functions even more. Fortunately, we're almost completely ported off the legacy API. So we should be able to simplify matters in the near future. A test relying on this functionality has also been updated to use the new API. Differential Revision: https://phab.mercurial-scm.org/D2792

hgweb: refactor fake file object proxy for archiving Python's zip file writer operates on a file object. When doing work, it periodically calls write(), flush(), and tell() on that object. In WSGI contexts, the start_response function returns a write() function. That's a function to write data, not a full file object. So, when the archival code was first introduced in 2b03c6733efa in 2006, someone invented a proxy "tellable" type that wrapped a file object like object and kept track of write count so it could implement tell() and satisfy zipfile's needs. When our archival code runs, it attempts to tell() the destination and if that fails, converts it to a "tellable" instance. Our WSGI application passes the "wsgirequest" instance to the archival function. It fails the tell() test and is converted to a "tellable." It's worth noting that "wsgirequest" implements flush(), so "tellable" doesn't. This hackery all seems very specific to the WSGI code. So this commit moves the "tellable" type and the conversion of the destination file object into the WSGI code. There's a chance some other caller may be passing a file object like object that doesn't implement tell(). But I doubt it. As part of the refactor, our new type implements flush() and doesn't implement __getattr__. Given the intended limited use of this type, I want things to fail fast if there is an attempt to access attributes because I think it is important to document which attributes are being used for what purposes. Differential Revision: https://phab.mercurial-scm.org/D2791

tests: additional test coverage of archive web command This command is special in a few ways. First, it is the only command using the write() function from WSGI's start_response() function. Second, it is setting a custom content-disposition header. We change the test so it prints out full details of the HTTP response. We also save the response body to a file so we can verify its size and hash. The hash check will help ensure that archive generation is deterministic. Differential Revision: https://phab.mercurial-scm.org/D2790

hgweb: port static file handling to new response API hgwebdir_mod hasn't received as much porting effort. So we had to do some minor plumbing to get it to match hgweb_mod and to support the new response object. Differential Revision: https://phab.mercurial-scm.org/D2789

hgweb: remove one-off routing for file?style=raw Now that both functions are using the same API, we can unify how the command is called and perform command-specific behavior in the command itself instead of in the high-level router. Differential Revision: https://phab.mercurial-scm.org/D2788

hgweb: port most @webcommand to use modern response type This only focused on porting the return value. raw file requests are wonky because they go through a separate code path at the dispatch layer. Now that everyone is using the same API, we could clean this up. It's worth noting that wsgirequest.respond() allows sending the Content-Disposition header, but the only user of that feature was removed as part of this change (with the setting of the header now being performed inline). A few @webcommand are not as straightforward as the others and they have not been ported yet. Differential Revision: https://phab.mercurial-scm.org/D2787

hgweb: support using new response object for web commands We have a "requestcontext" type for holding state for the current request. Why we pass in the wsgirequest and templater instance to @webcommand functions, I don't know. I like the idea of standardizing on using "requestcontext" for passing all state to @webcommand functions because that scales well without API changes every time you want to pass a new piece of data. So, we add our new request and response instances to "requestcontext" so @webcommand functions can access them. We also teach our command dispatcher to recognize a new calling convention. Instead of returning content from the @webcommand function, we return our response object. This signals that this response object is to be used for sending output. The keyword extension was wrapping various @webcommand and assuming the output was iterable, so we had to teach it about the new calling convention. To prove everything works, we convert the "filelog" @webcommand to use the new convention. The new calling convention is a bit wonky. I intend to improve this once all commands are ported to use the new response object. Differential Revision: https://phab.mercurial-scm.org/D2786

hgweb: inline caching() and port to modern mechanisms We only had one consumer of this simple function. While it could be a generic function, let's not over abstract the code. As part of inlining, we port it off wsgirequest, fix some Python 3 issues, and set a response header on our new response object so it is ready once we start using it to send responses. Differential Revision: https://phab.mercurial-scm.org/D2785

hgweb: expose repo name on parsedrequest I'm not a fan of doing this because I want to find a better solution to the REPO_NAME hack. But this change gets us a few steps closer to eliminating use of wsgirequest. We can worry about fixing REPO_NAME once wsgirequest is gone. Differential Revision: https://phab.mercurial-scm.org/D2784

hgweb: expose URL scheme and REMOTE_* attributes These are consulted by the HTTP wire protocol handler by reading from the env dict. Let's expose them as attributes instead. With the wire protocol handler updates to use the new attributes, we no longer have any consumers of the legacy wsgirequest type in the wire protocol code (outside of a proxied call to the permissions checker). So, we remove most references to it. Differential Revision: https://phab.mercurial-scm.org/D2783

hgweb: remove wsgirequest.form (API) Now that everything is ported to consume from parsedrequest.qsparams, we no longer have a need for wsgirequest.form. Let's remove all references to it. .. api:: The WSGI request object no longer exposes a ``form`` attribute containing parsed query string data. Use the ``qsparams`` attribute instead. Differential Revision: https://phab.mercurial-scm.org/D2782

hgweb: perform all parameter lookup via qsparams I think I managed to update all call sites using wsgirequest.form to use parsedrequest.qsparams. Since behavior of qsparams is to retrieve last value, behavior will change if a parameter was specified multiple times. But I think this is acceptable. I'm not a fan of the `req.req.qsparams` pattern. And some of the modified code could be written better. But I was aiming for a straight port with this change. Cleanup can come later. Differential Revision: https://phab.mercurial-scm.org/D2781